Nicolas Williams wrote: > On Fri, Oct 16, 2009 at 02:04:20PM -0500, Mark Martin wrote: > >> <contract_export type="pid_file" name="/var/run/pids/tomcat.pid"/> >> > > The problem is that a process contract can have more than one member > process (and almost always does at some point). But consumers of PID > files usually want a single PID in a PID file. > True. > Which PID should appear in such a magic PID file? > I don't rightly know at this moment. Presumably you could pick the right one in most cases. Right = which one would Linux want? (certainly excluding svc.startd and friends). > PID files are quaint in an SMF world. > > It's possible that what's going on here is that some application > restarts the Tomcat service by killing the PID in the Tomcat PID file. > That's not the right way to restart a service under SMF management. > > Another possibility is that some tool monitors the health of the service > by first looking up the Tomcat daemon PID and then monitoring the > process. Here the right thing to do is to check the service itself, not > the processes that make it up. > While I agree totally with you about what the right thing to do is, I was looking for a way to lower the bar slightly for project teams tasked with porting FOSS -- creating a porting bridge of a sort for them without burdening them with the repetitive rewrite-pid-stuff-as-SMF type tasks that might crop up. There seems to be this gap between "rewrite it the Solaris way" and "It's a Linux familiarity case so leave it alone", and I wonder if we couldn't source some transitioning API's or technology to bridge those gaps.
It's probably a non-starter simply because, as you suggest, it's likely that processes would try to restart daemons this way, and that way lies pain and suffering and astonishment. My use case is very narrow -- a read-only file system exposing a PID for a layered monitoring application that uses /legacy/ interface.
