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