[01:26] <Slapshot|Linux> Hi, I am having trouble getting my upstart to run at boot. Any help would be great.
[08:42] <pmjdebruijn> jhunt: we're using a heavily customized setup
[08:42] <pmjdebruijn> where we synchronize configurations
[08:42] <pmjdebruijn> in an upstart job
[08:42] <pmjdebruijn> but parallization of the rc sysv init seems to be problematic
[08:42] <pmjdebruijn> in the past I just upstartified the packages and be done with it
[08:42] <pmjdebruijn> but for complexer init scripts this is well a pain and very error sensitive
[08:43] <pmjdebruijn> we're actually doing a migration to ubuntu (from debian)
[08:43] <pmjdebruijn> but in our custom setup, upstart seems to make this very painful
[08:47] <jhunt> ??? I don't understand what the problem is? If you have specifics, please can you post to the mailing list or raise bugs if you think you've found one?
[08:48] <pmjdebruijn> it's not really a bug
[08:53] <pmjdebruijn> ideally my problem would be solved if I could depend the sysv rc upstart job on another upstart job
[08:53] <pmjdebruijn> but if I do that my whole init breaks
[08:53] <pmjdebruijn> I tried that before
[08:53] <pmjdebruijn> system won't reboot anymore
[09:03] <pmjdebruijn> I guess I might mail to the mailing list if I have time to workout my case
[09:04] <jhunt> are you saying that existing sysv scripts fail to run correctly when started by upstart?
=== Md_ is now known as Md
[09:06] <pmjdebruijn> no sorry
[09:06] <pmjdebruijn> sysv works
[09:06] <pmjdebruijn> but it runs to soon
[09:07] <pmjdebruijn> it should only run _after_ another upstart job
[09:07] <pmjdebruijn> which synchronizes the local configuration from a remote host
[09:07] <pmjdebruijn> but it's being parallized
[09:07] <pmjdebruijn> so stuff isn't starting because there is no configuration yet
[09:07] <pmjdebruijn> we're talking about network bootend hosts he
[09:07] <pmjdebruijn> here*
[09:09] <jhunt> you really need to migrate your sysv job to upstart then. There is a way to do what you want though...
[09:09] <jhunt> 1) disable the sysv job by removing the sym links.
[09:10] <pmjdebruijn> yeah
[09:10] <pmjdebruijn> it's just that the sysv script is _very_ complex
[09:10] <jhunt> 2) create an upstart job "wrapper" for it that does "start on event-i-need" and "exec /etc/init.d/my-sysv-service"
[09:10] <pmjdebruijn> oh
[09:10] <pmjdebruijn> lol
[09:10] <pmjdebruijn> that's an idea
[09:10] <pmjdebruijn> it's a horrible hack
[09:10] <pmjdebruijn> but that would work though
[09:11] <pmjdebruijn> for nagios-nrpe I created a real upstart job
[09:11] <pmjdebruijn> which is just requires a trivial patch
[09:11] <pmjdebruijn> but your suggestion would work for everything
[09:15] <pmjdebruijn> jhunt: thanks for that suggestion
[12:55] <pmjdebruijn> jhunt: btw, just implemented the wrappers
[12:55] <pmjdebruijn> jhunt: it seems to work nicely
[12:55] <pmjdebruijn> jhunt: thanks for the tip
[12:57] <jhunt> np. of course you'll need to ensure that the sysv sym links don't get re-instated if the packages get updated say.
[12:57] <pmjdebruijn> that's not an issue
[12:58] <pmjdebruijn> it's a ramdisk based setup
[12:58] <pmjdebruijn> so it's static
[12:58] <pmjdebruijn> everytime we update the ramdisks, we also have a QA phase (which should catch that)
=== Alien_Freak is now known as csgeek