[13:29] how can I (easily) HUP to reload a process [13:30] everything says "initctl reload " - but as far as I can ascertain that's simply for reloading initctl's config file for that job [13:30] I'm wroking with three daemons which respond to HUP by seamlessly rebooting themselves with zero-downtime [13:31] I don't really feel like going back to systemv init scripts, or reading pidfiles and sending HUPs - especially as that causes upstart to lose track of them when their PID changes [13:37] Parse the pid from the output of initctl status job, send HUP to that. [13:39] pid=; eval "$(initctl status foo | sed -nre 's|^cron start/running, process ([0-9]+)$|pid=\1;|p')" [13:40] if [ -n "$pid" ]; then … [14:02] thanks ion, that's a bit cleaner [14:02] but when teh pid changes, initctl will still lose track of it, right ? [14:02] (sorry, didn't see your response) [14:04] If the pid changes, please file a bug report against the daemon. :-P [14:25] heh [14:26] Unicorn (web server) treats a USR2 as an invitation to reload itself, it spawns a new master process - and replaces the old one as the worker processes complete their tasks [14:26] so that's a perenial problem [14:26] and in Rails land, booting an application takes 45 seconds [14:28] Perhaps Unicorn could have a very thin parent process that just keeps the child running and dies if the child dies. That would result in a constant pid. [15:32] codebeaker: initctl reload does in fact send HUP to the tracked pid [15:33] but it says that it's used for reloading the initctl script [15:33] codebeaker: anything that forks and then exits multiple times in its lifecycle cannot be tracked by upstart [15:33] codebeaker: wrong, that is reload-configuration [15:33] ok, so that is "restart" is a stop/start [15:34] yes, restart also does not reload the job file between stop/start