[00:20] <ahammond> figured it out. we're using an older version of upstart and setgid / setuid stanzas aren't supported. wrapped the whole thing in start-stop-daemon. Ugly, but upgrade friendly.
[00:21] <ion> I’ve had better experiences with sudo than start-stop-daemon. “exec sudo -H -u user -- cmd”
[13:34] <Lekensteyn> hi all
[13:35] <Lekensteyn> The `pidfile` stanza has been removed a while ago, is there any way I can make upstart aware of the right PID?
[13:36] <Lekensteyn> Our program fork&execs some program to do some initialization tests and then forks&(in parent) exist if the command line options say so
[13:36] <Lekensteyn> exits*
[13:42] <jodh> Lekensteyn: Upstart doesn't use pid files as it tracks pids itself. Read this: http://upstart.ubuntu.com/cookbook/#expect
[13:45] <Lekensteyn> I saw that, but it does not work for me since all fork()s are traced
[13:46] <Lekensteyn> the application first loads the configuration and then daemonizes if it should do that according to the config
[13:47] <Lekensteyn> during loading of the config, fork&exec could occur (modinfo $driver)
[13:48] <jodh> Lekensteyn: your app uses ptrace itself?
[13:48] <Lekensteyn> nope
[13:50] <Lekensteyn> start program (pid 100), fork (child 101) & execve "modinfo driver" (multiple times), fork (child 102), child continues, parent (100) is exited
[13:50] <jodh> Lekensteyn: well, you must either ensure the config doesn't change, or auto-gen the upstart .conf file with an appropriate expect stanza, or use start-stop-daemon or an equivalent tool.
[13:51] <Lekensteyn> currently, the config and environment is validated before daemonizing, should it be done in an other way then? (i.e. validate after daemonizing)
[13:52] <jodh> if you have a tool to validate your apps config file, maybe that tool could ensure that if your apps config says something like "daemonize=true" that the upstart config contains "expect daemon"?
[13:53] <Lekensteyn> well, it's ran like "programm --daemon". If that option is encountered, it knows that it should daemonize later. Before daemonizing, other settigns are evaluated (like --driver or Driver from conffile)
[13:56] <Lekensteyn> thanks for your help btw
[14:38] <Lekensteyn> How can I clear stale pids without rebooting or renaming the job? Related bug https://bugs.launchpad.net/upstart/+bug/406397
[14:40] <jodh> http://upstart.ubuntu.com/cookbook/#recovery-on-misspecification-of-expect. If that fails, you'll have to reboot.
[14:40] <Lekensteyn> so I've to reboot or rename :s
[14:41] <jodh> Lekensteyn: the recommendation is to develop your .conf file on a non-critical dev box. Once you have fully tested it, then deploy to your server(s).
[14:42] <Lekensteyn> It is on my dev box ;)
[14:43] <Lekensteyn> Now, I've tried program --daemon;wait "$(cat /var/run/program.pid)" but the pid tracked by Upstart is wrong. How do I make Upstart aware of my pidfile?
[14:44] <jodh> Lekensteyn: as I already said, upstart doesn't use pidfiles - it uses ptrace to establish the pid.
[15:03] <Lekensteyn> what PID is tracked if "script \n .... \nend script" is used?
[15:09] <jodh> Lekensteyn: that is all covered in the previously referenced http://upstart.ubuntu.com/cookbook/#expect
[16:27] <Lekensteyn> jodh: thanks for your help so far, is it possible to redirect stdout/stderr from the program to syslog?
[16:31] <jodh> Upstart 1.4 can log job output. If you're using an older version though, use the technique here: http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section, but rather than writing to /dev/.initramfs/..., write to /dev/kmsg.
[16:32] <jodh> alternatively, run "mycmd | logger" if creating that extra logger process won't cause your job problems.
[16:35] <Lekensteyn> Thanks, I
[16:35] <Lekensteyn> 'll try it, should I use exec or script