On Fri, Oct 16, 2009 at 02:44:32PM -0500, Mark Martin wrote: > Nicolas Williams wrote: > >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).
"which one would Linux want" == the one that writes to the PID file. If you take that out then you can't tell. The problem here is that writing to the PID file is tricky. It necessarily requires privilege, which complicates service startup, since privs have to be dropped, and this too, like picking a PID to put in a PID file, can't be done automatically by SMF -- the start method/daemon has to take care of that. One possibility is that we could have a "PID file service" which records a PID for any SMF FMRI when a member of any running service's process contract asks to do that. But that'd have to be retrofitted in, and we gain little or nothing from that. Just make the tools in question not need a PID file :) > 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. I agree. I don't know what can be done about it :( Nico --
