=== johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart === j_ack [n=rudi@p508D92B9.dip0.t-ipconnect.de] has joined #upstart === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart === Admiral_Chicago [n=freddy@st0660990722.monm.edu] has joined #upstart === j_ack [n=rudi@p508D92B9.dip0.t-ipconnect.de] has joined #upstart === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart === johnnybuoy0 [n=jano@nilus-268.adsl.datanet.hu] has joined #upstart === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === Ingmar^ [n=ingmar@d51A482FD.access.telenet.be] has joined #upstart === neuralis [n=krstic@solarsail.hcs.harvard.edu] has joined #upstart === xhochy [n=uwe@p54A6BBE1.dip0.t-ipconnect.de] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart === maro_ [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart === theCore [n=alex@modemcable106.200-70-69.mc.videotron.ca] has joined #upstart === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart === Keybuk [n=scott@syndicate.netsplit.com] has joined #upstart === ajgenius [n=andrew@c-68-48-76-28.hsd1.md.comcast.net] has joined #upstart === j_ack [n=rudi@p508D86D0.dip0.t-ipconnect.de] has joined #upstart === Ingmar^ [n=ingmar@244.75-64-87.adsl-dyn.isp.belgacom.be] has joined #upstart [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] could be just a normative comment? [10:12] <_ion> Yes. [10:13] <_ion> Just like "author" and "description". :-) [10:13] true, true [10:13] 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] true [10:18] a bit like Java's "throws" ? [10:18] :p [10:19] 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] well, the obvious thing is for users to be able to register services to be run on their behalf [10:22] so I can have an hourly script run [10:22] or even daemons run for me [10:22] PAM needs to be used to set up the session properly [10:22] the root bit is that the root _user_ should be able to register services/tasks [10:23] and thus be run with PAM to set up the session [10:23] 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] indeed [10:25] the technical difference is the same, actually [10:27] ok. hm. [10:28] 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] and I am not finding any real information on goals regarding that in the docs or todo's :) [10:28] well, it depends what you mean by "user session" at this point? [10:30] 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] 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] 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] sometimes yes sometimes no. that would be a task level dependency [10:31] there's several levels of thing: [10:31] <_ion> (As long as the bofh hasn't disabled it) [10:31] - new system session (process group and session) [10:31] - new user session [10:31] - existing user's session [10:32] the second is "switch to the user, create a new session, login that session, run the task" [10:32] the third is run the task for a user that is logged in [10:32] which is an interesting case all to itself [10:32] but potentially conflicting with a desktop session manager [10:32] right. I am interesting in both the latter cases [10:32] mostly the last however [10:33] it's definitely something that's worth serious thought [10:33] 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] there's been some interesting discussion about that on the dbus mailing list last week [10:35] I think most of that belongs in an upstart space. [10:36] otherwise we have multiple event based systems for different kinds of things [10:40] which part though? [10:40] which part of what? [10:40] I think most of that belongs in an upstart space. [10:40] you wouldn't have upstart monitoring battery levels, for example? [10:40] yes. anything to do with handling events and starting jobs [10:41] 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] the event daemon is something which recieves events, and starts jobs. it doesn't generate the events. something else does [10:42] +----------------------+ [10:42] | gnome-power-manager | [10:42] +-------+--------------+ [10:42] | HAL | | [10:42] +-------+ +-----------------+ [10:42] | D-Bus | Suspend Scripts | [10:42] +----------------------+-----------------+ [10:42] | Upstart | [10:42] +----------------------------------------+ [10:42] that kind of thing? [10:43] <_ion> [10:43] ehm [10:43] _ion: ? [10:43] <_ion> Just some line drawing characters for cooler boxes. ;-) [10:44] _ion: harder to type than just '-' :p [10:44] <_ion> Hehe. [10:44] gnome-power-manager receives information from HAL that indicates the battery is critical [10:44] so it issues a battery critical event [10:44] 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] which upstart receives and runs the suspend scripts for [10:44] that's another point [10:45] we know that HAL and the D-Bus system daemon are run by upstart [10:45] 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] 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] 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] that allows a single point of origin for anything in that users space [10:48] _ion: yeah exactly. thats a large part of it [10:48] kinda, you end up with two ... started by the X session manager or started by upstart [10:48] but it wouldn't JUST be a "desktop" dession manager it would be a user space manager. desktop [10:49] is really seperate at that point. [10:49] Keybuk: why would the X session manager have anything to do with it :) [10:50] it just starts a user session. why not make what it starts, a user level upstart. [10:50] why would you want upstart as your desktop-manager? [10:50] ajgenius: it doesn't just do that though [10:50] an X session manager actually does a whole bunch of stuff [10:50] http://live.gnome.org/SessionManagement [10:51] also there's [10:51] http://freedesktop.org/wiki/Standards_2fautostart_2dspec [10:51] yes I know about them [10:52] why not just hook users up to the system upstart? (as it looks to be the current plan) [10:52] would upstart need to implement those? [10:52] Keybuk: no [10:52] well and yes ;) [10:52] maro: there isn't any current plan in this regard [10:52] hmm [10:52] ajgenius: see, this is where the lines to me get fuzzy [10:52] Autostart Specificatio [10:53] Keybuk: I was thinking of the "on ~scott/..." examples I found somewhere [10:53] Keybuk: its clear to me. upstart doesn't DO any of those things. it just recieves events, and starts jobs [10:53] maro_: those are just for "new temporary session" jobs (e.g. cron/atd) [10:53] thats it. in the rough ;) [10:54] X sessions are odd anyway [10:54] 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] 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] and events [10:56] it certainly makes an amount of elegant sense to have upstart start things like the panel [10:56] thats kind of it. you might have a "session management" daemon that upstart begins first [10:56] but then you wonder whether upstart should receive a "user clicked a launcher" event, which causes upstart to start openoffice [10:56] to handle autosave stuff [10:56] and I'm not sure at which point the line between genius and insanity gets crossed yet [10:56] Keybuk: no [10:57] 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] openoffice ends up being a child of upstart :) [10:57] thats not a problem to me [10:58] I see no reason it shouldn't be [10:58] it is by default [10:58] parent process is #1 for most X apps [10:58] right [10:59] 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] it doesn't have anything to do with the actual processes or gui or whatnot [10:59] people could make jobs [11:00] that do those sorts of things. [11:00] but thats not upstarts concern [11:01] so you still will probably need a "session manager", but for example - it handles the other aspects, like close/shutdown things. [11:01] but it doesn't need to start them [11:03] it doesn't seem unreasonable [11:04] 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] and it would just have system events forwarded to it from the system instance. [11:05] I was just thinking about how that would work [11:05] sounds a bit dbus-like to me [11:06] 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] I'm not immediately sure you need a user session daemon at all === johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #upstart [11:09] due to the way X has historically worked, all you need is something to register a session with the master daemon [11:09] give the DISPLAY, DBUS_*, etc. environment variables [11:09] so then init can just include those in anything marked for that "session" [11:09] but thats based on X [11:09] they don't need to be children of any particular process [11:10] hm [11:10] that is what I'm thinking, an user upstart could be just a small program that would send message to upstart [11:10] then you would add a new first-class object to upstart ... "session" [11:10] jobs might exist in a session or not [11:10] but what about starting jobs in user space? who would be the root level? upstart [11:11] yes [11:11] that's easy [11:11] fork () [11:11] setsid () [11:11] setuid () [11:11] exec () [11:11] :p [11:11] hm. maybe [11:11] nothing X related has a controlling terminal [11:11] only the X server itself [11:11] but if nothing else it would make the process tree horrible to make sense of in a multiuser environment ;) [11:11] so there's no UNIXish signal interaction to worry about here [11:11] ps fjax [11:11] this is what the process tree looks like *today* [11:12] not on my system ;) [11:12] note that everything in your X "session" has PID=1 [11:12] why not on your system? [11:12] show me [11:12] I can't at the moment because I am booted up under a normal system === Keybuk doesn't follow [11:12] but under my normal environment I use a hacked system like what I am talking about [11:13] any particular reason? [11:13] proof of concept. I started something like upstart about 2 years ago but nobody cared ;) [11:13] ahh [11:13] so you'd see something like [11:13] init [11:13] `- X [11:13] `- x-session-manager [11:14] `- user-init [11:14] `- gnome-panel [11:14] ? [11:14] yes [11:14] probably with a "`- gdm" in the middle there somewhere [11:14] I called it ProcessManager [11:14] but yeah [11:14] amazing how what two years ago was a stupid idea is todays big new thing ;) [11:15] heh [11:15] I've not yet managed to convince anyone inside the Boston Conspiracy that this is a good thing yet [11:16] hehe [11:16] Havoc does seem interested though [11:16] 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] don't suppose, btw, you could write a summary mail about the above and post it to the mailing list? [11:17] well, we have a distro ;) that's a big help [11:17] hm [11:19] if it works, Ubuntu will rock because of it, and everyone else will adopt it [11:19] if it doesn't work, then it doesn't [11:20] it will work :) === johnnybuoy hopes too [11:20] I just mean upstart in general [11:20] the concept is sound, and as I say. I have been running on it for a long time now. [11:21] Keybuk: sure it will [11:21] :) === johnnybuoy is running it, and is quite pleased! [11:22] I mean. just conceptually it really makes integration into the new udev design system a lot easier [11:24] yeah [11:24] next is a matter of integrating it with dbus and HAL properly [11:24] dbus?? [11:24] johnnybuoy: message passing bus [11:24] doesn't that slow down the machine horribly. [11:24] ?? [11:24] no? [11:24] yes? [11:25] why would it? [11:25] it's just an IPC bus [11:25] how one program tells another that something happened [11:25] i mean the cpu has to put itself into adm. mode everytime a message comes or goes [11:25] is logical for upstart to be able to start and stop things because of dbus broadcast messages [11:25] err? [11:25] hmm [11:25] what's "adm. mode" ? [11:26] supervisor? [11:26] i don't remember the word :( [11:26] but the cpu has two modes? [11:26] you're thinking of a Mach-like kernel aren't you? [11:26] CONTEXT SWITCH i think [11:26] right [11:26] where the entire kernel is based on message-passing? [11:26] dbus is just a user-space process for passing messages between user processes [11:26] L4 shows that can be quite fast. [11:27] ahh, so no context switch [11:27] 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] yet l4 doesn't even have userlan tools to do proof-of-concept [11:28] proof-of-concept of what? [11:28] that the linux drivers an 'really' be run in userland as servers [11:28] s/an/can [11:29] i tested it, it got me to a pretty screen that was mooving fast, bu no user interaction at all [11:29] L4 isn't really interested in that either. [11:29] Perhaps you are thinking of linux-on-l4? [11:29] bu if dbus doesn't need those context switching.. [11:33] dbus isn't in kernel space. its in user space space. thats a whole different concept then a messaging bus in kernel === johnnybuoy_ [n=void@nilus-1746.adsl.datanet.hu] has joined #upstart [11:36] <_ion> ajgenius: Excuse my ignorance, but what is "the new udev design system"? [11:38] kernel sends events when stuff changes [11:38] <_ion> Isn't that how udev has worked for a long time? === johnnybuoy_ is now known as johnnybuoy [11:39] <_ion> I.e. listening to uevent? [11:39] 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] _ion: uevents etc is new [11:52] as in, for proper functionality it requires a 2.6.15(16?) kernel iirc [11:52] it completely replaces hotplug now [11:53] before it just integrated with it [11:53] there is some documentation if you want to read up on the history and the recent changes :) [11:58] its one of the important reasons for upstart NOW [12:00] before it was just a good idea. now its almost necesary