<Tekk>
sdomi: It's not robust against a whole system crash, but that's about all I can think of.
<misentropy>
have you considered catching signals from children
<misentropy>
oh hi trap
<Tekk>
Come to think of it I'm not sure I like pidfiles anyway. Since there's presumably been a crash if it hasn't been done I think the debial solution might be better
<Tekk>
Just warn about the stale pidfile and die
jn has quit [Ping timeout: 252 seconds]
jn has joined ##bash-crimes
jn has joined ##bash-crimes
Tekk has quit [Quit: zzz]
f[x] has joined ##bash-crimes
f[x] has quit [Remote host closed the connection]
<cve>
I am not sure if creating a lockdir might help; what happens to dir fds that were opened before the lockdir was created (e.g. in the classical opendir(3) usage)
<cve>
do they keep the directory state that was present during the opendir(3) call? or is it dynamically updated?
<cve>
but I might be thinking a little bit out of the box here, so maybe view my comments as a thinking out loud instead :P
Tekk has joined ##bash-crimes
f[x] has joined ##bash-crimes
<sdomi>
cve: i may not be familiar with the internals here, but why would that matter? as far as i'm concerned the mkdir trick just operates on the logic of "a directory will only be created if it doesn't exist, and we can check the return code on that"
<sdomi>
please correct me if i'm missing something obvious
<cve>
nevermind, that sounds right ^^
<cve>
was more concerned when an external application monitors that directory, but that is probably out of scope
<JAA>
Yeah, it's basically 'mkdir(2) will succeed iff the directory did not exist yet'.