On Wed, Oct 28, 2009 at 10:51:13AM -0500, Mark Martin wrote: > As this case appears to be closed, with the official +1 and all that, > I just want to make sure I understand what the message here is for > future teams. With this case, it appears that is acceptable for teams > (internal or not) to use the PID file process-locating interface > instead of SMF's contracts, /*even when using SMF as the agent to run > the service*/. Furthermore, it is acceptable for these PID files to > be put in arbitrary locations, or at least locations relatively local > to other project artifacts (instead of, say, a single common > system-wide location).
I think there may never have been a stricture against creating PID files in /var/run, even though SMF obviates the need for them, but even so, this case should absolutely NOT be seen as establishing precedent that it's OK to have PID files, because: a) PID files can make it difficult to have multiple enabled instances of your service -- impossible, actually, if the PID file path is hardcoded; b) PID files are not needed anyways, since you can always find your running services' processes by using process contracts; c) PID files are ugly, and not the SMF way; d) PID files often cause headaches, depending on the implementation (e.g., if one process crashes and leaves behind a PID file, and by the time a new process starts the old process' PID has been reused and the new instance then refuses to start); e) ... I could probably go on, but let's not. PID files are not a good mechanism at all. (a) is fatal, IMO; PID files should be forbidden by default, and you should have to seek ARC and c-team permission to integrate code that uses PID files. Nico --
