tgies | so, apologies if i'm out of date, because all the info i could find on this was really old | 09:23 |
---|---|---|
tgies | but is there a sound way to get upstart to run a daemon as a given user | 09:24 |
tgies | i don't want it to be getting file handles as root or anything | 09:25 |
TeTeT | anybody has seen an upstart job not returning on 'sudo stop <jobname>' and the job not being terminated> | 09:44 |
TeTeT | ? | 09:44 |
ion | What does initctl status jobname say? | 10:30 |
ion | tgies: For now, use su | 10:31 |
tgies | fair enough | 10:35 |
TeTeT | ion: it says identd stop/spawned, process 1095. Though the process still runs | 10:35 |
ion | “exec su -c 'exec command' user” to avoid leaving extraneous shells around | 10:36 |
ion | tetet: Is its pid 1095? | 10:36 |
TeTeT | ion: yes, it is | 10:36 |
ion | Curious | 10:36 |
ion | What happens if you kill the process manually? | 10:36 |
TeTeT | ion: it's gone and 'sudo status identd' says 'identd stop/waiting' | 10:39 |
TeTeT | starting it with 'sudo start identd' works just fine then | 10:39 |
ion | Anything interesting in syslog? Also, please pastebin the job definition. | 10:40 |
TeTeT | ion: http://pastebin.ubuntu.com/473444/ | 10:41 |
TeTeT | ion: maybe the 'expect daemon' is wrong? | 10:41 |
TeTeT | ion: it seems so, I commented it and now I can start/stop the job | 10:41 |
ion | Yeah, the ‘expect’ stanza in the current release of Upstart only supports very specific cases of forking programs, and it’s very easy to confuse it. The 0.10 release will have a much better implementation of following processes that daemonize. If one doesn’t know *exactly* how the main process daemonizes itself, better just launch it in a way that it doesn’t daemonize at all and not use ‘expect’. | 10:44 |
TeTeT | ion: ok, thanks. pidentd seems to be tailored for use through identd regularly, so the '-b' option makes it a daemon. But if the expect clause is not needed it's all good. Thanks for your interest and help | 10:50 |
tgies | how do i go about telling upstart that yes, the job really is stopped, when the status is "start/killed" with an invalid pid | 11:36 |
ion | As i said, it’s very easy to confuse it... Would it be okay to reboot? :-P | 11:37 |
tgies | maybe | 11:39 |
ion | Here’s a horrible kluge if not: http://heh.fi/tmp/workaround-upstart-snafu | 11:41 |
ion | ./workaround-upstart-snafu N, where N is the pid from initctl status. | 11:41 |
tgies | i was su -c'ing as a user that i didn't realize had its login shell set to /bin/false | 11:42 |
tgies | and upstart got really mad | 11:42 |
tgies | wow ok | 12:01 |
tgies | it's having a hideous time trying to trace out the pid of my ircd | 12:01 |
tgies | i think it needs to follow through a few more forks than "expect daemon" allows for | 12:04 |
tgies | and it's coming up short | 12:04 |
ion | Why fork more than twice to daemonize? | 12:13 |
tgies | well, for one thing, this is being su -c'd so it can run as an unprivileged user | 12:16 |
tgies | and i think that might be affecting what pid ends up getting tracked. | 12:17 |
tgies | it ends up tracking pid 1191 when the correct pid is 1193 | 12:21 |
ion | Probably best to make the ircd not fork. | 12:22 |
tgies | (for instance) | 12:22 |
tgies | hmm, don't know if i can | 12:22 |
tgies | okay, i did | 12:35 |
tgies | eh. now it ends up with the pid of the sh -c /path/to/ircd | 12:36 |
* cwillu_at_work huggles tgies | 12:37 | |
cwillu_at_work | somebody who shares my "run as user" woes :) | 12:37 |
ion | exec su -c 'exec /path/to/ircd' ... | 12:39 |
tgies | oh piss i forgot about freaking exec(2) | 12:42 |
tgies | thanks | 12:42 |
tgies | hmmm | 12:49 |
tgies | THAT'S fine now | 12:49 |
tgies | but it still gets lost and hangs on "stop ircd" | 12:49 |
tgies | weird | 12:50 |
ion | And there’s no ‘expect’ stanza? | 12:50 |
tgies | the process goes away but it never returns and it never changes job state | 12:50 |
ion | What does initctl status jobname say? | 12:51 |
cwillu_at_work | tgies, do you have a post-start or -stop script? | 12:51 |
cwillu_at_work | stop ircd won't return until that finishes iirc | 12:52 |
tgies | cwillu_at_work: that would be the obvious culprit but no | 12:56 |
tgies | hmm, i can't get it to break again | 12:56 |
tgies | interesting | 12:56 |
tgies | it all works fine now, and that bothers me | 12:56 |
cwillu_at_work | did you modify it while it was running maybe? | 12:56 |
tgies | don't think so | 12:58 |
Keybuk | mbiebl: BOF was good | 17:56 |
Keybuk | post-BOF corridor was also good | 17:56 |
mbiebl | followed it via the live-stream | 17:57 |
mbiebl | fwiw, I think continuing to ship sysv init scripts and installing the upstart scripts in parallel is the way to go for Debian | 17:59 |
mbiebl | This way the kfreebsd case is solved | 18:00 |
Keybuk | yeah I think so | 18:00 |
Keybuk | and the chroot case | 18:00 |
mbiebl | I guess we just need a bit of magic in /etc/init.d/rc and /lib/lsb/init-functions | 18:00 |
Keybuk | insserv in Debian | 18:01 |
Keybuk | but yeah, rc too | 18:01 |
Keybuk | we could do it as a | 18:01 |
Keybuk | # X-Upstart-Job: xxx | 18:01 |
Keybuk | comment | 18:01 |
Keybuk | that gets looked for if sys-rc/inserv are running under Upstart instead of sysvinit | 18:01 |
mbiebl | or the simple convention, that if /etc/init.d/rc finds a file named <service>.conf in /etc/init, it skips running /etc/init.d/<service> | 18:02 |
mbiebl | But the # X-Upstart-Job: is more flexibel | 18:03 |
mbiebl | in case a sysv init script is replaced by several upstart jobs | 18:03 |
mbiebl | or vice versa, i.e. there is no direct match between the sysv and upstart job name | 18:04 |
mbiebl | continuing shipping sysv init scripts also gives people the comfy feeling, that they can easily switch back :-) | 18:07 |
Keybuk | right that's what I thought | 18:16 |
Keybuk | since then you can do deps and stuff | 18:16 |
goraxe | hi, I'm trying to code a 'user' stanzer for upstart | 21:57 |
goraxe | I'm trying to figure out the test suite, I can't seem to figure out the TEST_ALLOC_FAIL macro ... | 21:58 |
goraxe | I'm getting this error as a result of running the tests (null):alloc.c:634: Assertion failed in nih_unref: ref != NULL | 21:59 |
Keybuk | right, sounds like the first argument to nih_unref is NULL? :-) | 22:03 |
goraxe | okay, is nih_unref called by nih_free? | 22:05 |
goraxe | http://pastebin.com/RRMgMEeg | 22:06 |
goraxe | is the test function | 22:06 |
Keybuk | posssssibly | 22:07 |
Keybuk | you can't pass NULL to any nih function | 22:07 |
AlanJenkins | evening all | 22:08 |
Keybuk | evening AlanJenkins | 22:08 |
AlanJenkins | hey Keybuk =) | 22:08 |
AlanJenkins | anyone here running arch linux with upstart? | 22:09 |
goraxe | Keybuk: I have pushed my current code to https://code.launchpad.net/~goraxe/upstart/user_sid | 22:10 |
AlanJenkins | anyone know if there is an archive of upstart job definitions? I am trying to write some jobs for arch linux and could do with some example jobs to learn from | 22:15 |
AlanJenkins | i have the ones that come with upstart but they are a little basic | 22:15 |
Keybuk | goraxe: where are you getting the assertion error? | 22:16 |
Keybuk | AlanJenkins: Ubuntu is probably the easiest place | 22:16 |
Keybuk | goraxe: oh, scratch that | 22:17 |
Keybuk | goraxe: pretty obvious - you never initialise job->user to NULL in job_new | 22:17 |
AlanJenkins | Keybuk: hmmm ok will have to grab a copy of ubuntu and run it in a vm | 22:17 |
goraxe | Keybuk: thanks | 22:17 |
AlanJenkins | thought that may be the case but thought i would ask =) | 22:17 |
AlanJenkins | thanks Keybuk | 22:17 |
Keybuk | np | 22:18 |
goraxe | was a bit of a quick cnp job to try and learn the code base | 22:18 |
Keybuk | chrome os is another good source | 22:18 |
AlanJenkins | mmm forgot about that one... think i have the image knocking around somewhere too | 22:19 |
AlanJenkins | will check chrome first i think | 22:19 |
AlanJenkins | B/quit | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!