James Carlson wrote:
> 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 the fopen("/var/run/tomcat.pid", "r"); fscanf(); side I was
interested in. In one particular case, a shell script is creating the
pid. That's the pattern I have the most particular personal experience
with, actually, however slight that experience might be -- an external
wrapper creating the pid file. Regardless, for purposes of this
discussion, I was presuming an existing service would already be
"Solaris'd" and using SMF. Incoming, ported, external monitors of same
said service would, by default, go hunting about for PID's to determine
state. A porting team would then need to /probably/ fork source and
replace the fopen();fscanf();kill() calls with smf_disable_instance();
//or whatever -- you get the point
>
>> 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."
>
If that's the advice that the ARC has given in the past then I thank you
for it and I believe that's what's been already been given to the team
for the interesting case that spurred this idea. I was trying to solve
for the "if you must have them at all" clause, but as I said, it's
probably not solving enough of a problem to be worth investigating.
I think the summary here is that the way to handle this is for project
teams to do the fork and campaign to get the patch integrated upstream,
and for the ARC to be consistently insistent on the "do it the Right Way
and use SMF" advice.
Maybe I'm just continuing to fish for reasons to put anything that looks
like BFS or WinFS into OpenSolaris.
