| 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:20 |
|---|---|---|
| ion | I’ve had better experiences with sudo than start-stop-daemon. “exec sudo -H -u user -- cmd” | 00:21 |
| Lekensteyn | hi all | 13:34 |
| Lekensteyn | The `pidfile` stanza has been removed a while ago, is there any way I can make upstart aware of the right PID? | 13:35 |
| 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:36 |
| jodh | Lekensteyn: Upstart doesn't use pid files as it tracks pids itself. Read this: http://upstart.ubuntu.com/cookbook/#expect | 13:42 |
| Lekensteyn | I saw that, but it does not work for me since all fork()s are traced | 13:45 |
| Lekensteyn | the application first loads the configuration and then daemonizes if it should do that according to the config | 13:46 |
| Lekensteyn | during loading of the config, fork&exec could occur (modinfo $driver) | 13:47 |
| jodh | Lekensteyn: your app uses ptrace itself? | 13:48 |
| Lekensteyn | nope | 13:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| Lekensteyn | thanks for your help btw | 13:56 |
| Lekensteyn | How can I clear stale pids without rebooting or renaming the job? Related bug https://bugs.launchpad.net/upstart/+bug/406397 | 14:38 |
| 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:40 |
| 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:41 |
| Lekensteyn | It is on my dev box ;) | 14:42 |
| 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:43 |
| jodh | Lekensteyn: as I already said, upstart doesn't use pidfiles - it uses ptrace to establish the pid. | 14:44 |
| Lekensteyn | what PID is tracked if "script \n .... \nend script" is used? | 15:03 |
| jodh | Lekensteyn: that is all covered in the previously referenced http://upstart.ubuntu.com/cookbook/#expect | 15:09 |
| Lekensteyn | jodh: thanks for your help so far, is it possible to redirect stdout/stderr from the program to syslog? | 16:27 |
| 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:31 |
| jodh | alternatively, run "mycmd | logger" if creating that extra logger process won't cause your job problems. | 16:32 |
| Lekensteyn | Thanks, I | 16:35 |
| Lekensteyn | 'll try it, should I use exec or script | 16:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!