On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote: > On Sun, Mar 20, 2016 at 08:53:03PM +0000, Roy Marples wrote: > > On Sunday 20 March 2016 14:53:46 you wrote: > > > On Sat, 19 Mar 2016 23:29:37 +0000 > > > > > > Roy Marples <r...@marples.name> wrote: > > > > pidfile(3) is pretty crap - it just writes to the file without any > > > > locking. > > > > > > I don't understand why you think any of that matters. Locks only > > > advisory anyway. Any noncooperating process can (with sufficient > > > privilege) overwrite the file. What cooperating process do you imagine > > > would honor a lock on a pidfile? > > > > So it honors it's own lock to avoid user stupidity of starting the same > > daemon > > more than once. This is the primary goal of the function. > > That's the wrong way to do it, because it does not work reliably on NFS. > You can take advantage of O_CREAT|O_EXCL or rename() semantics to do the > same thing but in a much more robust way.
In fact, what you really want is just the guts of shlock(1), specifically the shlock -p behavior. I can't see any reason why pidfile shouldn't just do exactly what shlock -p does, except with a C rather than a shell interface. -- Thor Lancelot Simon t...@panix.com "We cannot usually in social life pursue a single value or a single moral aim, untroubled by the need to compromise with others." - H.L.A. Hart
