[04:38] <bittu2> how to determine difference between single user mode and run level 1?
[04:38] <bittu2> i'm using centos 6 and i'm trying to see if there is an actual difference between the levels
=== elmo__ is now known as elmo
=== erkules_ is now known as erkules
[08:28] <xnox> bittu2: i'm not familiar with centos 6, but as far as I know by default it only uses init.d scripts. You can inspect those to see if there is any difference. I would not have thought there would be.
[08:30] <xnox> elmo: upstart 1.9-0ubuntu1 is in saucy. If you are after upstart apparmor support, you might need apparmor/kernel from saucy
[08:31] <jodh> xnox: thanks for doing the upload!
[08:32] <jodh> xnox: ...speaking of which, could I bug you about the procenv one? :)
[12:15] <elmo> xnox: no, I'm after the dbus bridge; thanks for letting me know
[12:16] <xnox> elmo: than straight backport should be enough =)
[12:30] <jodh> xnox: lp:~jamesodhunt/upstart/fix-libupstart updated.
[12:30] <xnox> jodh: win! =)
[12:31] <xnox> we should have done that long time ago anyway.... was on the back of my todo list =)
[12:31] <jodh> xnox: yeah, I'd like to understand exactly what's different on 64-bit systems though.
[14:24] <neomantra> hi, i am running on headless a Ubuntu cloud image (Raring with upstart 1.8) and want to use upstart session jobs.   I don't think I'm set up properly for this as I get this error in response to `initctl --user start mjob`:
[14:24] <neomantra> "initctl: UPSTART_SESSION isn't set in the environment. Unable to locate the Upstart instance."
[14:54] <xnox> jodh: ^
[14:54] <xnox> jodh: do we spawn user sessions on servers at all yet?
[14:55] <xnox> and how to do that?
[14:56] <jodh> xnox / neomantra: we don't really support console login environments yet.
[15:00] <jodh> neomantra: you could arrange for the system upstart to start a session init as your user, then "join" that session using something like 'export UPSTART_SESSION=`initctl list|awk '{print $2}'` before running 'start $job', but that assumes there is only 1 session init instance running for the user.
[15:03] <neomantra> thanks for the responses.    ah, using upstart to start the "user upstart" it makes sense
[15:05] <neomantra> my intention is to have services run as a user on cloud servers.    should i not be using upstart for this?  i'm revamping my infrastructure and thought i'd use it instead of start-stop-daemon
[15:48] <xnox> neomantra: if setuid/setgid stanzas are enough, just add system jobs.
[15:49] <xnox> neomantra: traditionally, userids that run webapps/etal shouldn't have login accounts / shell access at all =)
[15:49] <xnox> neomantra: such that those jobs are executed as non-priviledged users.
[15:50] <neomantra> xnox: that's a good point.    but i want users to be able to push configuration and then start/stop jobs...   but not do anything privileged
[15:50] <neomantra> their jobs
[15:51] <xnox> neomantra: for that case, user session / jobs sounds nicer.
[15:53] <neomantra> so i have system upstart starting the "init --user"  with setuid/gid as my user.    still need the upstart session variable.   the "initctl list|awk" doesn't seem to work
[19:22] <elmo> hmm
[19:22] <elmo> configure.ac:11: option `serial-tests' not recognized
[19:22] <elmo> autoreconf: automake failed with exit status: 1
[19:23] <elmo> ah, looks like I need saucy automake ; will file a bug about build-depends
[23:02] <xnox> elmo: or you can remove "serial-tests", introduced in automake1.12. we are in discussion with automake upstream about the whole test issues.
[23:03] <xnox> elmo: i don't think in upstream we have "serial-tests" specified, due to resulting in higher automake dependancy.