[11:35] <robs_> someone can take a look at this bug I submitted  ? https://bugs.launchpad.net/upstart/+bug/703993
[12:57] <ronny> hi
[12:58] <ronny> im a bit at loss, i cant seem to find docs on how to prevent the automated starting of some services
[13:02] <JanC> ronny: what version of upstart are you using?
[13:03] <JanC> ronny: in 0.6.7 you can use the "manual" stanza, in older versions you can comment out the "start on" line(s)
[13:08] <ronny> atm 0.6.6
[15:20] <dacresni> how can you which running process depend on an upstart job 
[15:20] <dacresni> like what's using mysql now
[15:25] <JanC> considering that those processes might be running on a computer at the other side of the world, how do you think that would work?
[15:28] <dacresni> other side of the world? im just talking about programs that only start after mysql is running 
[15:28] <dacresni> thats the point of upstart right? to only launch programs after the programs they depend on are runnning? 
[15:29] <dacresni> in the case of mysql if there are are open sockets i guess i should ask the mysql people about that right?
[15:29] <dacresni> or am I confusing this with launchd 
[15:35] <jhunt> dacresni: it's not that easy currently - you need to look at the "start on" and "stop on" entries for all jobs.
[15:36] <JanC> upstart is based on events, not on dependencies
[15:37] <jhunt> quite.
[15:38] <JanC> maybe it's possible to document dependencies in job metadata in the future, just like you can document "emits" ?
[15:40] <JanC> dacresni: programs/jobs that need mysql might not always have a connection/socket open permanently...
[15:41] <dacresni> ok, thanks
[15:43] <dacresni> the events vs dependencies tells me that i did confuse it with launchd 
[15:43] <dacresni> I forget how systemd does it
[15:44] <JanC> you can implement dependencies using upstart's events, but not the other way around
[16:02] <dacresni> well, thanks all 
[22:16] <kreign> hi, I'm trying to understand the mountall.conf file. I need to have it wait for a custom filesystem module, which is getting modprobed via module-init-tools.conf; however, both these conf files appear to have the same prereq of 'start on startup' 
[22:16] <kreign> is there any way to make one a prereq of the other? 
[22:18] <kreign> from looking at the files it looks like I can do an "emits fs_module" and then have mountall.conf with "start on (startup and started fs_module)" - is this correct?
[22:18] <JanC> "emits" is documentation
[22:19] <JanC> so it does nothing on its own
[22:20] <kreign> JanC, ok; how can I specify that basic chain of events?
[22:21] <kreign> JanC, start on (startup and started init-module-tools) ?
[22:21] <kreign> er module-init-tools
[22:22] <JanC> sounds like that might work
[22:22] <kreign> JanC, or am I going about this the wrong way?
[22:22] <kreign> i'm assuming it's not whitespace sensitive...
[22:22] <JanC> I guess the "startup" part can be left out too
[22:23] <kreign> hmm probably.
[22:24] <JanC> and maybe you can make the modprobe for that specific module its own task, so that mountall can start earlier?
[22:25] <kreign> JanC, hmm I don't think mountall will be able to start earlier - module-init-tools is the direct prerequisite. 
[22:25] <JanC> also depends on whether boot time is important  ;)
[22:25] <kreign> not so much.
[22:25]  * kreign misses the old way of doing things, somewhat.
[22:26] <kreign> JanC, I'd think that any filesystem modules should be loaded before filesystems try to mount, anyway.
[22:27] <JanC> normally they will be loaded automatically?
[22:28] <kreign> JanC, that does not seem to be the case, in this regard.
[22:28] <kreign> JanC, the modules aren't strictly "linux compliant" per se
[22:28] <kreign> (ok, not going to lie - it's zfs, and I"ve also got to import the zpool in the module-init-tools.conf)
[22:30] <JanC> kreign: I think for most filesystems, their mount utility loads the modules, or something like that
[22:31] <JanC> I guess 'mount.zfs' (or whatever it's called) doesn't?
[22:32] <kreign> JanC, running mountall manually once in does the trick (with 'auto' as an fstab option)
[22:33] <kreign> JanC, it just looks like mountall is running prior to zfs module getting loaded (defined in /etc/modules) and not knowing what -t zfs is. :)
[22:33] <kreign> so, it dies.
[22:33] <JanC> right
[22:35] <JanC> like I said, you can use an extra job only to load the ZFS modules and make mountall.conf depend on that task
[22:35] <kreign> I don't recall classic init hanging on exception like this... iirc it'd continue despite problems.
[22:36] <JanC> classic init did a lot of things serially
[22:36] <kreign> JanC, right - but the zfs modules would need to be loaded beforehand, which are defined in /etc/fstab, so it makes sense to have the module-init-tools.conf do that.
[22:36] <JanC> if you don't mind waiting until all those modules are loaded
[22:37] <JanC> in most cases not an issue, I think
[22:37] <kreign> JanC, yeah. it's on server hardware, so...
[22:37] <kreign> slow bios
[22:37] <kreign> that's like 3-4 times as long as boot even though it's booting from sloooooow flash media
[22:38] <JanC> ☺
[22:38] <kreign> well let's hope i didn't biff it
[22:38] <JanC> my desktop doesn't boot fast either  ;)
[22:38] <kreign> i don't want to walk across the building again
[22:38] <kreign>  15:38:28 up 123 days, 23:34,  9 users,  load average: 0.66, 0.57, 0.49
[22:39] <kreign> ^ not much a problem for me.
[22:39] <kreign> tho i should probably do something like that. I've had two new kernels installed since then...
[22:39] <JanC> right
[22:39] <JanC> I was going to say: I install security updates  :P
[22:39] <kreign> JanC, oh I do too.
[22:40] <kreign> just don't usually have the time for a reboot... will probably do that tonight and watch monday be unproductive fixing things.