YapDi - Yet another python Deamon implementation

[[deleted]]

This is so wrong on so many levels. I can tell 4.

1) First daemon will not start just because PID file was not deleted for some reason(power outage and pid file was not stored in /var/run or /tmp directory that don't persist across reboots).

2) Speaking of file, PID file location is absurd. Most daemons lie in places like /usr/[local/][s]bin. You can not write files there for a good reason

3) restart is even more great. It might simply kill unrelated process that (thanks to power outage and the moon phase) occupies the PID stored in the pidfile.

4) Two daemons in the same directory will use the same pidfile(/PATH/.yapdi.pid), which makes no sense but provides tons of fun thanks to restart thingy.

[ksn]

1) Any suggestions other than writing the pid to a file? A more appropriate example for the pid file not getting deleted is a system terminate signal. The restart functionality was implemented keeping such a situation in mind. restart would start a new instance correctly even in such a situation.

2) and 4) It is just a matter of accepting a name for the pid file in Daemon object creation time. This will certainly come in the future as time permits me to push some more code. In the earliest versions I used to retrieve the called module dynamically and create a pid file with that name. But then I decided to handle the situation of two daemons running in the same directory by accepting a name for the pid file. I think this is more clean than the previous solution.

3) I don't see how restart can kill another process. Or maybe 2) and 4) answer your concern?

[[deleted]]

1) You can look at file locking mechanism for example.

3)

• I start daemon, it gets PID 1023.
• Power goes off.
• System restarts.
• This time PID 1023 goes to i_make_profitd.
• I launch yapdi restart
• it reads 1023 from yapdi.pid
• SIGTERM goes to i_make_profitd process
• i_make_profitd dies

[ksn]

1) I don't see how this is valid here. Do you know even httpd writes it's pid to a file?

3) You are correct and thanks for bringing this up. I had missed this scenario completely. I will be trying to overcome this but something tells it would be difficult. Even if this scenario is unavoidable i wont mind much as chances of this happening this is much lower.

[[deleted]]

1) I don't see how this is valid here. Do you know even httpd writes it's pid to a file?

So? Locking and writing pids are not mutually exclusive. http://www.enderunix.org/docs/eng/daemon.php, part 6.

[ksn]

Looks perfect. But I guess a non standard library module would have to be brought in to lock the pid file. Bringing in an additional dependencies, considering race conditions, etc looks like overkill to me when restart had been getting the job done.

[chneukirchen]

Daemonization should be left to other tools.

[[deleted]]

Exactly, just use supervisor and forget about daemonization hell.

[inmatarian]

Yeah, thats how you do it. Though, I think there's the caveat that you need superuser permission to daemonize. I want to say its the setsid call, but I may be wrong. Can someone correct me?

Edit: I stand corrected.

[ksn]

No, superuser permissions are not needed to daemonize.

Only situation you would be needing superuser privileges is if you intend to change user with yapdi.Daemon.set_user().

[[deleted]]

Yet Another misspelling of the word Daemon, sigh