[10:11] <_ion> keybuk: An idea: an optional, purely informative "triggers" stanza that lists the events the job (either script or the daemon) may trigger, e.g. a hald job might contain "triggers block-device-added" and a mount job might contain "triggers path-mounted fhs-filesystem". That would make it easy to 1) grep event.d/* for "starts on jobname" and 2) visualize the relations between jobs programmatically.
[10:12] <Keybuk> could be just a normative comment?
[10:12] <_ion> Yes.
[10:13] <_ion> Just like "author" and "description". :-)
[10:13] <Keybuk> true, true
[10:13] <Keybuk> description is actually useful, as you have to describe the job in listings
[10:15] <_ion> For example, a GUI for managing jobs might display a list of jobs that act on events the currently selected job may trigger.
[10:16] <_ion> When you click "hal", it lists "check-filesystem" and when you click it, it lists "mount".
[10:17] <_ion> Also cool graphviz graphs would be possible. ;-)
[10:18] <Keybuk> true
[10:18] <Keybuk> a bit like Java's "throws" ?
[10:18] <Keybuk> :p
[10:19] <ajgenius> hmm ok. question the first. From todo - "Per-user services" "for "root-user services" but not for jobs/tasks", I am trying to figure out what that means, and what the intent is for User level services down the road
[10:20] <_ion> keybuk: Well, a bit like it. :-)
[10:21] <Keybuk> well, the obvious thing is for users to be able to register services to be run on their behalf
[10:22] <Keybuk> so I can have an hourly script run
[10:22] <Keybuk> or even daemons run for me
[10:22] <Keybuk> PAM needs to be used to set up the session properly
[10:22] <Keybuk> the root bit is that the root _user_ should be able to register services/tasks
[10:23] <Keybuk> and thus be run with PAM to set up the session
[10:23] <Keybuk> which is different from those in /etc/event.d which should not be run in a PAM session, maybe
[10:24] <_ion> I'd assume the root user's jobs to be different from the /etc/event.d jobs similarly as the root user's crontab is different from the system crontab.
[10:24] <_ion> I mean the semantical difference, not the technical difference.
[10:25] <Keybuk> indeed
[10:25] <Keybuk> the technical difference is the same, actually
[10:27] <ajgenius> ok. hm.
[10:28] <ajgenius> the thing I am trying to understand is the long term goal for user level integration, in regards to allowing users to have purely user session jobs and scripts.
[10:28] <ajgenius> and I am not finding any real information on goals regarding that in the docs or todo's :)
[10:28] <Keybuk> well, it depends what you mean by "user session" at this point?
[10:30] <ajgenius> I mean.. desktop situation. the user wants to register a task to do some operation on their files, by them, (they wouldn't think of it in the terms of sessions), on given events
[10:30] <Keybuk> the lack of information doesn't mean anything other than I haven't written it down in stone yet, and am still thinking about it and taking suggesions
[10:30] <Keybuk> right, but would these tasks need access to running X desktops?
[10:31] <_ion> mkdir -p ~/.event.d; vim ~/.event.d/job ... :wq and it just works. :-)
[10:31] <ajgenius> sometimes yes sometimes no. that would be a task level dependency
[10:31] <Keybuk> there's several levels of thing:
[10:31] <_ion> (As long as the bofh hasn't disabled it)
[10:31] <Keybuk> - new system session (process group and session)
[10:31] <Keybuk> - new user session
[10:31] <Keybuk> - existing user's session
[10:32] <Keybuk> the second is "switch to the user, create a new session, login that session, run the task"
[10:32] <Keybuk> the third is run the task for a user that is logged in
[10:32] <Keybuk> which is an interesting case all to itself
[10:32] <Keybuk> but potentially conflicting with a desktop session manager
[10:32] <ajgenius> right. I am interesting in both the latter cases
[10:32] <ajgenius> mostly the last however
[10:33] <Keybuk> it's definitely something that's worth serious thought
[10:33] <ajgenius> one of the problems is for example - right now we have "hald" for gnome integration, which handles hardware events etc. thats nice and interesting, but it doesn't allow much real integration on a user level
[10:34] <Keybuk> there's been some interesting discussion about that on the dbus mailing list last week
[10:35] <ajgenius> I think most of that belongs in an upstart space.
[10:36] <ajgenius> otherwise we have multiple event based systems for different kinds of things
[10:40] <Keybuk> which part though?
[10:40] <ajgenius> which part of what?
 I think most of that belongs in an upstart space.
[10:40] <Keybuk> you wouldn't have upstart monitoring battery levels, for example?
[10:40] <ajgenius> yes. anything to do with handling events and starting jobs
[10:41] <ajgenius> Keybuk: that wouldn't be IN upstart. but there is no reason not to have a way of registering new events of that nature into upstart space
[10:42] <ajgenius> the event daemon is something which recieves events, and starts jobs. it doesn't generate the events. something else does
[10:42] <Keybuk> +----------------------+
[10:42] <Keybuk> |  gnome-power-manager |
[10:42] <Keybuk> +-------+--------------+
[10:42] <Keybuk> |  HAL  |              |
[10:42] <Keybuk> +-------+              +-----------------+
[10:42] <Keybuk> |           D-Bus      | Suspend Scripts |
[10:42] <Keybuk> +----------------------+-----------------+
[10:42] <Keybuk> |                   Upstart              |
[10:42] <Keybuk> +----------------------------------------+
[10:42] <Keybuk> that kind of thing?
[10:43] <_ion>    
[10:43] <ajgenius> ehm
[10:43] <Keybuk> _ion: ?
[10:43] <_ion> Just some line drawing characters for cooler boxes. ;-)
[10:44] <Keybuk> _ion: harder to type than just '-' :p
[10:44] <_ion> Hehe.
[10:44] <Keybuk> gnome-power-manager receives information from HAL that indicates the battery is critical
[10:44] <Keybuk> so it issues a battery critical event
[10:44] <ajgenius> Keybuk: yes and no. gnome-power-manager is on top of HAL, but what should trigger it to start in the first place?
[10:44] <Keybuk> which upstart receives and runs the suspend scripts for
[10:44] <Keybuk> that's another point
[10:45] <Keybuk> we know that HAL and the D-Bus system daemon are run by upstart
[10:45] <Keybuk> but what runs the D-Bus session daemon, and gnome-power-manager?
[10:46] <_ion> It would be quite cool if upstart were abstracted as much to allow _it_ to be the desktop session manager.
[10:46] <ajgenius> thats the point I care about - there are a lot of really cool things that can be done from a user POV. but forcing multiple levels of start abstraction actually detracts what can be done. if they can all be started by the same thing - now in this case I think that perhaps an upstart user level daemon.
[10:47] <ajgenius> each user starts its own instance of a user only upstart - which gets events from the main system, but can only start them in that users context
[10:48] <ajgenius> that allows a single point of origin for anything in that users space
[10:48] <ajgenius> _ion: yeah exactly. thats a large part of it
[10:48] <Keybuk> kinda, you end up with two ... started by the X session manager or started by upstart
[10:48] <ajgenius> but it wouldn't JUST be a "desktop" dession manager it would be a user space manager. desktop
[10:49] <ajgenius> is really seperate at that point.
[10:49] <ajgenius> Keybuk: why would the X session manager have anything to do with it :)
[10:50] <ajgenius> it just starts a user session. why not make what it starts, a user level upstart.
[10:50] <theCore> why would you want upstart as your desktop-manager?
[10:50] <Keybuk> ajgenius: it doesn't just do that though
[10:50] <Keybuk> an X session manager actually does a whole bunch of stuff
[10:50] <Keybuk> http://live.gnome.org/SessionManagement
[10:51] <Keybuk> also there's
[10:51] <Keybuk> http://freedesktop.org/wiki/Standards_2fautostart_2dspec
[10:51] <ajgenius> yes I know about them
[10:52] <maro_> why not just hook users up to the system upstart? (as it looks to be the current plan)
[10:52] <Keybuk> would upstart need to implement those?
[10:52] <ajgenius> Keybuk: no
[10:52] <ajgenius> well and yes ;)
[10:52] <Keybuk> maro: there isn't any current plan in this regard
[10:52] <ajgenius> hmm
[10:52] <Keybuk> ajgenius: see, this is where the lines to me get fuzzy
[10:52] <ajgenius> Autostart Specificatio
[10:53] <maro_> Keybuk: I was thinking of the "on ~scott/..." examples I found somewhere
[10:53] <ajgenius> Keybuk: its clear to me. upstart doesn't DO any of those things. it just recieves events, and starts jobs
[10:53] <Keybuk> maro_: those are just for "new temporary session" jobs (e.g. cron/atd)
[10:53] <ajgenius> thats it. in the rough ;)
[10:54] <Keybuk> X sessions are odd anyway
[10:54] <Keybuk> as they're not true sessions, they're just a bunch of background processes without controlling terminal that happen to share some environment variables
[10:55] <ajgenius> personally I see no REASON to have the autostart specification persay. in the sense that, in terms of events, everything in a desktop environment depends on core parts of the desktop to start first, its desktop dependent. aka jobs
[10:55] <ajgenius> and events
[10:56] <Keybuk> it certainly makes an amount of elegant sense to have upstart start things like the panel
[10:56] <ajgenius> thats kind of it. you might have a "session management" daemon that upstart begins first
[10:56] <Keybuk> but then you wonder whether upstart should receive a "user clicked a launcher" event, which causes upstart to start openoffice
[10:56] <ajgenius> to handle autosave stuff
[10:56] <Keybuk> and I'm not sure at which point the line between genius and insanity gets crossed yet
[10:56] <ajgenius> Keybuk: no
[10:57] <ajgenius> hum. if someone chooses to use it in that fashion. that is up to them. but it has nothing to do with upstart itself
[10:57] <Keybuk> openoffice ends up being a child of upstart :)
[10:57] <ajgenius> thats not a problem to me
[10:58] <ajgenius> I see no reason it shouldn't be
[10:58] <Keybuk> it is by default
[10:58] <Keybuk> parent process is #1 for most X apps
[10:58] <ajgenius> right
[10:59] <ajgenius> the idea is in effect to make the user space all started as a child of a single point of origin, a user space upstart. thats it
[10:59] <ajgenius> it doesn't have anything to do with the actual processes or gui or whatnot
[10:59] <ajgenius> people could make jobs
[11:00] <ajgenius> that do those sorts of things.
[11:00] <ajgenius> but thats not upstarts concern
[11:01] <ajgenius> so you still will probably need a "session manager", but for example - it handles the other aspects, like close/shutdown things.
[11:01] <ajgenius> but it doesn't need to start them
[11:03] <Keybuk> it doesn't seem unreasonable
[11:04] <ajgenius> that allows everything upstart can do for a system. to be done for just a user. in that users scope. and does it in a GUI and Desktop agnostic fashion
[11:05] <ajgenius> and it would just have system events forwarded to it from the system instance.
[11:05] <Keybuk> I was just thinking about how that would work
[11:05] <Keybuk> sounds a bit dbus-like to me
[11:06] <ajgenius> you could do it on dbus at that level, because the system upstart would already be started. but I don't know if it needs to be
[11:08] <_ion> A user session upstart daemon would give a lot of flexibility for things, e.g. it would be possible to set niceness and environment variables for specific user session jobs.
[11:09] <Keybuk> I'm not immediately sure you need a user session daemon at all
[11:09] <Keybuk> due to the way X has historically worked, all you need is something to register a session with the master daemon
[11:09] <Keybuk> give the DISPLAY, DBUS_*, etc. environment variables
[11:09] <Keybuk> so then init can just include those in anything marked for that "session"
[11:09] <ajgenius> but thats based on X
[11:09] <Keybuk> they don't need to be children of any particular process
[11:10] <ajgenius> hm
[11:10] <theCore> that is what I'm thinking, an user upstart could be just a small program that would send message to upstart
[11:10] <Keybuk> then you would add a new first-class object to upstart ... "session"
[11:10] <Keybuk> jobs might exist in a session or not
[11:10] <ajgenius> but what about starting jobs in user space? who would be the root level? upstart
[11:11] <Keybuk> yes
[11:11] <Keybuk> that's easy
[11:11] <Keybuk> fork ()
[11:11] <Keybuk> setsid ()
[11:11] <Keybuk> setuid ()
[11:11] <Keybuk> exec ()
[11:11] <Keybuk> :p
[11:11] <ajgenius> hm. maybe
[11:11] <Keybuk> nothing X related has a controlling terminal
[11:11] <Keybuk> only the X server itself
[11:11] <ajgenius> but if nothing else it would make the process tree horrible to make sense of in a multiuser environment ;)
[11:11] <Keybuk> so there's no UNIXish signal interaction to worry about here
[11:11] <Keybuk> ps fjax
[11:11] <Keybuk> this is what the process tree looks like *today*
[11:12] <ajgenius> not on my system ;)
[11:12] <Keybuk> note that everything in your X "session" has PID=1
[11:12] <Keybuk> why not on your system?
[11:12] <Keybuk> show me
[11:12] <ajgenius> I can't at the moment because I am booted up under a normal system
[11:12] <ajgenius> but under my normal environment I use a hacked system like what I am talking about
[11:13] <Keybuk> any particular reason?
[11:13] <ajgenius> proof of concept. I started something like upstart about 2 years ago but nobody cared ;)
[11:13] <Keybuk> ahh
[11:13] <Keybuk> so you'd see something like
[11:13] <Keybuk> init
[11:13] <Keybuk> `- X
[11:13] <Keybuk>    `- x-session-manager
[11:14] <Keybuk>       `- user-init
[11:14] <Keybuk>          `- gnome-panel
[11:14] <Keybuk> ?
[11:14] <ajgenius> yes
[11:14] <Keybuk> probably with a "`- gdm" in the middle there somewhere
[11:14] <ajgenius> I called it ProcessManager
[11:14] <ajgenius> but yeah
[11:14] <ajgenius> amazing how what two years ago was a stupid idea is todays big new thing ;)
[11:15] <Keybuk> heh
[11:15] <Keybuk> I've not yet managed to convince anyone inside the Boston Conspiracy that this is a good thing yet
[11:16] <ajgenius> hehe
[11:16] <Keybuk> Havoc does seem interested though
[11:16] <ajgenius> I never managed to get as big a following as you though(or any at all), so thats something. at least you have momentum to make this idea actually work :)
[11:16] <Keybuk> don't suppose, btw, you could write a summary mail about the above and post it to the mailing list?
[11:17] <Keybuk> well, we have a distro ;)  that's a big help
[11:17] <ajgenius> hm
[11:19] <Keybuk> if it works, Ubuntu will rock because of it, and everyone else will adopt it
[11:19] <Keybuk> if it doesn't work, then it doesn't
[11:20] <ajgenius> it will work :)
[11:20] <Keybuk> I just mean upstart in general
[11:20] <ajgenius> the concept is sound, and as I say. I have been running on it for a long time now.
[11:21] <ajgenius> Keybuk: sure it will
[11:21] <ajgenius> :)
[11:22] <ajgenius> I mean. just conceptually it really makes integration into the new udev design system a lot easier
[11:24] <Keybuk> yeah
[11:24] <Keybuk> next is a matter of integrating it with dbus and HAL properly
[11:24] <johnnybuoy> dbus??
[11:24] <Keybuk> johnnybuoy: message passing bus
[11:24] <johnnybuoy> doesn't that slow down the machine horribly.
[11:24] <johnnybuoy> ??
[11:24] <Keybuk> no?
[11:24] <johnnybuoy> yes?
[11:25] <ajgenius> why would it?
[11:25] <Keybuk> it's just an IPC bus
[11:25] <Keybuk> how one program tells another that something happened
[11:25] <johnnybuoy> i mean the cpu has to put itself into adm. mode everytime a message comes or goes
[11:25] <Keybuk> is logical for upstart to be able to start and stop things because of dbus broadcast messages
[11:25] <Keybuk> err?
[11:25] <johnnybuoy> hmm
[11:25] <Keybuk> what's "adm. mode" ?
[11:26] <LarstiQ> supervisor?
[11:26] <johnnybuoy> i don't remember the word :(
[11:26] <johnnybuoy> but the cpu has two modes?
[11:26] <Keybuk> you're thinking of a Mach-like kernel aren't you?
[11:26] <johnnybuoy> CONTEXT SWITCH i think
[11:26] <johnnybuoy> right
[11:26] <Keybuk> where the entire kernel is based on message-passing?
[11:26] <Keybuk> dbus is just a user-space process for passing messages between user processes
[11:26] <LarstiQ> L4 shows that can be quite fast.
[11:27] <johnnybuoy> ahh, so no context switch
[11:27] <Keybuk> it's how gnome power manager can tell the screensaver you're on battery, so don't waste power bouncing cows and just blank the screen
[11:27] <johnnybuoy> yet l4 doesn't even have userlan tools to do proof-of-concept
[11:28] <LarstiQ> proof-of-concept of what?
[11:28] <johnnybuoy> that the linux drivers an 'really' be run in userland as servers
[11:28] <johnnybuoy> s/an/can
[11:29] <johnnybuoy> i tested it, it got me to a pretty screen that was mooving fast, bu no user interaction at all
[11:29] <LarstiQ> L4 isn't really interested in that either.
[11:29] <LarstiQ> Perhaps you are thinking of linux-on-l4?
[11:29] <johnnybuoy> bu if dbus doesn't need those context switching..
[11:33] <ajgenius> dbus isn't in kernel space. its in user space space. thats a whole different concept then a messaging bus in kernel
[11:36] <_ion> ajgenius: Excuse my ignorance, but what is "the new udev design system"?
[11:38] <Keybuk> kernel sends events when stuff changes
[11:38] <_ion> Isn't that how udev has worked for a long time?
[11:39] <_ion> I.e. listening to uevent?
[11:39] <johnnybuoy> my ISP is ging me crap, sorry, but in the lat 5-10 minutes i wasn't here...didn't miss me ehh?;)
[11:50] <ajgenius> _ion: uevents etc is new
[11:52] <ajgenius> as in, for proper functionality it requires a 2.6.15(16?) kernel iirc
[11:52] <ajgenius> it completely replaces hotplug now
[11:53] <ajgenius> before it just integrated with it
[11:53] <ajgenius> there is some documentation if you want to read up on the history and the recent changes :)
[11:58] <ajgenius> its one of the important reasons for upstart NOW
[12:00] <ajgenius> before it was just a good idea. now its almost necesary