[00:00] <jtane> xnox: it works well
[00:00] <jtane> xnox: except no events?
[00:00] <xnox> jtane: on the other hand if nobody directly logs into the server. you can simpy use "setuid" in a custom upstart job.
[00:00] <xnox> jtane: there are still /some/ events & you can emit your own if there is need.
[00:01] <jtane> xnox: true, i guess i was hoping to hook network or filesystem on boot
[00:01] <xnox> jtane: you can / should be able to do so with "user jobs"
[00:01] <jtane> xnox: as the user will probably never actually login
[00:02] <xnox> jtane: if the user never logs in, it might be better to use a system job with "setuid" or crontab with @reboot.
[00:03] <jtane> xnox: i guess i take that back, they may need to login at some point and start and stop their services
[00:03] <jtane> xnox: so requiring root here is a pain
[00:04] <xnox> jtane: experiment a little =)))) i see. I haven't done user jobs in a while (no longer deal with webops stuff). But if you try to do something and it doesn't work, just shout out with a sample job.
[00:04] <xnox> and I am sure one of the regulars here will help you out =)
[00:05] <jtane> xnox: how would you feel about a system job that loops over users and starts the jobs using something like ```sudo -u $USER -H $HOME start $SERVICE```
[00:06] <jtane> xnox: just to have a boot hook
[00:06] <jtane> xnox: everything else seems to work well
[00:07] <jtane> xnox: ps, thx for your help
[00:10] <jtane> xnox: better example - https://gist.github.com/4281324
[00:16]  * xnox ponders if there is a way to emit the dbus call and autostart user jobs.
[00:18] <jtane> xnox: interesting - https://bugs.launchpad.net/upstart/+bug/1065965
[00:20] <xnox> jtane: =)))) yeah... so for "upstart user sessions" we are working on playing back / re-emiting important events such as network-up for the user jobs.
[00:21] <xnox> it would help to fix the above bug.
[00:22] <jtane> xnox: i guess the workaround he suggests (wait for dbus then emit a user-jobs event) is good enough for now
[00:27] <jtane> xnox: er, i guess for any of this to work, my system job needs to manually create user sessions? how can i start a user session as root?
[00:30] <slangasek> that's the trick, isn't it? :)
[00:31]  * xnox is pondering this in my head, but i am not sure 
[00:31] <slangasek> starting user jobs without an associated user login session is non-obvious
[00:31] <slangasek> certainly in the general case, jobs can't be expected to work the same way when started from a user session than when not
[00:32] <slangasek> because of things like kerberos credentials / afs tokens, ecryptfs home directories, etc
[00:32] <xnox> slangasek: pushed gtkdoc branch update. but not doing debian nmu tonight, had christmas party drinks.
[00:32] <slangasek> xnox: does the user sessions spec have any concept of a "login-session-started" event?
[00:32] <slangasek> (I guess we should have such a thing)
[00:33] <slangasek> xnox: hmph, there's no legal limit on Debian upload alcohol level ;)
[00:35] <xnox> slangasek: yeah, but there are people who like to lol at typpos on OFTC ;-)
[00:36] <xnox> slangasek: it's best you ask stgraber about the "login-session-started" event. he had some ideas on how to do that and also notify about the state of machine at login, e.g. networking events may have been missed but user-jobs should still find out about them.
[00:39] <jtane> sort of grasp some of this... essentially the problem is that job dependencies may, in turn, depend on a login session for the process owner?
[00:40] <jtane> also, is there a diff between the terms "login session" and "user session"?
[00:42] <xnox> jtane: currently we use both interchangeably with roughly the same meaning and we have not yet formally defined the meaning of either of those.
[00:42] <jtane> xnox: ok thx
[00:43] <xnox> jtane: upstart has currently support for "sessions" - where pid 1 manages "user jobs" & "upstart in chroot jobs"
[00:43] <xnox> jtane: and there is the bright undefined future of "login sessions" / "upstart managed user sessions"
[00:43] <xnox> it is probably best to speak of "login sessions" as the brave new, yet to be defined future.
[00:46] <jtane> i guess i'm confused as to why upstart cares about whether a user has a "session"
[00:46] <jtane> i imagine "user jobs" as simply processes owned by a certain user that could be started and stopped by that user...
[00:46] <jtane> maybe i'm missing something big here
[00:56] <slangasek> xnox: oh, midair collision with your libnih branch, stgraber uploaded something :)
[00:56] <stgraber> ah yeah, I uploaded my libnih fix this morning :)
[00:57] <xnox> no worries =)
[00:57]  * xnox will fix it up.... (look at the clock) later today =)
[01:27] <jtane> hey so i just tested this: https://gist.github.com/4281324
[01:28] <jtane> works great
[01:28] <jtane> is "start" automatically creating user sessions?
[01:30] <jtane> or do i even need to be conscious of "sessions" if this works?
[01:32] <xnox> you should be good to go, things may change with new world order in the future type sessions.... but if they do, it should improve stuff to e.g. hopefully not require above hack.
[01:33] <jtane> xnox: right, just wanted to check and make sure i'm not doing anything insane (i still don't think i grasp sessions)
[01:35] <jtane> thanks a lot everyone for your help!
[22:40] <tgm4883> I've created a new upstart job (followed http://upstart.ubuntu.com/getting-started.html ) and placed it in /etc/init/ and rebooted, but it still says "unknown job" when trying to work with it. Is there a better set of instructions somewhere?