From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 13:46:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D38C3771 for ; Mon, 5 Aug 2013 13:46:22 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id B968E2E19 for ; Mon, 5 Aug 2013 13:46:22 +0000 (UTC) Received: from homiemail-a98.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 37923DD560 for ; Mon, 5 Aug 2013 06:46:22 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 5E50F2C2060; Mon, 5 Aug 2013 06:46:16 -0700 (PDT) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id 006172C2057; Mon, 5 Aug 2013 06:46:15 -0700 (PDT) Date: Mon, 5 Aug 2013 09:46:14 -0400 From: Tom Rhodes To: Jilles Tjoelker 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> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: tim@kientzle.com, 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: Mon, 05 Aug 2013 13:46:22 -0000 On Sun, 4 Aug 2013 21:53:16 +0200 Jilles Tjoelker 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