Date: Sun, 4 Aug 2013 21:53:16 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-ID: <20130804195316.GA39246@stack.nl> In-Reply-To: <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> References: <20130804134658.GC35080@stack.nl> <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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). -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130804195316.GA39246>