Mark Martin wrote:
> Nicolas Williams wrote:
>> 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.
Don't those projects already have some code that does the equivalent of
fp = fopen("/my/pid/file", "w"); fprintf(fp, "%d\n", getpid());?
They need that to run on Linux or any other system, so why should
OpenSolaris offer special support for generating PID files -- especially
so when OpenSolaris doesn't even really need them? Would anybody really
use them?
> 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.
I must be missing the point, because in previous cases, all we've really
had to do was say "you shouldn't have these, but the right place for
these, if you must have them at all, is /var/run if privileged, and
somewhere else if not."
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
