From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 19:53:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0901C694 for ; Sun, 4 Aug 2013 19:53:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3DA42736 for ; Sun, 4 Aug 2013 19:53:31 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D0E621203D9; Sun, 4 Aug 2013 21:53:16 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BA6CD28494; Sun, 4 Aug 2013 21:53:16 +0200 (CEST) Date: Sun, 4 Aug 2013 21:53:16 +0200 From: Jilles Tjoelker To: Tim Kientzle Subject: Re: Reliable process tracking Message-ID: <20130804195316.GA39246@stack.nl> References: <20130804134658.GC35080@stack.nl> <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:53:32 -0000 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