[03:07] <_Andrew> Hi
[03:08] <_Andrew> I have an upstart script I have made but it's not working on startup http://paste.ubuntu.com/351057/
[03:08] <_Andrew> Am I doing this right? I'm trying to execute a program under a specific user
[04:24] <JanC> _Andrew: 'exec' has a '-u' option on your system ?
[04:25] <_Andrew> I just copied it from so other upstart script
[04:25] <_Andrew> I have no idea
[04:25] <JanC> from which one?
[04:26] <JanC> you'll need to use something like su or sudo IMO
[04:29] <JanC> unless you do have an 'exec' with that option of course
[04:30] <_Andrew> http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstall?highlight=%28upstart%29
[04:30] <_Andrew> I got it from here
[04:31] <JanC> well, they *do* use sudo there, right?
[04:33] <JanC> also, the 4 first lines can be written as one: start on runlevel [2345]
[04:34] <ion> Also, [-f foo] is invalid (unless you have a command called [-f), you’ll want [ -f foo ]
[04:35] <ion> Will startup.sh stay in the foreground until shutdown.sh is called?
[04:36] <ion> (The job you pasted expects it to.)
[04:36] <_Andrew> I think so yes
[04:38] <_Andrew> Should it not stay in the foreground?
[04:39] <ion> It should.
[04:40] <ion> To clarify: it should stay in the foreground. :-)
[04:40] <JanC> ion: well, that or you need extra stuff in that file  ;)
[04:40] <ion> A future version of Upstart will properly track daemonizing things, but for now, it’s often best just to have it stay in the foreground.
[04:41] <ion> janc: Yeah, and you also need to know exactly what you’re doing in order not to break Upstart’s current fork-tracking code. :-)
[04:41] <JanC> _Andrew: did you read init(5) ?
[04:43] <JanC> http://manpages.ubuntu.com/manpages/karmic/en/man5/init.5.html for a web version
[04:44] <JanC> it's the best docs upstart has currently, I think  ;)
[04:44] <_Andrew> ok thanks gys
[04:45] <JanC> _Andrew: I also see that dropbox example is for versions of Ubuntu < 9.10
[04:46] <JanC> the script needs to go into /etc/init/ now, not /etc/event.d/
[04:46] <JanC> so, depending on what version of upstart you use...
[04:47] <_Andrew> Our server is LTS so I think it's in the right place, but thanks for letting me know
[04:47] <JanC> _Andrew: ah, then the manpage I pointing to might not work
[04:48] <JanC> I'm not sure if there is much documentation for that version of upstart
[04:48] <JanC> _Andrew: you can still use sysvinit init scripts though, if you are more familiar with those
[04:49] <_Andrew> I think this should be working now. I'll let you know if I have any other probs that I can't figure out
[13:44] <ion> keybuk: O hai
[13:44] <ion> Welcome back
[13:44] <ion> keybuk: http://people.canonical.com/~scott/daily-bootcharts/ :-D
[13:44] <Keybuk> Happy new tiger
[13:44] <Md> Keybuk: can you remind me the current plan wrt upstart and network up/down events?
[13:44] <Keybuk> ion: what about them?
[13:45] <Keybuk> ion: ah, amusing gap for new year calcuations :p
[13:45] <ion> keybuk: Nothing really. It was just interesting to learn there are 29 days in the zeroth month of the year.
[13:45] <ion> Beginning with the 0th day, of course.
[13:45] <Keybuk> Md: I don't have any current plans fori t
[13:46] <Md> Keybuk: I do... what do you think about a long-lived daemon which will listen to interface events on the netlink socket and feed back "cleaned up" events to upstart after applying a "carrier delay" and/or debouncing?
[13:47] <Keybuk> Md: that's probably the right kind of thing
[13:47] <Keybuk> though I don't know what you mean by "carrier delay"
[13:48] <Md> oh, it's an IOS feature which delays up/down events for a few ms, to prevent flapping the IGP if the physical layer bounces
[23:55] <btm> Md: bonding uses similar delays to deal with network equipment bring a link up before it is ready to recieve and pass traffic, which is another applicable analogy IRT upstart.