| Laney | slangasek: Do you plan on uploading an upstart with user sessions to unstable (soon)? I'm wondering whether to forward stuff and/or trying to have some kind of discussion about adding support to pkg-gnome packages. | 08:56 |
|---|---|---|
| vanguarde9 | Hello guys , i have a question | 09:25 |
| vanguarde9 | http://pastebin.com/XrXXv3Ue | 09:25 |
| vanguarde9 | I have this upstart scripts | 09:25 |
| vanguarde9 | In pre-start stanza Im reading simple config file | 09:26 |
| vanguarde9 | to get content of one shell variable | 09:26 |
| vanguarde9 | but when i try to echo this variable in script stanza | 09:26 |
| vanguarde9 | its empty | 09:27 |
| vanguarde9 | can somebody tell me what im doing wrong ? | 09:27 |
| vanguarde9 | why this variable is not propagated later ? | 09:27 |
| jodh | vanguarde9: http://upstart.ubuntu.com/cookbook/#pass-state-between-job-processes | 09:27 |
| vanguarde9 | thanks for hint | 09:30 |
| xnox | jodh: note debian-devel & debian-bsd w.r.t. kfreebsd upstart porting =))))) | 09:31 |
| jodh | xnox: interesting :) | 09:35 |
| joaojeronimo | so, I have a process that forks 4 times, and upstart is only changing the uid for the father. The children end up not having enough permissions to do stuff on the file system | 12:47 |
| joaojeronimo | how do I correctly setuid for all the children ? | 12:47 |
| jodh | joaojeronimo: upstart requires that processes only fork up to 2 times (since that is the maximum number of forks required to fully daemonize). I'd suggest either running your app in the foreground if it provides an option to do. Alternatively, 'expect stop' might be an option for you? (http://upstart.ubuntu.com/cookbook/#expect-stop) | 12:51 |
| joaojeronimo | jodh: 'expect stop' doesn't seem to fix this problem about the file permissions of the children | 12:53 |
| joaojeronimo | jodh, the problem is I'm running an app that uses leveldb, and leveldb is making 4 forks that need to read and write to the OS. Even using setuid on upstart, apparently the children end up not having correct permissions | 12:54 |
| jodh | joaojeronimo: upstart only sets the initial processes uid - sounds like your app is changing it again somehow. | 12:55 |
| joaojeronimo | jodh: I don't know how this works exactly but it sounds like it starts the process, the process forks, and then upstart changes the uid for the initial process ? | 12:56 |
| jodh | joaojeronimo: correct. | 12:56 |
| jodh | joaojeronimo: well, upstart forks, changes to the user you specify, then runs your app. whatever happens next wrt uids is the apps responsibility. | 12:57 |
| joaojeronimo | interesting... ok got it.. | 12:57 |
| joaojeronimo | well it's a node.js app, I even tried process.setuid('correctusername') but apparently the children still don't get the correct uid | 12:58 |
| jodh | joaojeronimo: try running your job replacing the node.js bit with procenv to show what environment upstart gives it (see http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in) | 12:58 |
| dottedmag | I am trying to run a daemon (which does not have an option to stay in foreground). I use 'expect daemon' and everything works fine, except | 13:00 |
| dottedmag | if this daemon detects configuration problem up launch and exits, and then upstart fails to detect that daemon exited before fork. | 13:00 |
| dottedmag | So upstart continues to report status as start/running (no pid) until I explicitly 'stop' it. | 13:01 |
| dottedmag | Is that expected? | 13:01 |
| dottedmag | It's pretty simple to reproduce. The following job description will stay in 'start/running' state after start: http://pastebin.com/ypdmTPAS | 13:02 |
| jodh | dottedmag: Please read the cookbook. This is correct behaviour because upstart is attempting to run your failing job repeatedly as you have specified 'respawn'. | 13:06 |
| jodh | dottedmag: see: http://upstart.ubuntu.com/cookbook/#expect, http://upstart.ubuntu.com/cookbook/#respawn, http://upstart.ubuntu.com/cookbook/#implications-of-misspecifying-expect. | 13:06 |
| jodh | dottedmag: note the big warning which covers your scenario at the start of the respawn section. | 13:06 |
| dottedmag | I see, thanks. | 13:08 |
| dottedmag | Hmm. But the job does not get respawned. Log file only shows single attempt to run it. | 13:26 |
| SpamapS | jodh: why doesn't init-checkconf ever work? | 14:06 |
| SpamapS | jodh: I say that as it now works for me. But the other day, it didn't. | 14:06 |
| SpamapS | jodh: n/m ;) | 14:07 |
| jodh | SpamapS: sorry, without more details I don't know. Can you raise a bug if you can recreate? | 14:13 |
| dottedmag | Where do the upstart log messages go? I have started it with --verbose, but the only place I see those messages is /var/log/dmesg and only up to DM start moment. | 15:00 |
| * dottedmag slaps his forehead | 15:00 | |
| dottedmag | dmesg :) | 15:00 |
| slangasek | Laney: updating upstart in unstable is on my List, but not a top priority currently | 15:00 |
| Laney | k | 15:00 |
| dottedmag | I've got a situation when daemon fails on startup and upstart does not cause it to be restarted: http://pastebin.com/ePciMNWw | 15:16 |
| dottedmag | zabbix_agent fails and (trivial fork/fork/exit) daemon-exit does not. | 15:16 |
| dottedmag | zabbix_agent does not do anything weird on startup: http://pastebin.com/0mkKvg1d | 15:18 |
| * xnox thought it needs to start to be respawned.... | 15:18 | |
| xnox | e.g. respawned if it segfaults / killed / etc. not when it gracefully exits. | 15:19 |
| dottedmag | It exits with exit code 255 | 15:19 |
| dottedmag | Also, if I just run /bin/false, it gets respawned to matter what. | 15:19 |
| dottedmag | And zabbix_agent gets stuck in start/running state. | 15:19 |
| jodh | dottedmag: are you aware that zabbix-agent has already been packaged for Upstart in Ubuntu? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/zabbix/saucy/view/head:/debian/zabbix-agent.upstart | 15:24 |
| dottedmag | jodh: I am aware of it, but have a look at bugtracker. | 15:26 |
| dottedmag | Also, I need 2.2 (not yet released one). | 15:26 |
| dottedmag | Anyway, now I can reproduce the error without zabbix_agent. | 15:27 |
| dottedmag | Please have a look: https://bugs.launchpad.net/upstart/+bug/1182943 -- this one is distilled to bare minimum. | 15:35 |
| jodh | dottedmag: this is not a bug in upstart so much as an incorrect .conf file - /bin/false does *not* fork twice, but you've told upstart it does... | 15:37 |
| dottedmag | jodh: Yes. But it's upstart's job to handle failing daemons properly. | 15:38 |
| jodh | ...which it does perfectly well when provided with a valid .conf file. | 15:38 |
| dottedmag | Uhm. | 15:38 |
| jodh | dottedmag: upstart cannot "guess" how your app works I'm afraid, hence "expect". | 15:38 |
| dottedmag | zabbix_agent checks the configuration and exits if it is incorrect. Otherwise it forks twice and runs. | 15:39 |
| dottedmag | How should I write a .conf in this case? | 15:39 |
| jodh | dottedmag: does zabbix have an option to "just check its config file and exit"? If so, put that call in a pre-start section which will stop the main job process starting in case of an invalid config file. | 15:40 |
| dottedmag | jodh: just had a look. Nope, it does not. | 15:40 |
| dottedmag | Hum-hum. I think I can abuse one of the options for this check. | 15:41 |
| dottedmag | Still. | 15:41 |
| dottedmag | If you look at log file, upstart correctly saw abrupt termination of daemon (and proper PID), so it seems to be just a matter of event ordering. | 15:43 |
| dottedmag | jodh: thanks for suggestion. | 15:45 |
| jodh | dottedmag: yes, "-t" is ripe for abuse fwics. | 15:45 |
| dottedmag | I still feel it's kind of shaky to rely on daemons always reaching their intended number of forks and not failing before. | 15:46 |
| dottedmag | I'll have a look, might be it is not hard to fix | 15:46 |
| jodh | dottedmag: the problem is the "respawn" - upstart cannot restart an app until that app has fully started (and then exited). | 15:51 |
| jodh | dottedmag: in your case, another consideration is how the config file became invalid in the first place. | 15:52 |
| jodh | dottedmag: the zabbix one that is. | 15:52 |
| dottedmag | jodh: that's just a syntax error, and I am not really worried about it. | 15:53 |
| dottedmag | jodh: I am worried about job being in start/running state, while no service is actually running. | 15:53 |
| dottedmag | Uhm, -t does not check config. Wonderful. | 16:12 |
| jodh | dottedmag: you might be able to use a "post-start" stanza to sniff around and determine if the agent started or not and just call "stop" if it isn't to tell upstart that it has died. | 16:27 |
| dottedmag | jodh: I will probably just add no-fork option to agent, seems much simpler. | 16:28 |
| jodh | dottedmag: frankly, most daemons provide such an option. And one to check any config file they use. | 16:28 |
| dottedmag | Yes, zabbix seems to be a bit... antique. | 16:28 |
| jodh | dottedmag: I was going to say "unique", but yeah ;) | 16:28 |
| === crank_ is now known as crank | ||
| === dottedma1 is now known as dottedmag | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!