[09:23] <tgies> so, apologies if i'm out of date, because all the info i could find on this was really old
[09:24] <tgies> but is there a sound way to get upstart to run a daemon as a given user
[09:25] <tgies> i don't want it to be getting file handles as root or anything
[09:44] <TeTeT> anybody has seen an upstart job not returning on 'sudo stop <jobname>' and the job not being terminated>
[09:44] <TeTeT> ?
[10:30] <ion> What does initctl status jobname say?
[10:31] <ion> tgies: For now, use su
[10:35] <tgies> fair enough
[10:35] <TeTeT> ion: it says identd stop/spawned, process 1095. Though the process still runs
[10:36] <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:39] <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:40] <ion> Anything interesting in syslog? Also, please pastebin the job definition.
[10:41] <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:44] <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:50] <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
[11:36] <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:37] <ion> As i said, it’s very easy to confuse it... Would it be okay to reboot? :-P
[11:39] <tgies> maybe
[11:41] <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:42] <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
[12:01] <tgies> wow ok
[12:01] <tgies> it's having a hideous time trying to trace out the pid of my ircd
[12:04] <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:13] <ion> Why fork more than twice to daemonize?
[12:16] <tgies> well, for one thing, this is being su -c'd so it can run as an unprivileged user
[12:17] <tgies> and i think that might be affecting what pid ends up getting tracked.
[12:21] <tgies> it ends up tracking pid 1191 when the correct pid is 1193
[12:22] <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:35] <tgies> okay, i did
[12:36] <tgies> eh. now it ends up with the pid of the sh -c /path/to/ircd
[12:37]  * cwillu_at_work huggles tgies 
[12:37] <cwillu_at_work> somebody who shares my "run as user" woes :)
[12:39] <ion> exec su -c 'exec /path/to/ircd' ...
[12:42] <tgies> oh piss i forgot about freaking exec(2)
[12:42] <tgies> thanks
[12:49] <tgies> hmmm
[12:49] <tgies> THAT'S fine now
[12:49] <tgies> but it still gets lost and hangs on "stop ircd"
[12:50] <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:51] <ion> What does initctl status jobname say?
[12:51] <cwillu_at_work> tgies, do you have a post-start or -stop script?
[12:52] <cwillu_at_work> stop ircd won't return until that finishes iirc
[12:56] <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:58] <tgies> don't think so
[17:56] <Keybuk> mbiebl: BOF was good
[17:56] <Keybuk> post-BOF corridor was also good
[17:57] <mbiebl> followed it via the live-stream
[17:59] <mbiebl> 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] <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:01] <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:02] <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:03] <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:04] <mbiebl> or vice versa, i.e. there is no direct match between the sysv and upstart job name
[18:07] <mbiebl> continuing shipping sysv init scripts also gives people the comfy feeling, that they can easily switch back :-)
[18:16] <Keybuk> right that's what I thought
[18:16] <Keybuk> since then you can do deps and stuff
[21:57] <goraxe> hi, I'm trying to code a 'user' stanzer for upstart
[21:58] <goraxe> I'm trying to figure out the test suite, I can't seem to figure out the TEST_ALLOC_FAIL macro ...
[21:59] <goraxe> 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] <Keybuk> right, sounds like the first argument to nih_unref is NULL? :-)
[22:05] <goraxe> okay, is nih_unref called by nih_free?
[22:06] <goraxe> http://pastebin.com/RRMgMEeg
[22:06] <goraxe> is the test function 
[22:07] <Keybuk> posssssibly
[22:07] <Keybuk> you can't pass NULL to any nih function
[22:08] <AlanJenkins> evening all
[22:08] <Keybuk> evening AlanJenkins
[22:08] <AlanJenkins> hey Keybuk =)
[22:09] <AlanJenkins> anyone here running arch linux with upstart?
[22:10] <goraxe> Keybuk: I have pushed my current code to https://code.launchpad.net/~goraxe/upstart/user_sid
[22:15] <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:16] <Keybuk> goraxe: where are you getting the assertion error?
[22:16] <Keybuk> AlanJenkins: Ubuntu is probably the easiest place
[22:17] <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:18] <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:19] <AlanJenkins> mmm forgot about that one... think i have the image knocking around somewhere too
[22:19] <AlanJenkins> will check chrome first i think
[23:10] <AlanJenkins> B/quit