Date: Mon, 5 Aug 2013 09:46:14 -0400 From: Tom Rhodes <trhodes@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: tim@kientzle.com, freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-ID: <20130805094614.3ff8c2fa.trhodes@FreeBSD.org> In-Reply-To: <20130804195316.GA39246@stack.nl> References: <20130804134658.GC35080@stack.nl> <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> <20130804195316.GA39246@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Aug 2013 21:53:16 +0200 Jilles Tjoelker <jilles@stack.nl> wrote: > On Sun, Aug 04, 2013 at 10:15:47AM -0700, Tim Kientzle wrote: > > On Aug 4, 2013, at 6:46 AM, Jilles Tjoelker wrote: > > > When shutting down a service or requesting status, rc.subr currently > > > uses a combination of pidfiles and process names. This is fairly but not > > > completely reliable once it is set up correctly (which can take a lot of > > > work and possibly patching the daemon to use pidfile(3) from our > > > libutil). It is also incapable of killing multiprocess daemons such as > > > CGI web servers without cooperation of the daemon. > > > > I think what is needed here is a facility that marks a process and all > > > of its descendants. > > > It sounds like all you really need is some way to > > signal a process and all descendants. > > No, it is different in several ways. Firstly, you need a different > definition of descendants than the one implied by getppid(). The parent > process ID resets to 1 when the parent exits, which would cause the > child to lose its relationship with the group. > > Secondly, I want to keep track of the group even if the top level > process terminates. For example, if apache's or postgres's master > process crashes, I want to shut down all remaining worker processes > before attempting to start a new master. > > > Why do you need to actively mark and/or track them? > > Tracking is needed for restarting services when they crash, as done by > fsc. It can also be useful for providing information to the system > administrator. > > Also, it can be useful for legacy/simple compatibility. After running > '/etc/rc.d/foo start' with a mark, the marked process(es) with ppid 1 > can be considered the processes that need to be monitored for service > foo. Admittedly, this is not fully reliable, but it is better than > matching by name on the process table (which is otherwise needed if the > daemon does not write a pid file). All good points - I actually don't really like the entire rc.d plugin stuff but wanted to be as "clean" as possible. It might be a neat project to work at removing the rc support from it. I'll be traveling to Baltimore this week for a convention, if I have some evening time I might look over this a bit. Famous last words considering I have little free time these days. :( -- Tom Rhodes
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130805094614.3ff8c2fa.trhodes>