[01:51] <litheum> is there a recommended method to completely disable a rule, persistent-net-generator under ubuntu in this case?
[02:54] <litheum> man, i am so far behind the times on this stuff, dang
[12:02] <JanC> litheum: that sounds like an udev question, not an upstart one  ☺
[12:02] <JanC> and how to override system-supplied udev rules is explained in /etc/udev/rules.d/README
[16:21] <litheum> JanC: yeah i wasn't sure if it was a udev question or upstart, but i do want to disable the upstart rule that is calling udev and i don't want to do anything to udev, so...
[16:23] <litheum> i guess i didn't understand well enough how things work to want to copy the file and edit it
[16:24] <litheum> if i don't want it to run at all, is that really the right approach?
[16:43] <JanC> I guess creating an empty udev rule with the same name in /etc/udev/rules.d/ would work
[16:44] <litheum> yeah this does sound more like a udev question, doesn't it :)
[16:44] <litheum> how about a different question that might be related to upstart!
[16:45] <litheum> i edited /etc/init/hostname.conf so that it sets the hostname based on the name of the VM it is running inside of
[16:45] <litheum> but i need /etc/init.d/vboxadd to be executed first... is there a way to make the upstart job depend on an old-school init script?
[16:47] <JanC> edit the SysV init script to emit an event, then depend on that event?
[16:47] <litheum> yeah, that's what i ended up doing
[16:48] <litheum> that seems really scary though if that script is just going to get overwritten if i install a new version of those tools at some point
[16:48] <JanC> and vbox has no hooks for this?
[16:50] <litheum> hooks for what, running scripts after the module is loaded?
[16:50] <JanC> yes?
[16:50] <litheum> i have no idea if it does that or not, but tearing the hostname out of upstart and tying it to some vbox hooks didn't really even enter my mind
[16:50] <JanC> I mean, emitting an event from such a hook
[16:51] <litheum> oh, right
[16:51] <litheum> well, i don't know about that. good suggestions
[17:55] <jMCg> hmmm... now that there are actually people here, maybe I should reepeat my question..
[17:55] <jMCg> 15:48:53 < jMCg> I'm looking for a better way to handle this: http://sprunge.us/IAiV
[17:56] <jMCg> 15:49:10 < jMCg> Because the results are just plain horrible (IMO): http://sprunge.us/WSdc
[18:01] <JanC> jMCg: why are they horrible?  (not sure what you are trying to do)
[18:02] <jMCg> JanC: the point is that I need the logger only during the startup, but it stays up and running for the whole runtime. I find that... wrong.
[18:02] <JanC> eh
[18:02] <jMCg> JanC: the problem is that expect daemon doesn't work.
[18:04] <JanC> so logger works as intended, right?  ☺
[18:04] <jMCg> JanC: what doesn't work as expected is upstarts fork tracing :-S
[18:04] <jMCg> Can it please just work automagickally?
[18:05] <jMCg> I mean.. how does SMF do this?
[18:05] <JanC> AFAIK that's a feature that's in the works
[18:05] <jMCg> I don't remember SMF ever once caring a. Oh. Right.
[18:05] <jMCg> Contracts.
[18:07] <jMCg> http://www.freebsd.org/cgi/man.cgi?query=contract&sektion=4&apropos=0&manpath=SunOS+5.10
[18:08] <jMCg> That's a property all Solaris processes have which doesn't exist on Linux.
[18:14] <JanC> jMCg: how would that fix the logger issue?
[18:14] <JanC> also, can't you use start-stop-daemon for example?
[18:16] <JanC> also, you can probably do some logging in pre-/post- scripts
[18:16] <jMCg> JanC: the logging is only needed for startup -- and only in case of failure.
[18:16] <JanC> what does it need to log?
[18:17] <jMCg> JanC: the reason why it's failing to start, for instance.
[18:17] <jMCg> That kind of stuff is *reeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeaaally* useful for debugging.
[18:17] <JanC> how did you do that with SysV init?
[18:18] <jMCg> JanC: I haven't used SysV init since there's upstart, and I haven't used this setup before.
[18:19] <broder> jMCg: it sounds like you're looking for https://code.launchpad.net/~jamesodhunt/upstart/job-logging
[18:19] <JanC> broder: I doubt that will stop logging after startup?
[18:19] <broder> so?
[18:20] <JanC> that's what he wants, if I understand correctly?
[18:20] <JanC> to log startup failures, but not whatever else the application spews after that?
[18:21] <broder> it's still possible to get that information out of full job logging, though
[18:21] <broder> once job logging gets merged in, i could imagine extending it to "log everything until the job transitions to a running state"
[18:21] <broder> pretty easily, even
[18:23] <jMCg> broder: what I want is to be able to start httpd without -D NO_DETACH without upstart losing track of it.
[18:23] <jMCg> Oh.
[18:23] <JanC> he already gets that with logger now, although upstart job-logging would make it easier
[18:23] <jMCg> expect daemon expects two forks, my fancy pants setup has 3.
[18:27] <JanC> jMCg: there is some work being done about that, but in the mean time your job should work just fine?
[18:28] <jMCg> JanC: yup.
[18:28] <JanC> I mean, the thing you complained about has nothing to do with that  ;)
[18:28] <JanC> complained about first
[18:29] <jMCg> JanC: I'm not using expect daemon. I tried doing that, but it wouldn't work. Only now did I grasp why.
[18:31] <JanC> ah, yes, THAT is a known problem
[18:31] <JanC> IIRC there are several solutions for that planned  ☺
[18:37]  * jMCg strongly suggests implementing contracts in Linux.
[18:44] <JanC> jMCg: have any good link about that?  ☺
[18:45] <jMCg> JanC: aside from the docs I linked above, there's the OpenSolaris.. well.. OpenIndianna source code.