Re: pidfile_lock(3)

2016-04-01 Thread Roy Marples
On 20/03/2016 18:53, James K. Lowden wrote: > The biggest problem with pidfiles IMO is stale files left over when the > process terminates abnormally. That could be remedied with a separate > daemon, modelled on syslogd, that would create, update and delete > them. Modify pidfile(3) to use the da

Re: pidfile_lock(3)

2016-03-24 Thread Steffen Nurpmeso
Hi. "James K. Lowden" wrote: |mlel...@serpens.de (Michael van Elst) wrote: |> r...@marples.name (Roy Marples) writes: |>>See here: |>>http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html Well, btw., the MUA i maintain forks, keeping a communication pipe to its parent, then c

Re: pidfile_lock(3)

2016-03-24 Thread James K. Lowden
On Thu, 24 Mar 2016 07:18:13 + (UTC) mlel...@serpens.de (Michael van Elst) wrote: > r...@marples.name (Roy Marples) writes: > > >See here: > >http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html > > ... handling crashing programs reliably > > isn't a worthwhile goal to me.

Re: pidfile_lock(3)

2016-03-24 Thread Thor Lancelot Simon
On Thu, Mar 24, 2016 at 11:55:25AM +, Roy Marples wrote: > Lets go back to the original question. > > On 20/03/2016 09:26, Michael van Elst wrote: > > r...@marples.name (Roy Marples) writes: > > > >> So I've created pidfile_lock (patch attached) to address these problems. > > > > Does it wor

Re: pidfile_lock(3)

2016-03-24 Thread Roy Marples
On 24/03/2016 12:47, Michael van Elst wrote: > r...@marples.name (Roy Marples) writes: > >> If it doesn't work on NFS and you care so much, please spend your time >> fixing NFS > > If you want to change things you should not try to pass your responsibility > to someone else. But with regards to

Re: pidfile_lock(3)

2016-03-24 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >If it doesn't work on NFS and you care so much, please spend your time >fixing NFS If you want to change things you should not try to pass your responsibility to someone else. -- -- Michael van Elst Internet: mlel...@serp

Re: pidfile_lock(3)

2016-03-24 Thread Roy Marples
Lets go back to the original question. On 20/03/2016 09:26, Michael van Elst wrote: > r...@marples.name (Roy Marples) writes: > >> So I've created pidfile_lock (patch attached) to address these problems. > > Does it work on NFS root? After taking on board what everyone has said, my considered a

Re: pidfile_lock(3)

2016-03-24 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >See here: >http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html ... handling crashing programs reliably isn't a worthwhile goal to me. -- -- Michael van Elst Internet: mlel...@serpens.de

Re: pidfile_lock(3)

2016-03-23 Thread Roy Marples
On Thursday 24 March 2016 10:25:20 Brett Lymn wrote: > On Tue, Mar 22, 2016 at 02:13:01PM +0100, Martin Husemann wrote: > > None of my (plenty) diskless machines does that - /var/run is not > > performance critical, so why bother? > > Because it automagically gets cleared out when the machine rebo

Re: pidfile_lock(3)

2016-03-23 Thread Brett Lymn
On Tue, Mar 22, 2016 at 02:13:01PM +0100, Martin Husemann wrote: > > None of my (plenty) diskless machines does that - /var/run is not > performance critical, so why bother? > Because it automagically gets cleared out when the machine reboots so you don't have to worry about stale pid files? --

Re: pidfile_lock(3)

2016-03-22 Thread Edgar Fuß
> It works correctly on NFS if you have the locking daemon setup? NetBSD doesn't support the client side of NLM, does it? Ages ago, I wrote the client side (for 3.0), but nobody picked that up.

Re: pidfile_lock(3)

2016-03-22 Thread Martin Husemann
On Tue, Mar 22, 2016 at 02:10:57PM +0100, Joerg Sonnenberger wrote: > It works correctly on NFS if you have the locking daemon setup? Besides, > is there even a valid reason for using NFS for pidfiles? I would expect > /var/run to be a minimal tmpfs in that kind of installations. None of my (plent

Re: pidfile_lock(3)

2016-03-22 Thread Joerg Sonnenberger
On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote: > On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote: > > On Sunday 20 March 2016 14:53:46 you wrote: > > > On Sat, 19 Mar 2016 23:29:37 + > > > > > > Roy Marples wrote: > > > > pidfile(3) is pretty crap - it just w

Re: pidfile_lock(3)

2016-03-21 Thread Rhialto
On Mon 21 Mar 2016 at 19:02:10 -0400, Thor Lancelot Simon wrote: > On Mon, Mar 21, 2016 at 04:44:40PM +, Roy Marples wrote: > > > > foo starts as PID 10, links /var/foo and writes 10 to it. > > "As simple as possible but no simpler". Don't just write 10, write > hostname-proctitle-10 (this i

Re: pidfile_lock(3)

2016-03-21 Thread Thor Lancelot Simon
On Mon, Mar 21, 2016 at 04:44:40PM +, Roy Marples wrote: > > foo starts as PID 10, links /var/foo and writes 10 to it. "As simple as possible but no simpler". Don't just write 10, write hostname-proctitle-10 (this is an old solution too; trn does it). Thor

Re: pidfile_lock(3)

2016-03-21 Thread James K. Lowden
On Mon, 21 Mar 2016 10:55:49 -0400 Thor Lancelot Simon wrote: > Please do not introduce a daemon just to service pidfile. Do one thing and do it well? It need not be a new daemon. The functionality could attach to syslogd, for example, or init I know you understand the motivation: t

Re: pidfile_lock(3)

2016-03-21 Thread Michael van Elst
dyo...@pobox.com (David Young) writes: >I'm not sure that the problem of pidfile(3)-using crashing programs is >serious enough on its own to justify changing the kernel. The standard usage is: system bootstrap removes pidfiles (or uses empty tmpfs) daemon creates pidfile exclusively on startup a

Re: pidfile_lock(3)

2016-03-21 Thread David Young
On Mon, Mar 21, 2016 at 04:44:40PM +, Roy Marples wrote: > How else would you solve your need to work on NFS and my need to lock > and handling crashing programs reliably? I'm not sure that the problem of pidfile(3)-using crashing programs is serious enough on its own to justify changing the k

Re: pidfile_lock(3)

2016-03-21 Thread Roy Marples
On 21/03/2016 14:55, Thor Lancelot Simon wrote: > On Mon, Mar 21, 2016 at 02:30:43PM +, Roy Marples wrote: >>> >>> 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 shloc

Re: pidfile_lock(3)

2016-03-21 Thread Thor Lancelot Simon
On Mon, Mar 21, 2016 at 02:30:43PM +, Roy Marples wrote: > > > > 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 > >

Re: pidfile_lock(3)

2016-03-21 Thread Roy Marples
On 21/03/2016 00:46, Thor Lancelot Simon wrote: > On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote: >> On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote: >>> On Sunday 20 March 2016 14:53:46 you wrote: On Sat, 19 Mar 2016 23:29:37 + Roy Marples wrote

Re: pidfile_lock(3)

2016-03-20 Thread Thor Lancelot Simon
On Sun, Mar 20, 2016 at 08:43:31PM -0400, Thor Lancelot Simon wrote: > On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote: > > On Sunday 20 March 2016 14:53:46 you wrote: > > > On Sat, 19 Mar 2016 23:29:37 + > > > > > > Roy Marples wrote: > > > > pidfile(3) is pretty crap - it just w

Re: pidfile_lock(3)

2016-03-20 Thread Thor Lancelot Simon
On Sun, Mar 20, 2016 at 08:53:03PM +, Roy Marples wrote: > On Sunday 20 March 2016 14:53:46 you wrote: > > On Sat, 19 Mar 2016 23:29:37 + > > > > Roy Marples wrote: > > > pidfile(3) is pretty crap - it just writes to the file without any > > > locking. > > > > I don't understand why you

Re: pidfile_lock(3)

2016-03-20 Thread Christos Zoulas
In article <21451069.kys5rkk...@uberpc.marples.name>, Roy Marples wrote: >On Sunday 20 March 2016 23:05:12 Christos Zoulas wrote: >> In article <1547312.w6y7ml9...@uberpc.marples.name>, >> Roy Marples wrote: >> >> There is no need for pidfile_lock(), just fix pid_file() to return pid_t. >> I'v

Re: pidfile_lock(3)

2016-03-20 Thread Roy Marples
On Sunday 20 March 2016 23:05:12 Christos Zoulas wrote: > In article <1547312.w6y7ml9...@uberpc.marples.name>, > Roy Marples wrote: > > There is no need for pidfile_lock(), just fix pid_file() to return pid_t. > I've audited the code in the tree and the code that checks, checks for -1. > The com

Re: pidfile_lock(3)

2016-03-20 Thread Christos Zoulas
In article <1547312.w6y7ml9...@uberpc.marples.name>, Roy Marples wrote: There is no need for pidfile_lock(), just fix pid_file() to return pid_t. I've audited the code in the tree and the code that checks, checks for -1. The compat code below is probably wrong anyway. christos >+/* The old fun

Re: pidfile_lock(3)

2016-03-20 Thread Roy Marples
On Sunday 20 March 2016 14:53:46 you wrote: > On Sat, 19 Mar 2016 23:29:37 + > > Roy Marples 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

Re: pidfile_lock(3)

2016-03-20 Thread James K. Lowden
On Sat, 19 Mar 2016 23:29:37 + Roy Marples 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

Re: pidfile_lock(3)

2016-03-20 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >Saying that, I'm not really bothered about any remote lock on a remote fs, >just as long as it can lock correctly on the host. Why would you think NFS root to be not on the host? -- -- Michael van Elst Internet: mlel...@

Re: pidfile_lock(3)

2016-03-20 Thread Roy Marples
On Sunday 20 March 2016 14:04:52 Roy Marples wrote: > Updated patch with man page changes, including an example of it's use. > Added pidfile_remove() which fixes the existing BUGS section. > Added pidfile_close() so a forked process can close it safely. > Made pidfile_read() visible so it's easy to

Re: pidfile_lock(3)

2016-03-20 Thread Roy Marples
Updated patch with man page changes, including an example of it's use. Added pidfile_remove() which fixes the existing BUGS section. Added pidfile_close() so a forked process can close it safely. Made pidfile_read() visible so it's easy to obtain the PID to send a signal to. RpyIndex: include/util

Re: pidfile_lock(3)

2016-03-20 Thread Roy Marples
On Sunday 20 March 2016 09:26:23 Michael van Elst wrote: > r...@marples.name (Roy Marples) writes: > >So I've created pidfile_lock (patch attached) to address these problems. > > Does it work on NFS root? I've not tested it especially, but I would assume so as flock(2) makes no note of it not wo

Re: pidfile_lock(3)

2016-03-20 Thread Michael van Elst
r...@marples.name (Roy Marples) writes: >So I've created pidfile_lock (patch attached) to address these problems. Does it work on NFS root? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every t