=== robbiew is now known as robbiew_ === btm_ is now known as btm === rberger_ is now known as rberger === robbiew_ is now known as robbiew [16:58] hi.. a question about temporarily disabling services managed by upstart from starting.. let's say i'd like to disable some service for a reason or another but don't want to uninstall the package. in debian/ubuntu, with traditional init scripts, you could disable a service from starting on boot by running update-rc.d -f remove [16:59] is there something similar for upstart or do i just need to remove the conf file under /etc/init ? [17:01] tj___: nothing similar as of yet [17:01] ok [17:07] i have an ltsp server setup with local apps. handy for trying out machines, testing motherboards etc. quickly without having local disks. by default it'll boot to desktop. but in the pxe menu i've setup an entry for a quick non-graphical boot with minimum services running. it passes a special command line option to kernel. then i have a custom boot script which is run very early in the boot process. it'll check for this boot argument and if exists, it'll remove g [17:07] this worked fine until karmic but now that more services are using upstart, i need to figure out another way to do that [17:09] i'd rather not just remove the conf file for the service as it would be handy if you could manually start any service after the boot if needed, only autostart on boot should be disabled [17:10] remove g? [17:17] g? [17:18] " it'll check for this boot argument and if exists, it'll remove g" [17:19] ah that was clipped [17:19] it'll remove gdm and other desktop related services using update-rc.d from the root fs which is unionfs-on-top-of-squashfs-mounted-over-nbd [17:20] tj___: you have some strange ways of operating [17:21] could be but it works^Hed :) [18:55] tj___: just comment out the "start on" in the upstart job files === rberger_ is now known as rberger [19:58] HI [19:59] How or when does upstart connect to the dbus-daemon system bus? [19:59] is this something I can configure? [20:00] I am mainly interested in talking to upstart from a user accont and possibly using the dbus-daemon 's system configuration to configure who can access the upstart daemon [20:03] keesj: it used to connect when launched, which meant if you ran it before dbus (i.e. the way you'd always run it in a non-test environment) it would never connect. I think something was done about this but I'm not sure. [20:06] I would find it somewhat strange if upstart would not start the daemon itself and on my ubuntu machine. it starts dbus-daemon itself [20:06] but I think I found the trick.. [20:06] post-start exec kill -USR1 1 [20:06] keesj: exactly [20:06] in the dbus.conf will probably make upsart try again [20:07] sounds right [20:07] though I wonder why ubuntu doesn't have that already if it was put it. [20:07] *in [20:08] i ubuntu it is [20:08] http://paste-it.net/public/x881ffb/ [20:10] it just lacks a comment why I did that :p [20:11] perfect then [20:15] thanks for helping [21:25] notting: hey so i'm looking at your prefdm.conf / gdm.conf stuff [21:25] woah i have underscores [21:26] h_lfline_: you're loosing vowels rapidly [21:26] anyway, noticed a typo [21:26] if [ -f /etc/init/$base.conf ] [21:26] should probably be /etc/event.d/$base.conf [21:27] but i wonder if that's the most "upstarty" way to do it [21:27] /etc/init is the 0.6.x path [21:27] /etc/event.d is the 0.3.x path [21:27] ohhhhhh [21:27] makes sense [21:27] h_lfline_: this should probably be in fedora-devel really. We've been coming down on the ubuntu questions pretty hard, so for fairness sake I should mention it. [21:27] the problem is that if multiple DMs have installed jobs, you need to explicitly start one; you can't have them all start on a generic event [21:28] but say you had a dm event [21:29] with a DM variable [21:29] then the only two competing would be the relevant dm and the fallback task [21:29] sadmac2: oh i brought discussion here in case keybuk was around [21:30] you guys probably know the internals of upstart a lot better than i do though [21:30] h_lfline_: there is that. anyway its venturing into more generic upstart stuff anyway [21:30] notting: so i wonder if we could have the fallback task sit back and wait [21:31] and only chime in if the main event doesn't show up [21:31] that sounds messy to code [21:32] i'm looking at this state diagram that's in the upstart tree [21:32] and it looks like things shoot to stopping if nothing is around [21:33] so maybe we could have a handler on stopping that checks if runlevel is still 5 [21:33] and if so starts fallback [21:34] unless there's some upstart mechanism for "no one caught the event" [21:34] h_lfline_: Is this absolutely necessary? [21:34] no absolutely not [21:34] just trying to come up with the most upstart-y way of doing things [21:35] if doing [ -f /etc/init/$base.conf ] && start $base is the right way to go [21:35] then that's fine with me [21:35] backing up, the idea we're trying to solve [21:35] we pick a $foo to start [21:36] we want to start a specific provided-by-$foo job if it exists; if not, start a generic job that starts $foo [21:36] hence the logic abov [21:37] oh I see. hmm... [21:38] notting: the way I'd do it would be to have the fallback job check if the provided-by-$foo job has already started, and if so, terminate itself. Then the special foo job should start on starting generic-job [21:39] so the question is, do we detect if a job doesn't exist by doing if [ ! -f /etc/init.d/$job.conf ] or is there some upstart hook to say "only call me if for this event if no one else takes it" [21:39] sadmac2: that would mean the fallback would need to know all possible names of provided-by-$foo. sounds painful [21:39] sadmac2: is there a way to ensure job ordering? [21:40] ohhh start on starting is the way you keep order [21:40] notting: not really [21:41] sadmac2: how do you know what to check for otherwise? [21:41] notting: what you would do is have all of the provided-by-$foo jobs start another job called dm-started DISPLAY=$whatever. That job would have no executable. Its a "state" if you will [21:42] notting: then you detect the presence of that (initctl list) to determine if the display manager is up [21:42] notting: thereby implementing a good chunk of upstart 1.0 in userspace in bash :) [21:42] you mean "initctl status dm-started " [21:42] ? [21:42] sounds messy [21:44] notting: its one line in each of the generic jobs ( post-start start dm-started ) and really not much in the generic job [21:44] *one line in each of the specific jobs [21:45] so you'd have specific job: 'start on start-dm DM=foo', and then 'post-start initctl emit started-dm' [21:45] and the generic job has 'start on start-dm', 'stop on started-dm'. with a sleep thrown in? [21:45] start on starting start-dm DM=foo [21:45] notting: the specific job would have start on starting generic-dm-job DM=foo [21:45] i think sadmac was saying if you put the "starting" then you don't need a sleep === plndra is now known as plundra [21:46] notting: the idea is we always just try to run the generic job, and then we just have the specific jobs jump in the way and say "wait!" [21:47] 'bar: start on starting foo' implies bar must finish before foo starts? [21:48] notting: yes. [21:48] notting: when jobs emit events they wait for all the responders to finish responding before they continue. Its a very important part of how upstart works. [21:49] * notting goes off to write the 'start on starting startup' job [21:49] notting: and actually you don't need the dm-started state. you could have the specific jobs just have "post-start stop generic-job" [21:49] notting: and then the generic job will never get past starting. [21:50] oh that's a littler nicer [21:50] so you have start on starting display-manager DM=gdm [21:50] notting: that has the advantage that the generic job can be written in a vacuum, with no knowledge that there is such a thing as a specific job or that it might run instead. [21:50] psot-start stop display-manager [21:50] hmm that doesn't sound right [21:50] maybe it should be called display-manager-arbiter or something [21:50] h_lfline_: it doesn't but it is [21:51] h_lfline_: yeah, name it as you like [21:51] sadmac2: although it does mean that the individual jobs need to know about the generic job [21:51] notting: indeed, but they'd have to know about some event or something that was going to kick them off anyway. [21:51] notting: so they don't need to know more than usual. [21:51] sadmac2: not as written now, but as halfline says, it's a bit hackish [21:52] notting: I'm on my way home. I could stop by and look at what you have [21:52] lemme bounce you the mail [21:52] by on my way home I mean about to grab my coat [21:52] i have to head out in ~15 anyway [21:52] cool [21:54] clearly it should be called "quest-to-find-a-display-manager" [21:54] start on starting quest-to-find-a-display-manager [21:54] post-start stop quest-to-find-a-display-manager [21:54] h_lfline_: of course, this is ignoring the contortions where it figures out what it needs to start. ah, legacy installbases and config files [21:55] yea i'm pretty sure there's not much we can do about those checks and heuristics [22:32] how about an all-display-manager-rise