#upstart 2007-06-18
<Keybuk> rah
<Keybuk> Straw Poll:
<Keybuk> a) "start on EVENT and EVENT" / "stop on EVENT or EVENT"
<Keybuk> or
<Keybuk> b) "from EVENT and EVENT" / "until EVENT or EVENT"
<shawarma> Keybuk: Well, b) more clearly conveys the fact that upstart manages the job and doesn't just start and stop it.
* Keybuk hugs nih_tree_*()
<Keybuk> shawarma: from/until fits in better with adding "while" as well
<Keybuk> from starting dbus
<Keybuk> until stopped dbus
<Keybuk> while filesystem-writable and network-available
<Keybuk> (other suggestions from the floor welcome <g>)
* Starting logfile irclogs/upstart.log
<Trevelyan`> hi. looking at launchpad it seems that init script replacement jobs writting seems to have stalled. is this true or has the work moved elsewhere?
<Keybuk> Trevelyan`: we're working on changes to Upstart itself to make it possible
<Trevelyan`> still not happy with how jobs (defs) work?
<Keybuk> largely, yes
<Keybuk> the issue has been the implementation of more complex event expressions than just an "OR" list
<Keybuk> Upstart 0.2 and 0.3 just implement "start on"/"stop on" as a list of events, and any can match
<Keybuk> that's obviously not flexible enough (and we knew it wouldn't be)
<Keybuk> the delay has been coming up with a replacement expression language that is as flexible as we want, but with very well defined behaviour
<Keybuk> I think we're on a very good track for it now, with some really nice features
<Trevelyan`> cool. I tried initng, but upstart i think has more promise. however until it has jobs that will do parallel job/process starts i wont get much use out of it, ifykwim.
<Trevelyan`> thank you for explaining that.
<Keybuk> these things take some amount of time to get right
<Trevelyan`> no doubt
<Keybuk> and I'm being deliberately cautious, rolling out changes incrementally and testing them, rather than trying to do it all at once
<Trevelyan`> sensible, but having said that it surprises me more that upstart went into ubuntu so quick.
<Keybuk> how so?
<Keybuk> in order to test, you need a group of users to test it on
<Trevelyan`> not that it wasn't ready, but how young it was
<Trevelyan`> that is true
<Keybuk> the set of features of 0.2.7 was a superset of those of sysvinit
<Keybuk> so it was an ideal way to test it, since it could behave like sysvinit while stress-testing the new code in the field
<Trevelyan`> i gather it went well? since i've not really heard anything that negative about the upstart in ubuntu.
<Trevelyan`> anyway i look forward to upstart reaching its full potential, and my laptop booting in a couple of seconds =)
<Keybuk> it's gone well, yes
<Keybuk> it's taking a little longer to develop than anticipated, but there's no major panics yet :)
<ion_> trevelyan: While youre at it, replace the BIOS with something better and faster. :-)
<Trevelyan`> http://linuxbios.org/index.php/Main_Page
<ion_> Yes. :-)
<Keybuk> meh, BIOS isn't that slow
<Trevelyan`> although i think that might be a step too far for Dell's tech support to swallow =)
<Trevelyan`> they only just about accept the fact we run debian
<Trevelyan`> although since they now ship ubuntu i guess they can't blink at our ubuntu desktops.
<Trevelyan`> i don't know what dell uses but for their desktops/laptops it fairly fast on what i like to think as cached boots (ie nothings hw or bios wise has changed since last boot)
<Trevelyan`> on their servers it can take as long as 5 mins before you reach grub =/
<AlexExtreme> Keybuk: what would i need to do if i wanted to add a new command to initctl to change profile?
<Keybuk> AlexExtreme: it's a little complicated ;)
<AlexExtreme> heh
<Keybuk> first you need to modify libupstart
<Keybuk> add appropriate messages and replies to upstart/message.h, and then modify upstart/message.c so that the arguments in both directions are correctly marshalled
<Keybuk> the usual format here is a "change profile" message from initctl, along with a generic "current profile" message that can be used as both a reply, and as a subscription event
<Keybuk> cf. the emit/event series
<Keybuk> second you need to modify upstart itself
<AlexExtreme> so that it receives the message and does the appropriate thing with it?
<Keybuk> this is quite easy, just add a function to init/control.c and hook it into the message table, that handles your marshalled message - it looks like an ordinary function that has some useful effect
<Keybuk> and lastly you need to modify initctl
<Keybuk> add an action function that makes the appropriate initctl_send call
<Keybuk> and add handle functions to deal with the replies
<AlexExtreme> ok
<Keybuk> http://upstart.ubuntu.com/wiki/JobEventExpressions
<Keybuk> ^ for proof-reading and comment
<AlexExtreme> *clicks*
<AlexExtreme> there's a small typo in the design section
<AlexExtreme> "The expression, or sub-expressions within parentheses) must"
<AlexExtreme> where's the opening bracket for that closing bracket? ;)
<Keybuk> heh
<Keybuk> fix it for me :p
<AlexExtreme> k :P
<AlexExtreme> done
<Keybuk> any comments on the design, rather than my typing? :p
<AlexExtreme> i haven't finished reading yet ;)
<AlexExtreme> bah, what is it with the weather in this country?
<AlexExtreme> this is supposed to be summer!
<AlexExtreme> gah, thunderstorm overhead, i'll bbiab
<Keybuk> it's doing similar here
<wasabi> Keybuk, I don't see our "from" idea there. Has that cahnged?
<wasabi> oh wait there it is.
<wasabi> unresolved issues heh
<Keybuk> :)
<AlexExtreme> back
* AlexExtreme continues reading the spec
<AlexExtreme> Keybuk: IMO the from/until is better because it makes it reading a job sound more like the time period in which the job is run (i hope that makes sense :))
<AlexExtreme> this seems like a "simpler" verson of c-e-c
<Keybuk> AlexExtreme: it's intended to be step #1 in replacing c-e-c
<Keybuk> step #2 is to introduce "States" which are jobs without the jobbish bits. ie just from/until
<Keybuk> step #3 is to allow expansion of from events in the until expression
<Keybuk> step #
<Keybuk> states introduce a "while" stanza
<Keybuk> and I do think that from/until/while go together nicely
<AlexExtreme> cool, sounds good
<ion_> Wow. By using the GUI edit mode, i managed to do a huge diff, while adding just a single character. http://upstart.ubuntu.com/wiki/JobEventExpressions?action=diff&rev2=3&rev1=2
<ion_> It changed each `...` to {{{...}}}
<ion_> Is it possible to subscribe to each current and future spec at the Upstart wiki?
#upstart 2007-06-19
<Keybuk> hihi
<razialx> hello, i was hoping someone would be able to help me with an upstart question i had
<razialx> i will return later I suppose, thanks though :) (realized it was quitting time)
<ion_> Theres no such thing.
#upstart 2007-06-20
* Starting logfile irclogs/upstart.log
<razialx> hello again. I was wondering if someone would help me. I am trying to write a job that will catch the event of a network interface coming up. I am not sure how to get the event to emit, without using initctl. 
<Keybuk> razialx: hello
<razialx> I suppose I assumed that an event would be emitted automatically 
<Keybuk> initctl is the standard method to emit events
<razialx> ok, so should i add an initctl command to the eth1_up script ?
<Keybuk> if the monitoring software is a daemon, it may prefer to link directly with libupstart rather than fork()/exec()ing initctl, but the effect is the same
<Keybuk> yes
<razialx> I just want to be sure that I am doing things correctly :)
<razialx> thank you keybuk 
<Keybuk> the only events Upstart generates itself are for "startup", and for events informing you of a job state change
<razialx> ah, ok. 
<Keybuk> events for things like network cards, interfaces, devices, etc. are expected to be emitted by other processes using initctl or libupstart
<razialx> that is good to know. 
<razialx> thank you, i should have what i need now. 
<Keybuk> the dbus service activation threads are amusing me
<Keybuk> I hadn't, until now, realised how heavily nih Fedora are
<Keybuk> and coming from me, that's a big thing
<Nilsy> nih ?
<thom> not invented here
<Nilsy> oh ok
<Keybuk> start on wibble foo bar or ((foo "frodo baggins"
<Keybuk>                              and bar bilbo))
<Keybuk> stop on wibble (foo) and
<Keybuk>                ^ Expected operator
<Keybuk> exec /sbin/daemon
<Keybuk> at line 3
<Keybuk> \o/
<ion_> Whee
#upstart 2007-06-21
<Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070620222502-rqg8aiw9kzt3h8t7?start_revid=scott%40netsplit.com-20070620222502-rqg8aiw9kzt3h8t7
<Keybuk> ^ event expression trees have landed
<Keybuk> heh
<Keybuk> I had planned, this morning, to get rid of job->cause entirely
<Keybuk> and so far I've been distracted by shiny new compiz-fusion features
<ion_> I upgraded from beryl to compiz+compcomm recently.
<ion_> Theres an interesting bug, which i havent got around to investigating yet.
<thom> Keybuk: honestly, i'm shocked. :P
<ion_> When i switch from a desktop to another using any largedesktop plugin, it seems to work fine, unless im switching from/to a desktop with Firefox as the active window. When that is the case, the movement is really jerky.
<AlexExtreme> that's why i don't use compiz/beryl/whatever :)
<AlexExtreme> when you're trying to do something, it's just too easy to get distracted with bouncing windows
<AlexExtreme> sorry for the disconnects, my IRC bouncer is acting up
<Keybuk> heh, silly things
<AlexExtreme> there, that was the last one
<Keybuk> which bouncer do you use?
<AlexExtreme> bip
<AlexExtreme> http://bip.berlios.de
<ion_> alex: Whether the windows bounce depends on your configuration. :-)
<AlexExtreme> ion_: of course ;)
<ion_> The nicest thing is that when switching to another desktop, the windows dont need to be repainted. That makes it a lot faster on this 500 MHz machine.
<ion_> *Even* when using a transition effect.
<AlexExtreme> yep
<AlexExtreme> I first tried compiz on a 700Mhz box when it was first released, it was quite fast
<Keybuk> CPU speed shouldn't affect compiz
<Keybuk> that's kinda the point <g>
<Keybuk> fancy effects aside, the entire point is to offload all the boring screen management to the GPU
<Keybuk> so more CPU resource is free
<ion_> Indeed.
<ion_> I meant that even showing the transition effect takes less time than having one of the bit more bloated programs repaint its window on this box.
<Keybuk> true
<Keybuk> in fact, in theory, the transition is free
<ion_> Yeah.
<Keybuk> because it's done using spare GPU capacity, rather than taxing the CPU
* Keybuk lols at a test case
<Keybuk> I do use some funny metasyntactic names
<Keybuk> clearly for this test, I really wanted a name I wasn't likely to accidentally use later
<Keybuk> so instead of foo, bar, baz
<Keybuk> or frodo or bilbo
<Keybuk> or wibble, wobble, waggle, wiggle, etc.
<Keybuk> I used ...
<Keybuk> biscuit
<ion_> Hehe
<Keybuk> there's one thing about specs that always bites
<Keybuk> you always forget something, and have to retcon it when you write the code
<Keybuk> e.g. the spec for replacing cause with event expressions
<Keybuk> I had completely forgotten that a job is allowed to abort the stop in pre-stop
<ion_> Looking up retcon from dictionary.com just spoiled a TV show. :-)
<ion_> Not that id want to watch the show in question.
<AlexExtreme> :)
<Keybuk> retcon. v. to pretend the spec always said that ;)
<ion_> :-)
<AlexExtreme> :)
* Keybuk frowns at post-stop -> starting
<Keybuk> there's another state transition I forgot
* AlexExtreme frowns at this stupid country's weather
<AlexExtreme> why is it that every time i need to go somewhere it starts raining?
<Keybuk> the weather here has marginally improved over the last few days
<AlexExtreme> yeah, *marginally*, i.e. not raining constantly, just showers every 20 minutes ;)
<Keybuk> EGBB 211720Z 16010KT 9999 -SHRA FEW020CB SCT030 16/13 Q1007
<Keybuk> tomorrow's TAF is pretty mad
<Keybuk> EGBB 211624Z 220024 17010KT 9999 SCT025 BECMG 0205 11005KT PROB40 TEMPO 0210 7000 -RA BKN008 PROB30 TEMPO 1022 7000 SHRA BKN020CB PROB30 TEMPO 1120 3000 +TSRA BKN014CB BECMG 2124 4000 BR
<AlexExtreme> what's that from?
<Keybuk> metoffice aviation forecast
<Keybuk> EGBB = Birmingham International Airport
<AlexExtreme> ah
<AlexExtreme> you're near birmingham?
<Keybuk> 40% probability of light rain in the morning,
<Keybuk> 30% probability of showers in the afternoon
<Keybuk> and 30% probability of heavy thunderstorms in afternoon
<Keybuk> in Birmingham yeah
<AlexExtreme> cool, not too far from here
<Keybuk> that somewhat explains why we've been experiencing equally dire weather ;)
<AlexExtreme> :)
<Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070621173820-45cqbuufjbcft1sn?start_revid=scott%40netsplit.com-20070621173820-45cqbuufjbcft1sn
<Keybuk> ^ \o/
<Keybuk> actually, the current METAR isn't bad at all; perfectly flyable in fact
<AlexExtreme> :)
<Keybuk>  * If a job fails to reach its goal, all appropriate blocked events are marked as failed. Nodes with a FALSE value, and children of those nodes, are not considered since they have not caused the job to fail.
<Keybuk> Urgh
<Keybuk> I haven't worked out how to implement *that* yet
<Keybuk> deciding which events in the expression tree to mark as failed
<Keybuk> it's supposed to be "those that contributed to it starting in the first place"
<AlexExtreme> Keybuk: would you mind greatly if I copied the nih linked list code to my project? i'd rather not link against libnih since i'm trying to keep the dependencies on this lib i'm writing to only libc
<AlexExtreme> of course i'd add credits in the header (it's GPL, btw)
<Keybuk> not at all
<AlexExtreme> thanks
<Keybuk> though you'd need nih_alloc as well, unless you modify it
<AlexExtreme> k
<Keybuk> (modify is easy enough, it's just nih_list_new, nih_list_entry_new, nih_list_destructor and nih_list_free)
<AlexExtreme> yep
<Keybuk> why do I only ever discover problems half way through an implementation?
<Keybuk> today's problem:
<Keybuk>   instance
<Keybuk>   from tty-added
<Keybuk>   until tty-removed $TTY
<Keybuk>   respawn
<Keybuk>   exec /sbin/getty $TTY 38400
<Keybuk> nice and simple
<Keybuk> what happens if
<Keybuk>  a) the same tty gets added
<Keybuk>  b) the tty gets removed, and another tty is added while the job is stopping
<wasabi> I vote for proper lock/abort files. :0
<wasabi> The instance gets spawned twice, but some nice chap tests to see if the instance is already spawned.
<Keybuk> wouldn't it be nice if upstart took care of this for you? :p
<wasabi> I don't really think so.
<Keybuk> why not?
<wasabi> got me.
<wasabi> instance could be "unique per parameters"
<Keybuk> yeah, which is interesting
<Keybuk> but then do you restart the instance, or do you wait to create a new instance? :P
<wasabi> Well, what happens if a start evnet happens twice in any non-instanced job
<wasabi> Basically nothing.
<Keybuk> indeed
<Keybuk> need to think on this a bit
<Keybuk> EGBB 212020Z 15006KT CAVOK 14/11 Q1008
<Keybuk> CAVOK!
* Keybuk was starting to think he'd never see those letters again
<Keybuk> *cries*
#upstart 2007-06-22
<Keybuk> today I feel like I have a handle of the event expression atomicity issues
<Keybuk> Interesting question
<Keybuk> when upstart kills a process, should it just kill that process, or should it kill everything in that process's group?
<shawarma> Keybuk: Good question. What about the session?
<Keybuk> the session?
<shawarma> Yup.
<shawarma> getsid()
<Keybuk> you can't kill a session
<shawarma> If you SIGHUP the session leader, it trickles down to the other processes in the session.
<Keybuk> actually, it's more complicated than that
<shawarma> If you SIGTERM the session leader, it doesn't kill the rest of the processes, afair.
<Keybuk> you don't mean session leader
<Keybuk> you mean process group leader
<shawarma> No, I'm quite sure I mean session leader.
<Keybuk> and the SIGHUP thing only applies to the foreground process group with a controlling terminal
<Keybuk> iirc.
<shawarma> That's the session leader.
<shawarma> Gah.. getsid has no man page. Gimme a sec.
<Keybuk> the session leader is the first process in the session?
<Keybuk> the one where the sid == pid
<shawarma> Right.
<Keybuk> setsid() gives you a process where pid == pgrp == sid
<shawarma> Right.
<Keybuk> ie. it's the session leader and a process group leader
<Keybuk> process groups can exist without their leader
<Keybuk> sessions contain one or more process groups
<Keybuk> sessions can have a controlling terminal
<shawarma> Right.
<Keybuk> one of the process groups can be the foreground process group
<Keybuk> all of the others are the background process groups
<Keybuk> Control-C on the terminal will send SIGINT to all processes in the session's foreground process group
<Keybuk> if the terminal is hung-up, SIGHUP is sent only to the session leader
<shawarma> What causes the other processes in the session to die, then?
<Keybuk> Control-Z sends SIGTSTP to all processes in the foreground process gruop
<Keybuk> Control-\ sends SIGQUIT to all processes in the foreground process group
<Keybuk> reading from standard input while you are not in the foreground process group will send SIGTTIN back to you
<shawarma> ABout SIGHUP: "This signal is also generated if the session leader terminates. In this case the signal is sent to each process in the foreground process group". Hmm.. Is it the kernel doing that?
<Keybuk> writing to a terminal while you are not in the foreground process group may either succeed or send SIGTTOU back to you
<shawarma> (from APUE)
<Keybuk> shawarma: dunno, not got that far yet (I'm in APUE too :p)
<shawarma> *G*
<shawarma> I cheated and skipped ahead. :)
<Keybuk> children in a process group that are stopped are sent SIGHUP followed by SIGCONT if the process group they are in becomes orphaned
<Keybuk> (ie. the parents of all processes in that process group are in different sessions)
<Keybuk> SIGHUP is only sent if there is a controlling terminal
<Keybuk> if the session leader terminates, SIGHUP is sent to the foreground process group (apparently)
<shawarma> By whom?
<shawarma> Must be the kernel..
<Keybuk> -- entering new session
<Keybuk> pid: 9171
<Keybuk> pgrp: 9171
<Keybuk> sid: 9171
<Keybuk> -- execing shell script
<Keybuk> --shell
<Keybuk> pid: 9172
<Keybuk> pgrp: 9171
<Keybuk> sid: 9171
<Keybuk> --end shell
<Keybuk> ok
<Keybuk> so that's a session leader that execs a shell, which runs a single command
<Keybuk> the shell is 9171
<Keybuk> the process group and session of the simple command is also 9171
<Keybuk> but the pid of the thing run in it is 9172
<Keybuk> which makes sense
<Keybuk> doesn't get SIGHUP here
<Keybuk> aha
<Keybuk> does if it has a terminal
<Keybuk> -- entering new session
<Keybuk> -- taking control of terminal
<Keybuk> pid: 9618
<Keybuk> pgrp: 9618
<Keybuk> sid: 9618
<Keybuk> -- execing shell script
<Keybuk> -- shell 9618
<Keybuk> pid: 9619
<Keybuk> ppid: 9618
<Keybuk> pgrp: 9618
<Keybuk> sid: 9618
<Keybuk> -- end shell
<Keybuk> 9619 got SIGHUP
<Keybuk> -- exit
<Keybuk> right
<Keybuk> SIGHUP comes from the terminal control driver only
<Keybuk> that makes sense
<Keybuk> so the question is still valid
<shawarma> I forgot the question :)
<Keybuk> when upstart wants to kill a job, should it just send TERM to dash (which won't kill anything else since there's no terminal) or to the entire process group?
<Keybuk> and how will this affect services with multiple processes, since they'll all get TERM, rather than just the top one?
<shawarma> How does that work, actually? You iterate throguh the process space looking for things with the same pgid?
<Keybuk> killpg :p
<Keybuk> thom: how would apache cope with that?
<shawarma> I think each request each child is handling would be dropped and the top process would clean up the mess..
<Keybuk> yeah
<Keybuk> I think killpg is reasonable here
<Keybuk> (it's also what sysvinit does ... I never noticed that)
<Keybuk> *giggle*
<Keybuk> well, that change royally buggered up my test suite
* Keybuk adds setpgrp() calls to the test children
<Keybuk> yay
<Keybuk> job->cause is gone
<AlexExtreme> whoo
<Keybuk> though I now have a stack of issues with the new code ;o)
<Keybuk> in particular
<Keybuk>   start on foo and bar
<Keybuk>   stop on frodo and bilbo
<Keybuk> ...
<Keybuk> if you stop that, and then foo happens quickly afterwards, it will start again
<Keybuk> because the event tree still has the true values, and it's still enough to touch it
<Keybuk> but if it happens after it has properly stopped, you need both foo and bar to happen again
<Keybuk> (likewise for the stop on bit)
<Keybuk> the way to solve that, I think, is to reference an "Event Expression" not just the root "Event Operator"
<Keybuk> Event Expression would be the root Event Operator, and also an Event State
<Keybuk> if the root operator becomes TRUE, the matching events from the tree are copied into the Event State, and then the operator tree is reset
<Keybuk> the job would respond to the expression, so it retains the state while requiring the match to happen all over again
#upstart 2009-06-15
<Keybuk> make -C nih-dbus-tool check TESTS_ENVIRONMENT=memcheck  1262.20s user 17.42s system 72% cpu 29:13.49 total
<Keybuk> eep
<Keybuk> test suite is taking far too long these days <g>
<ion_> keybuk: :-)
<ion_> Not many authors can say that, which is a bad thing.
#upstart 2009-06-16
<ppawel> hey folks
<ppawel> does current (0.5.x) upstart provide dbus interface with methods and signals?
<ppawel> in ubuntu there is 0.3.9
<Keybuk> ppawel: yes
<Keybuk> though not on the D-Bus system bus
<Keybuk> it's a private D-Bus connection
<ppawel> hmm ok
<ppawel> is new version of upstart going to be compatible with 0.5 ?
<Keybuk> no
<ppawel> we are looking for integrating upstart for service management in our system
<ppawel> we were hoping for nice D-Bus API
<Keybuk> the next version of upstart will have that ;)
<ppawel> I understand, but what is the time line for next version ?
<ppawel> I guess Ubuntu 9.10 ?
<Keybuk> right
<Keybuk> i'm working fulltime on the new version right now
<ppawel> in what shape is it ? would you recommend using it ?
<Keybuk> I tend to recommend using 0.3 at the moment
<Keybuk> the new version doesn't build yet
<Keybuk> talking of which, brb
<ppawel> Keybuk, is it possible to talk to upstart 0.3.9 through D-Bus then? if yes, using the same API and configuration as is in 0.5 distribution? will D-Bus API change between 0.3 and 1.0?
<Keybuk> no, 0.3 uses a private IPC protocol
<Keybuk> sadmac: the cn_proc setsid patch has gone to lkml for the .31 merge window
<ppawel> Keybuk, ok thanks for the support, looking forward to the new version, also will watch fosdem talk later today
<sadmac> Keybuk: I take it that's your monitoring stuff? (or at least the setsid support therein)?
<Keybuk> yeah
<Keybuk> sometimes I really hate D-Bus
<Keybuk> Upstart's test suite yet again provides testing of other parts ;)
<sadmac> Keybuk: fun stuff
<sadmac> Keybuk: I'm hoping to do a second pass on that wiki page this weekend. Seems the biggest thing I'm out of sync on is creation/destruction of "instances"
<mbiebl> Md: hi
<mbiebl> have you seen, that most of udev-extras was moved into udev today?
<mbiebl> The only interesting bits left in udev-extras are the keymap handling stuff.
<Md> mbiebl: this is part of the reason I am waiting to package it :-)
<mbiebl> I just thought it was kind of ironic, that you submitted the ITP the very same day Kay moved over all the bits from udev-extras ;-)
<mbiebl> anyways, thanks for packaging it.
<mbiebl> Please keep me posted on the progress so we can coordinate future uploads of HAL etc
<mbiebl> e.g. for the ACL handling 
<Md> I doubt I will package a current udev before a couple of weeks, after I will finish with inn2 I first need to fix the bugs in the current one and then wait for libuuid from u-l to appear
<mbiebl> np
#upstart 2009-06-17
<hugo303> Fiveby5184
<hugo303> *slaps his head, hard, and changes password
<Keybuk> d'oh
<rikard> Does anyone know how to get upstart 0.3.9 to work with multiple dependencies?
<Keybuk> it doesn't
* Keybuk changed the topic of #upstart to: Upstart 0.3.10 "Two minutes to Belgium" | Upstart 0.5.1 "Unexpected item in bagging area" | http://upstart.ubuntu.com/ | âUnable to set oom adjustmentâ? Mount /proc before running init.
<sadmac> Keybuk: I didn't know there was going to be a 0.3.10...
 * sadmac would have written a lot more patches
<Keybuk> heh
<Keybuk> I didn't necessarily plan one
<Keybuk> but assert() bugs are always worth fixing
<sadmac> damn, you should have held it up. I could have fixed 10 minor annoyances over the weekend.
<sadmac> Red Hat BZ is full of 3-liner "flag foo is missing from shutdown" type patches
<sadmac> well, its full of the complaints anyway
<Keybuk> those don't seem worth fixing ;)
<Keybuk> once you cave in and agree an option should exist, you have to keep it forever
<sadmac> Keybuk: you did say "SysV compatible" when you released. RH Engineering is holding you to that quite rigorously.
<sadmac> Keybuk: also, you could have cleaned up/taken the "preserve state across re-exec" patch
<sadmac> fedora carries it
<Keybuk> no I didn't
<Keybuk> that's obvious by the fact Upstart doesn't read /etc/inittab <g>
<Keybuk> preserve state across re-exec -> then that would have to be supported by 0.5 and 0.10
<sadmac> Keybuk: I seriously hope we're going to support that...
<Keybuk> support which?
<sadmac> preserving state across reload
<Keybuk> yes
<Keybuk> and once I do, that API will never be broken
<Keybuk> which is why I'm being slightly hesistant of writing down that API
 * Keybuk tries to figure out his branch mess
<Keybuk> *ahem*
<sadmac> Keybuk: I think introducing it into 0.3.* wouldn't be harmful. 0.5+ breaks from that in so many ways anyway
<sadmac> by 0.10 state transfer between minors wouldn't even make sense. 0.10 state doesn't even look that much like 0.3.9 state
<Keybuk> exactly my point?
<sadmac> Keybuk: so why not carry the 0.3 patch and retire the release in style?
<Keybuk> better question, why carry the patch?
<Keybuk> carrying it will suddenly bless that API, and there will be bugs when it doesn't work in future
<Keybuk> it doesn't cost you anything to apply it in Fedora after all
<sadmac> you can close with ENOTSUPP
<Keybuk> but it must be supported
<Keybuk> the patch is in the release
<Keybuk> see what I mean
<Keybuk> if I apply the patch and release with it, I'm declaring it supported
<sadmac> which it will be, in the 0.3.9 series only
<sadmac> across minors, you can just say "no"
<Keybuk> hmm, it's not an unconvincing argument ;)
<Keybuk> if you could file a bug (target 0.3), clean up and attach the patch (making sure it has test cases) - I'll do a 0.3.11 with it
<sadmac> sweet. I might compile a list of other things that might suit a 0.3.11. You can line-item those when I get them (they'll all be comparatively tiny)
 * sadmac wonders what else we're carrying in CVS...
<sadmac> shouldn't be much...
<sadmac> oh wow. 9 patches.
<sadmac> force-on-shutdown-reboot is a genuine bugfix. you'll want that.
<Keybuk> sure, file bugs on them
<sadmac> will do.
<Keybuk> use the "Target to release" thingy to set them as 0.3
<Keybuk> (you can also tag 0.5 and trunk that way too)
<sadmac> Keybuk: is ubuntu built on gcc43+ yet?
<sadmac> we're still carrying a patch to add a header file that needs
<Keybuk> yes
<Keybuk> limits.h?
<Keybuk> that one went into 0.3.10
<sadmac> yeah
<sadmac> cool
<Keybuk> as did an amd64 fix
<sadmac> Keybuk: oh, want to roll our events.5 manpage into a general release?
<Keybuk> sure
<sadmac> cool
<ion_> CVSâ
<sadmac> I'll have all this filed by saturday (earlier if my date stands me up tonight)
<sadmac> ion_: don't remind me
<sadmac> ion_: Fedora packages are in CVS. We have one branch per release. Inside each branch is an rpm specfile and all the patches we apply (upstream tarballs are kept separate in a lookaside cache and pulled in when we build)
<sadmac> its actually fairly easy to work with. we have a makefile that does the hard stuff.
<sadmac> cahnge specfile, copy in patch, commit, make tag, make build
 * Keybuk tries to make util build again
<Keybuk> shutdown.c: In function âshutdown_nowâ:
<Keybuk> shutdown.c:490: error: too few arguments to function ânih_dbus_proxy_newâ
<sadmac> phantastiq
<Keybuk> builds now ;)
<sadmac> 5 minutes. Not bad. But can you do it in space?
<Keybuk> I _AM_ in space
<sadmac> The boss took you along on his vacation this year?
<Keybuk> I wish
<ion_> I am in time.
<Keybuk> the most we get for good behaviour is a ride in the jet
<sadmac> I think Shuttleworth jokes are the equivalent of saying "your mom" to an Ubuntu dev.
<sadmac> at least the spaceboy ones.
<Keybuk> Your CEO is so dull he worked for Delta 
<Keybuk> etc.
<sadmac> Jim's actually a lot more fun than I thought. Not as intimidating as Szulik, but he drinks the Kool-aid, which is nice
<sadmac> runs rockbox on his iPod
<sadmac> look forward to the release of Red Hat Enterprise Music Bus soon
<sadmac> echo -e '#include<pthread.h>\n#include<unistd.h>\nmain(){pthread_t
<sadmac> t;pthread_create(&t,NULL,pause,NULL);pause();}'|gcc -o t -x c - -pthread
<sadmac> thats... a new way to specify a reproducer in BZ...
<Keybuk> BZ?
<Keybuk> oh, BugZilla
<Keybuk> damnit, the 0.3 code is easier to read than the 0.5
<sadmac> Keybuk: what's the cause?
<Keybuk> sadmac: of the code being easier to read?
<sadmac> Keybuk: rather of it being harder. Is there a particular disease?
<Keybuk> I don't like the way blocked stuff is done in 0.5 basically
<Keybuk> then again, at least it work s:p
<Keybuk> ...with respawn of running while post-start process
<Keybuk> test:job_process.c:1090: Assertion failed in job_process_terminated: job->state == JOB_POST_START
<Keybuk> \o/
<sadmac>  |
<sadmac> \
<sadmac> there's a regular on fedora-devel-list who's name is listed as King InuYasha
<sadmac> I can't tell if he's serious or not
<Keybuk> now, if distcheck would just pass ...
<sadmac> Keybuk: what's up with it?
<Keybuk> just taking its time
<Keybuk> there's no reason it shouldn't pass
<Keybuk> but I'm paranoid
<Keybuk> and out-of-tree builds hate me
<ion_> A process too slow? Throw more hardware at it. :-)
<Keybuk> /home/scott/co/upstart-0.5/upstart-0.5.2/_build/util/../../util/initctl.c:349: undefined reference to `job_get_name_sync'
<Keybuk> see
<Keybuk> HATRE
<Keybuk> HATE
<sadmac> carpe odium
 * Keybuk waits again
<Keybuk> Too Many Test Cases
<sadmac> Keybuk: we could probably parallellize a lot of them if we thought about how
* Keybuk changed the topic of #upstart to: Upstart 0.5.2 "Something, something, something, D-Bus" | Upstart 0.3.10 "Two minutes to Belgium" | http://upstart.ubuntu.com/
<ion_> Next up: 0.10. :-P
<sadmac> Keybuk: we went to GPLv3? I thought your license preferences tended the other way
<sadmac> Keybuk: you rewrote nih_dbus_tool in expat?
<sadmac> *or rather in C
<keesj> http://paste-it.net/raw/public/j16d3e1/ same kind of error  undefined reference to `dbus_message_iter_abandon_container'
<keesj> that one looks more like a dbus thing actualy
<mbiebl> Is that related to the D-Bus patch that Scott referenced in his announcement email?
<mbiebl> Keybuk: what bad things will happen, if this patch is not applied?
<Keybuk> sadmac: my licence preferences don't apply to Upstart
<Keybuk> that's up to Canonical ;)
<Keybuk> keesj: see NEWS
<Keybuk> mbiebl: Upstart won't combile, obv :)
<sadmac> Keybuk: oic
<mbiebl> Keybuk: ah,ok. So keesj' problems are indeed related to this missing dbus patch
<Keybuk> you can replace _abandon_ with _close_
<Keybuk> but then libdbus will randomly assert() on you
<Keybuk> you can remove the lines, but then you'll get a memory leak
 * sadmac is near to cleaning up the hideous locking in linux's wait*() syscalls
<sadmac> no more quantum-critical sections!
<Keybuk> cisco in "whinging about licensing" again shocker
<keesj> I have the same problem . I feel very sorry
 * keesj goes and reads the GPLV3 again
<Keybuk> keesj: why?
<Keybuk> What is it about v2->v3 that you don't like?
<keesj> I don't think is about liking or not. at least at work we gplv3 will be very hard(read impossible) to sell.
<Keybuk> you don't ship any current versions of FSF software?
<Keybuk> what version of gcc do you use?
<keesj> our company has booth hardware and things like maps they really like to sell
<Keybuk> you can sell hardware with GPLv3 software on it
<keesj> we use recent gcc like 4.2 but that doesn't pose restrictions on the software we create 
<keesj> I can sell a close source project compiled with gcc so that is not a good example
<Keybuk> gcc 4.2 is under the GPLv3
<Keybuk> which version of coreutils do you use?
<keesj> don't know something relased with the code sourcery we use let met check
<Keybuk> CodeSourcery the company/products?
<keesj> the toolchain
<Keybuk> they're partners of Canonical, and certainly include GPLv3 pieces
<keesj> nope , well perhaps lgpl
<Keybuk> (you know that GPLv2 software can't be linked with LGPLv3 right? :p
<Keybuk>  so every single piece of GPLv2+ software on a system linked to an LGPLv3 library is automatically GPLv3 :p)
<keesj> well I guess I need to find an other job :p
<Keybuk> seriously though
<Keybuk> why the concern?
<Keybuk> we do work in the embedded and mobile spaces
<Keybuk> no GPLv3 trouble there
<keesj> dear Mister GSM provider please provice us the source code for your GSM stack so we can abuse your network, and make your device not FCC compliant
<sadmac> oh boy do people ever have some funny ideas about what this license means
<Keybuk> you don't need the source any more than you do in GPLv2
<Keybuk> you can ship GPLv3 code in the same system as commercial code
<Keybuk> just as you can with GPLv2
<keesj> no it's not about source it's about freedom for the devloper !
<Keybuk> huh?
<sadmac> keesj: what freedom do you think has gone missing?
<keesj> well the "tivoization" part for example or wanting keep control over what software runs on the embedded device
<sadmac> keesj: what's wrong with that? I paid for the damn device.
<sadmac> and LGPLv3 strikes all of that
<sadmac> explicitly
<sadmac> brb kernel
<keesj> Well quite frankly I will check the license of the binutils and such but for the moment assume GPLV3 is not OK
<sadmac> Keybuk: I don't see your patch in linus yet. Who said they took it?
<joshk> is there a way to print something to tty0 even during a quiet boot?
<joshk> i have this /etc/rc.local file that takes a while to run
<joshk> i've tried: stderr, and log_*_msg from /lib/lsb/init-functions, and nothing shows up
<joshk> i guess upstart is filtering out all of stderr and stdout. There's no way to work around that?
#upstart 2009-06-18
<mbiebl> Keybuk: still around?
<Keybuk> mbiebl: am back around now
<mbiebl> Keybuk: morning
<Keybuk> morning
<mbiebl> just wanted to let you know, that I stumbled upon a bug in 0.5.2
<mbiebl> which I then reported as 388753
<Keybuk> a bug not present in 0.5.1?
<mbiebl> not sure, but iirc not
<mbiebl> I was also wondering, when you plan to land more of the exiting stuff in trunk
<mbiebl> like the new process monitoring etc.
<mbiebl> currently the only difference I see between trunk and the 0.5 branch, is that 0.5 uses D-Bus for it's support utils
<Keybuk> The D-Bus stuff was a bit of a nightmare
<Keybuk> so I wanted to get that out of the way first, and make a release with it
<Keybuk> otherwise it would have forever been over my head
<Keybuk> (along with our security guy's knife :p)
<mbiebl> ah, nice ;-)
<Keybuk> going to start merging in the netlink stuff from today
<Keybuk> needs some main loop changes first
<mbiebl> looking forward to it.
<Keybuk> when do you head into London? Sunday?
<mbiebl> yeah
<mbiebl> will be there around 14:00
<Keybuk> cool
<Keybuk> you can't miss our office building really - it's the only tall one ;)
<Keybuk> I get down sometime Sunday evening
<mbiebl> cool
<mbiebl> Will the office building be open on Sunday?
<Keybuk> no :p  probably not
<Keybuk> there's free wifi at the hotel though
<Keybuk> plus London's nice to wander around
<Keybuk> weather is supposed to be good
<mbiebl> yeah, I planned to do explore London a little on sunday afternoon
<mbiebl> so I guess we will meet on sunday evening in the hotel then.
<mbiebl> looking forward to it.
<sadmac2> Keybuk: is this part of the time stuff you fixed recently? https://bugzilla.redhat.com/show_bug.cgi?id=506679
<sadmac2> and did that make it to 0.3*
<Keybuk> https://bugs.edge.launchpad.net/upstart/+bug/388873
<Keybuk> the same guy just filed that in LP
 * Keybuk links them
<Keybuk> handy tip btw
<Keybuk> (+) Also affects distribution
<Keybuk> Distribution: Fedora
<Keybuk> Source Package Name: upstart
<Keybuk> URL: paste bugzilla URL
<Keybuk> links the two together, and syncs information from BZ into LP
<Keybuk> it's not fixed, because I didn't know about it until literally minutes ago ;)
<Keybuk> going to confirm shortly
<sadmac2> Keybuk: theres 2 more things I want to try to get into 0.3.11: The state transfer stuff, and the -f option for shutdown (reboot has it, shutdown seems to be missing it for some reason)
<Keybuk> err, do you mean -f ?
<Keybuk> -f and -F on shutdown did strange things
<sadmac2> yeah
<sadmac2> we have a BZ complaining about it
 * sadmac2 wonders if jkatz' ticket about wanting upstart to eject CDs is still open...
<Keybuk> again, please do file bugs in LP if you have them in BZ and link them ;)
<sadmac2> never rolled that one, for reasons of "eeeew"
<Keybuk> it makes sense to file all your bugs upstream
<sadmac2> happily
<Keybuk> damn, mbiebl wandered off, was going to nag him too :p
<sadmac2> Keybuk: I'm a support engineer now, and the triager knows I have upstart knowledge, so come RHEL 6 all upstart bugs in RHEL will probably be going through me
<sadmac2> (unless they find so many that I can't handle them all :)
<sadmac2> Keybuk: I still don't see your patch in linus
<Keybuk> akpm has it
<Keybuk> it's somewhere in the firehose, it may not be part of the torrent yet ;)
<sadmac2> Keybuk: yeah. You didn't actually send it to Linus, I was wondering how it was going to get there :)
<Keybuk> you don't have to send everything to Linus
<sadmac2> yeah, but when you send a patch to lkml you usually CC /someone/ who gives a particular damn (unless you're just looking for reviews)
<Keybuk> right, Ingo and akpm saw it first
<Keybuk> sadmac2: use Also affects when adding BZ links
<sadmac2> Keybuk: yeah. Figuring that out from the update emails :)
<Keybuk> did you notice what I did on bug #388745 ? :p
<sadmac2> changed the summary
<Keybuk> I replied with a sentence with "however" without a following comma ;)
<sadmac2> oic
<joshk> Keybuk: still there?
<Keybuk> yes
<joshk> see scrollback from 22:27 UTC yesterday?
<Keybuk> I don't keep scrollback
<Keybuk> what did you ask?
<sadmac2> Keybuk, joshk: http://irclogs.ubuntu.com/2009/06/17/%23upstart.html
<sadmac2> big brother is watching
<arekm> hi, which dbus has function dbus_message_iter_abandon_container() ? stable 1.2.14 doesn't have it and upstart wants it
<arekm> that irclog was actually useful
<sadmac2> arekm: you need to apply the patch specified in the release notes
<Keybuk> joshk: you need to add "console output" to the job that runs rc.local
<joshk> Keybuk: just the word?
<joshk> like, in a comment or something?
<sadmac2> joshk: on a line of its own. no comment
<joshk> oh
<joshk> to the *job*.. huh.
<joshk> okay, and that'll kill the splash screen and display the output?
<sadmac2> joshk: it won't kill the splash screen unless the splash screen is designed to die when input is requested or strange output occurs.
<joshk> hmmm.. ok then. thanks
<arekm> sadmac2: ok, builds now but fails at
<arekm> BAD: wrong value for dbus_message_get_reply_serial (reply), expected 2 got 3                                                                                  at tests/test_dbus_message.c:155 (test_message_error).
<arekm> test
<Keybuk> arekm: odd, the test suite is not _always_ perfect
<Keybuk> though that implies something a little strange
<arekm> also UPSTART_INIT_DAEMON isn't defined in sources so build fails (0.5 bzr branch)
<Keybuk> arekm: *cough* fixed and push
<Keybuk> sadmac2: don't suppose you put the debug symbols from your upstart builds anywhere?
<sadmac2> Keybuk: upstart-debuginfo-<versioncrap>.arch.rpm
<Keybuk> do you have older versions around?
<sadmac2> Keybuk: how old do you need?
<Keybuk> upstart-0.3.9-22.fc11.3586.rpm
<Keybuk> plus debuginfo
<Keybuk> i386.rpm
<Keybuk> sorry
<sadmac2> should be i586
<sadmac2> build policy bumped our minimum 32-bit arch
<Keybuk> Version-Release number of selected component (if applicable):
<Keybuk> upstart-0.3.9-22.fc9.i386
<Keybuk> from your BZ :p
<sadmac2> Keybuk: koji.fedoraproject.org is our build system. Its purged now and again, but its not terribly aggressive. All the packages are there.
 * sadmac2 finds that upstart version
<sadmac2> Keybuk: http://koji.fedoraproject.org/koji/buildinfo?buildID=93252
<sadmac2> specifically: http://kojipkgs.fedoraproject.org/packages/upstart/0.3.9/22.fc11/i586/upstart-debuginfo-0.3.9-22.fc11.i586.rpm
<Keybuk> those are fc11?
<Keybuk> not f9?
<sadmac2> oh, f9. missed your update
<sadmac2> we have that one too
<sadmac2> http://koji.fedoraproject.org/koji/buildinfo?buildID=80006
<sadmac2> And if you need more:
<sadmac2> http://koji.fedoraproject.org/koji/packageinfo?packageID=5768
<sadmac2> Keybuk: what are you inspecting?
<Keybuk> BZ #506679
<sadmac2> ah.
<sadmac2> wow. this guy filed an f9 bug a week before EOL
<sadmac2> impressive
<Keybuk> hmm
<Keybuk> still doesn't seem to match
<Keybuk> I can't apply his core files to your bianries
<sadmac2> notting: ^^prelink??
<notting> sadmac2: shouldn't affect corefiles, iirc
<Keybuk> https://bugs.edge.launchpad.net/upstart/+bug/388873
<Keybuk> core files are attached there
<Keybuk> if you run gdb on them, do you get better results?
<sadmac2> I don't have an F9 box handy
 * sadmac2 should probably be doing something about this IOMMU thing he's working on
#upstart 2009-06-19
<Keybuk> this bug is, err, bugging me
<Keybuk> it looks like four jobs were started from the same event
<Keybuk> and the one that made it then freed that event, despite the refcount
<Keybuk> sadmac2: oh, I'm going to beat you
<sadmac2> Keybuk: what's going on? Give me the 1 hour of sleep version.
<Keybuk> you know that "rewind the data and upstart crashes" bug?
<sadmac2> yes
<Keybuk> I think it's caused by a Fedora patch
<sadmac2> which?
<Keybuk> not sure yet
<Keybuk> but I suspect the re-exec one
<sadmac2> well I didn't write that, so its all good
<sadmac2> mostly good...
<Keybuk> just need to prove it
<Keybuk> basically an inviolate constraint is being violated ;)
<Keybuk> hmm
<Keybuk> I can't see anything about your patch that might do that, sadly
<sadmac2> have you reproduced this thing?
<Keybuk> nope
<Keybuk> though his log just made me go "HUH"
<Keybuk> I like following state machines on paper
<Keybuk> it's SO MUCH FUN
<ion_> :-)
 * Keybuk now has ice cream
<Keybuk> I have reached the event that kills everything
<Keybuk> I can see it on the event queue
<Keybuk> (the bit of paper on the rhs of my desk)
<Keybuk> Handling started event
<Keybuk> ? goal changed from stop to start
<Keybuk> ? state changed from waiting to starting
<Keybuk> ? respawning too fast, stopped
<Keybuk> ? respawning too fast, stopped
<Keybuk> ? goal changed from start to stop
<Keybuk> ? state changed from starting to waiting
<Keybuk> ... wonder whether that could be it
<Keybuk> the double "respawning too fast" is kinda odd
<Keybuk> but, more than that, the respawn detection is the one thing that could be broken by the date spooling backwards
<Keybuk> kids
<Keybuk> remember
<Keybuk> time(NULL) is not monotonic
<Keybuk> https://bugs.edge.launchpad.net/upstart/+bug/388873/comments/26
<Keybuk> gnnnrgh
<Keybuk> this is a bug
<sadmac2> Keybuk: as opposed to?
<Keybuk> as in, I can now, following the code, see how it goes wrong :)
<sadmac2> oic
<sadmac2> can you /fix/ it though?
<Keybuk> first I write a test case ;)
<Keybuk> and forward port that to 0.5 to check
<Keybuk> I'm pretty sure 0.5 is expressly not vulnerable, because I totally rewrote the event queue there
<Keybuk> interestingly, I appear to have rewritten it to exactly avoid this issue
<Keybuk> will check the test cases there to see whether I already hit this bug, or a similar one, and didn't realise
* Keybuk changed the topic of #upstart to: Upstart 0.5.2 "Something, something, something, D-Bus" | Upstart 0.3.11 "For Friday, June 19th 2009, I'm Jon Masters" | http://upstart.ubuntu.com/
#upstart 2009-06-20
<ion_> keybuk: Have you already proposed your magic sauce to make Upstart handle forks et al. to be merged to Linux? (2.6.31?)
<Keybuk> ion_: yes
<Keybuk> everything but setsid() is in 2.6.29 I think
<Keybuk> hoping that the setsid() notification will be in .31
<ion_> keybuk: Cool
#upstart 2010-06-22
<[diablo]> moin moin
<[diablo]> anyone about?
<[diablo]> morning all
<[diablo]> anyone about please?
<JanC> [diablo]: if you have a question, ask it, and then stay around--if somebody knows the answer, they will answer when they are online & have time
<[diablo]> hi JanC 
<[diablo]> sorry, reason I asked it was dead here when I last tried
<[diablo]> ok here goes
<[diablo]> basically I have a problem with ubuntu 10.04 not starting qemu-kvm and libvirt-bin on boot
<[diablo]> it only started after I changed my NIC to bridge mode
<[diablo]> anyway.... I started looking at the rc.N ... all is set correctly..
<[diablo]> then I checked the upstart jobs, yep.. all there
<[diablo]> but... I want to start debugging it (upstart)
<[diablo]> I look at man init
<[diablo]> and I see it says in the files section at the bottom
<[diablo]> FILES
<[diablo]>        /etc/init.conf
<[diablo]>        /etc/init/*.conf
<[diablo]> but there is no /etc/init.conf file
<[diablo]> and I want to work out the boot order of the services that upstart does on boot
<JanC> if there is no init.conf it's not used  ;)
<[diablo]> ohhhh
<[diablo]> k
<[diablo]> so, the order of the services starting???
<JanC> so, only look in /etc/init/*.conf
<[diablo]> nod
<JanC> well, that depends on the scripts in that directory
<[diablo]> ok is there a primary script, first point of execution?
<JanC> you might want to read init(5) (run "man 5 init")
<[diablo]> ok
<JanC> basically, it starts services based on events
<[diablo]> ok
<ion> I seem to remember a known bug regarding bridge initialization in Ubuntu. Youâll probably find it on Launchpad.
<[diablo]> JanC, the bridge is working actually
<[diablo]> JanC, the problem is that qemu-kvm and libvirt-bin must now be started manually once the machine has booted
<JanC> lookign at their init scripts, it seems like they should start on startup
<JanC> well, they should start on runlevel 2, 3, 4 & 5
<[diablo]> actually, due to faffing around with update-rc.d ... I have sysv links
<[diablo]> I will remove them
<[diablo]> gonna reboot the box now
<[diablo]> and see...
<JanC> there should be a symlink /etc/init.d/libvirt-bin -> /lib/init/upstart-job normally
<[diablo]> nod
<JanC> (which implements sysv-compatibility)
<JanC> and LSB-compatibility, I suppose
<[diablo]> nope, LSB nope
<[diablo]> ok, just rebooted...
<[diablo]> nada de nada ... still neither service is running
<JanC> does your hardware support kvm?
<[diablo]> this is weired 
<[diablo]> yep sure does.. if I manually start the services, all is good
<[diablo]> and previously it all worked, it was only when I changed to bridge that these two services stopped booting
<JanC> ion: maybe try what ion said: he thinks there is a known bug about that  ;)
<[diablo]> in the bridge-utils package ion ?
<[diablo]> sorry, was thinking it was you (JanC) who said it
<JanC> might be in libvirt or whatever
<[diablo]> ok, but that should not effect qemu-kvm
<[diablo]> as that just does a modprobe 
<JanC> and it doesn't modprobe?
<JanC> modules aren't loaded?
<[diablo]> nope
<[diablo]> but if I manually run it now
<[diablo]> diablo@beast:~$ lsmod |grep kvm
<[diablo]> diablo@beast:~$ sudo service qemu-kvm start
<[diablo]> [sudo] password for diablo: 
<[diablo]> qemu-kvm start/running
<[diablo]> diablo@beast:~$ lsmod |grep kvm
<[diablo]> kvm_intel              46296  0 
<[diablo]> kvm                   286392  1 kvm_intel
<JanC> /etc/default/qemu-kvm has "KSM_ENABLED=1" ?
<JanC> although, that shouldn't change things on manual start
<[diablo]> yep
<[diablo]> enabled
<[diablo]> itÂ´s gotta be something with the bridge
<ion> The bug might be against the upstart package, or even the udev package.
<ion> or ifupdown
<[diablo]> hi ion 
<[diablo]> well, it only started once I changed to bridge 
<[diablo]> will just check launchpad about what your saying ion 
<JanC> [diablo]: maybe also ask in #ubuntu-virt and/or #ubuntu-server
<JanC> https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/580454 might be the bug ion was thinking about
<[diablo]> thanks JanC 
<[diablo]> looks about right
<[diablo]> well
<[diablo]> mmm sort of
<[diablo]> but I will just have to fire the two services up manually until a resolution is found
<[diablo]> many thanks for you help JanC and ion 
<[diablo]> all the best
<hallyn> on this vostro 1220, in order to get it to respect 'auto eth1' (eth1 being broadcom sta wireless) in /etc/networks/interfaces, i had to add 'pre-up exec ifdown -a' to /etc/init/networking.conf
<Psi-Jack> Oh cool. There's an entire channel just for upstart eh?
<Psi-Jack> Anyway. I'm trying to learn about upstart, and the documentation for it, is minimal at best so far that I can see. What I'm trying to work with now is respawn and limit. If I understand it right, basically by using respawn, a watchdog tracks the process and respawns it should it tie by abnormal means without using upstart process control, correct?
<mbiebl> Psi-Jack:  upstart (/sbin/init) tracks the process
<Psi-Jack> Right. :)
<Psi-Jack> So if I flagged respawn on, for example, my keepalived upstart-job, and I killall -9 keepalived, upstart should respawn it basically correct?
<ion> Yep
<Psi-Jack> How's the limit definition work?
<ion> See init(5)
<Psi-Jack> Well, that doesn't show much at all.
<Psi-Jack> Ahh wait. ;)
<Psi-Jack> Now that, makes a lot more sense. ;)
<Psi-Jack> With upstart supervising a process, say, keepalived, which I setup so that conntrackd and ipvsadm are linked with keepalived's starting and stopping events, if I killed keepalived abnormally, would conntrackd ad ipvsadm follow with it, or would they remain running?
<ion> I think theyâll be restarted when keepalived is respawned, but better check that for yourself.
<Psi-Jack> Hmm. I'm testing it now, before adding the respawn part to it, just to see what happends.
<Psi-Jack> There is one thing that has me boggled a bit, though.
<Psi-Jack> When I was making an upstart job for ipvsadm, I had some issues.
<Psi-Jack> I ended up having to use pre-start script and post-stop script so it wouldn't actually try to track the process itself, but what happends when I start ipvsadm otherwise, it loads it as [ipvsadm_syncmaster] and/or [ipvsadm_syncbackup], instead of as a normal process.
<Psi-Jack> upstart fails to keep track of that it seems.
<Psi-Jack> So, is it possible somehow to get an upstart job to basically track a kernel process thread, rather than a normal process daemon or fork?
<neal> I'm trying to write an upstart job for Maemo 5 (upstart version 0.3.8).  My program forks into the background.  It seems that this means upstart doesn't know how to find its pid and kill it.  (stop ...)  Should I use pre-stop and kill it manually?
<Psi-Jack> neal: expect fork
<Psi-Jack> If it forks out 1 process, expect fork. If it daemonizes and runs 3 processes, expect daemon
<neal> I thought that was only 0.5.0+
<Psi-Jack> Oh.
<Psi-Jack> hmm. Maybe. ;)
<Psi-Jack> Upgrade time. ;0
<neal> this is Maemo 5
<neal> I can't.
<Psi-Jack> There is only do, or do not, there is no can't.
<neal> sure.
<neal> Any other suggestions?
<Psi-Jack> I personally only know more of the newer stuff about upstart, so I have nothing.
<Psi-Jack> without the advancements upstart's gone, I probably wouldn't be using it like I am now.
<Psi-Jack> Personally, I'm curious how well the cron-like advancements are coming." :)
<ion> Perhaps with 0.10, which should be released for Ubuntu 10.10 if all goes well.
<Psi-Jack> That soon eh?
<Psi-Jack> Well, it'll probably be a while till I switch off 10.04. Probably end up sticking with it till the next LTS.
<Psi-Jack> Hmm
<Psi-Jack> Has any progress been made on an apache upstart job script?
#upstart 2010-06-23
<Psi-Jack> I have a stuck job that's stop/killed, process 1511, but I can't start it successfully.
<Psi-Jack> I mean, it just flat out will not start for anything.
<Psi-Jack> Even after a reboot of the system it's still stuck like that.
<bleungchromium> hello
#upstart 2010-06-24
<Psi-Jack> Hmm
<oli1980> Hi all, i have a strange issue inside an linux vserver guest: when stopping ssh with "stop ssh" nothing happens, ssh simply get's not stopped
<ion> I take it âstatus sshâ lists the correct pid?
<Stevee> good evening
<Stevee> i`ve a question to the upstart feature to dealing with profiles
<Stevee> i`ve found an article in the wiki, but if i try to execute the command "initctl profile <profilename>" i got the error invaild command
<ion> Not implemented yet.
<Stevee> so is this feature full included or will it be included or has it been removed... ?
<Stevee> mhm, any idea when this feature will be inplemented ?
<Stevee> the idea to deal with such profiles is very great !
<ion> Iâm not exactly sure what features will make it into 0.10 and what wonât, but that will be a major release and it hopefully happens in time for Ubuntu 10.10.
<Stevee> that sounds great
<Stevee> thanks man
<Stevee> and is there any deadline planned for the release of the 0.10 ?
<Stevee> will be that in a half year, year, 5 years....
<Stevee> it would be great to know that for planning in future etc
<ericholscher> I just added my own job to /etc/init (which didn't exist before), and 'start jobname
<ericholscher> ' is saying it doesn't exist -- do i need to do something for it to re-read my jobs?
<ion> Youâll probably find a parse error in syslog.
#upstart 2010-06-25
<candyban> Hi guys. I'm having an issue with ubuntu 10.04 where some scripts (e.g. snmpd, conntrackd) do not start properly because some interfaces are not ready yet (e.g. eth2/eth3). Both scripts have Required-Start: $network, so I wonder if there is a bug in upstart where it does not wait for the dependency to be met before starting the script
<candyban> anyone alive in here?
<candyban> Is it possible for upstart to run /etc/rcX.d serial rather than parallel ?
<candyban> can I force scripts to somehow wait for "all" interfaces to be available & configured before continuing?
<twb> On Ubuntu 10.04, there are upstart services that I wish guarantee are NEVER EVER started, but due to package dependencies, I can't simply remove the package via apt.
<twb> Since "update-rc.d foo disable" and policy-rc.d are not applicable, my next instinct is to "dpkg-divert --rename /etc/init/avahi-daemon.conf", so that upstart will see (and hopefully ignore) a file "/etc/init/avahi-daemon.conf.distrib".
<twb> Is there a better way to blacklist services?
<candyban> twb, I'm here for help myself on 10.04 ... usually when I have a problem like that, I go ugly and just do chmod -x /usr/sbin/avahi-daemon
<candyban> twb, or I suppose you can edit /etc/init/avahi-daemon.conf
<twb> Permissions on non-conffiles aren't preserved
<twb> But yeah, you could dpkg-divert /usr/sbin/avahi-daemon
<candyban> twb, just add exit 0 at the top of /etc/init/avahi-daemon.conf (not sure if that works)
<twb> Unfortunately, upstart jobs are a hodge-podge of DSL and embedded sh
<twb> So I doubt that would work.
<twb> In any case, editing the file is basically what I'm trying to avoid.
<oli1980> Hi all
<oli1980> i have a strange issue with upstart :/ when trying to stop ssh in Ubuntu 10.06 the stop command does not return
<soren> twb: Just remove the job?
<twb> soren: you mean rm -f it?
<twb> Hmm, I suppose that WOULD work, because it's a conffile
<soren> twb: Yes, that's what I mean.
<soren> twb: It's absolutely supported. And absolutely offtopic for this channel, but there you go :)
<twb> Sorry!
<twb> I guess because upstart jobs (i.e. conf files) are distro-specific, and thus off-topic?
<soren> twb: Conffile handling is not an upstart issue.
<twb> Righto
<oli1980> when i try to stop ssh with "stop ssh" i simply get in the debug of init  init: job_process_handler: Ignored event 20 (5) for process PID
<candyban> soren, is there a way to start the network and make all the rest wait until that is completed?
<soren> candyban: Generally, no.
<soren> candyban: Mostly because there's no way to know when you're going to be done configuring the network.
<soren> candyban: I mean.. It's very difficult to define when configuration of the network has been completed.
<candyban> soren, I'm having trouble with snmpd (which I bind on eth3) and conntrackd (which syncs on eth2)
<soren> candyban: then start them when they come up.
<candyban> soren, they are both started before the network is properly initialized
<soren> candyban: "start on net-device-up IFACE=eth2"
<soren> Adjust as appropriate.
<soren> This is assuming an Ubuntu system, by the way.
<soren> Other distros may or may not have a net-device-up event.
<candyban> soren, 10.04 (but snmpd and conntrackd are "regular" init scripts in /etc/init.d ... there is no equivalent in /etc/init ... do I need to recreate the scripts?
<soren> candyban: You can also add a post-up line to your network configuration in /etc/network/interfaces that just calls the relevant init scripts. This is completely off-topic here, though. If you want to discuss this, please take it somewhere like #ubuntu-server
<candyban> soren, I never had these kinds of problems with regular SysV boot ... so I spent most of today learning about upstart as I want to understand what and where it goes wrong and how I can fix it the right way. (e.g. creating a new upstart script for snmpd/conntrackd)
<soren> No, with sysv boot you had different problems.
<candyban> soren, true, but at least it was predictable. Now booting of certain services fails/succeeds at random
<candyban> soren, anyways, back to topic. Should I create a new /etc/init script (or can I modify the existing SysV-style script)
<soren> I'm not sure what you want me to say. Even driven boot is racy if not configured correctly. All you need to do is configure it correctly.
<soren> As I said:  This is  completely off-topic here, though. If you want to discuss this, please take it somewhere like #ubuntu-server
<candyban> soren, ok, thanks.
<bencer> hi all
<bencer> i'm having some issues with upstart starting squid 2.x on lucid
<bencer> syslog says:
<bencer> Jun 25 16:58:50 eboxdev1 init: squid main process (27716) killed by TERM signal
<bencer> Jun 25 16:58:50 eboxdev1 init: squid main process (28441) terminated with status 1
<bencer> but squid after his default shutdown_lifetime says:
<bencer> 2010/06/25 16:59:21| Squid Cache (Version 2.7.STABLE7): Exiting normally.
<bencer> it's like upstart was killing squid for not being stopped inmediately
<bencer> and look at the times, it matches the default 30sec squid shutdown_lifetime
<bencer> and the funny thing is that if i comment the pre-script on the upstart script i can't reproduce the issue
<bencer> i think i've found that the expect fork option doesn't work very well, just not using that and running squid with -N (do not background) works as expected
<bencer> going to submit a patch on squid package...
#upstart 2011-06-22
<jp_larocque> What's the best way to figure out why upstart is blocking system startup on something?  I'm having a heck of a time trying to write a couple of upstart job definitions.
<jp_larocque> Well, I'm disappointed to report that after maybe 6 hours across a few days of trying to do this the right way, the only tractible solution was to mangle existing definitions to call old /etc/init.d scripts.  Upstart is just way too complicated for me, and I can't predict how it makes decisions, or what it's doing.
<JanC> did you enable verbose logging?
<JanC> jp_larocque: are you using http://upstart.ubuntu.com/cookbook/ ?
<JanC> http://upstart.ubuntu.com/cookbook/#debugging
<jp_larocque> JanC: Verbose logging told me that my jobs weren't starting, and the lack of activity told me that there was a deadlock, but not the cause of either.
<jp_larocque> I have been reading through a bit of the cookbook, but not the entire thing.  I probably could have done more research before giving up.
<JanC> in that case, you'll have to see what the start conditions for the jobs that don't start are?
<jp_larocque> Well, I wrote the job definitions.  For the "setkey" defintion, there were no start conditions (which I think means start at any point not further restricted by other definitions), and for the "racoon" definition the start condition was "start on (started setkey and starting mountall-net)".
<jp_larocque> Which I optimistically thought meant that upstart would ensure setkey starts before racoon, and the start of mountall-net is blocked until racoon is started.
<JanC> no start conditions means it will only start when you start it manually?
<jp_larocque> But I'm having a hard time finding precise language that specifies how jobs are ordered.
<jp_larocque> Oh?  I had not realized that.
<JanC> you can use "start on startup" to start a job ASAP
<jp_larocque> But having upstart print something along the lines of "racoon blocked until `started job=setkey' event" would be immensely helpful in troubleshooting these issues.
<JanC> although "start on startup" means that it might start before filesystems are available etc.
<jp_larocque> Yeah.
<JanC> maybe that's okay, or maybe you want some other event to start it on
<jp_larocque> Anyway, thought I'd provide some feedback on why I gave up.  I could easily waste many more hours trying to get this done the right way, but I'm ready to have a booting computer with IPsec-protected NFS home directories now.  =)
<jp_larocque> Thanks for the information.
#upstart 2011-06-23
<dcorbin_work> Is there some reason an upstart script couldn't be written that would "generically wrap" an /etc/init.d script, as a migration aid.
<ion> In what way is that more useful than the current sysvinit compatibility stuff?
<ion> A future version of Upstart will handle sysvinit scripts natively, which actually is more useful.
<dcorbin_work> ion: I don't know anything about current compatibility.  I just know that I want to trigger an upstart job based on the start of an init.d script.
<mbiebl> dcorbin_work: you could use pre-start exec /etc/init.d/foo start
<mbiebl> post-stop exec /etc/init.d/foo stop
<dcorbin_work> mbiebl: It's more that I want my job to be triggered by an init.d script "event".  
<mbiebl> wrapping a sysv init script inside an upstart job will give you that
<dcorbin_work> Yes.  That's why I asked if it was possible write a generic upstart script that would do that for any old init.d script.
<ion> You can add e.g. âinitctl emit starting-fooâ, âinitctl emit started-fooâ, âinitctl emit stopping-fooâ, âinitctl emit stopped-fooâ to the sysvinit script to generate Upstart events.
<mbiebl> ion: I guess dcorbin_work doesn't want to modify each sysv init script individually
<dcorbin_work> ion:  But then I'm changing a script from some other package and I have to worry about it getting replaced
<mbiebl> iirc the fedora /etc/init.d/rc.d script (or whoever it is called)
<mbiebl> used to emit events when it started sysv init scripts
<dcorbin_work> My immediate need is just one script "dependency".  I just thought a general solution might be generally ehlpful.
<mbiebl> that doesn't work if you run /etc/init.d/foo directly though
<JanC> dcorbin_work: an alternative is to write an upstart job to replace the sysvinit script
<dcorbin_work> JanC: yes, but doesn't help me today:)
<JanC> if you write the replacement today it does  :P
<dcorbin_work> JanC: No, we haev to work with Ubuntu 10.4 :)
<JanC> dcorbin_work: Ubuntu 10.04 uses upstart, so what's the problem to write an upstart job?
<dcorbin_work> JanC: as an example, the postgres version we have installed doesn't use upstart.  We've written an upstart script for our software.  We'd like it to depend on postgres.  We'd like to not change the software as packaged.
#upstart 2012-06-18
<Guest95587> hey
<Guest95587> i wanna know if upstart can handle the return code of a service, like catch "-2" and restart the service
<anibalcesar> hi all
#upstart 2012-06-21
<wavded> can't seem to get setuid and setgid to work, following cookbook, the user is still root when starting the service, any ideas?
<wavded> running upstart 1.5
<SpamapS> wavded: can you pastebin your upstart job?
<kenwaln> Anyone familiar with using jsvc and upstart
<kenwaln> More specifically I'm on ubuntu and am trying to get a configuration right for jsvc.  It starts, but on stop gets stuck in state killed.  Any pointers?
#upstart 2012-06-22
<wavded> SpamapS: here is the script: http://pastebin.com/UuBcRTws
<resmo_> hi
<resmo_> i created a upstart conf for node but but when I try to start myserver I get a Unknown job
<resmo_> any hints what I am doing wrong?
<resmo_> config is in /etc/init/myserver.conf
<wavded> resmo_ that is the correct location, what is the contents of your upstart script?
<SpamapS> wavded: hm, that looks ok
<SpamapS> wavded: one side note, you do not need the 'script' and 'end script' bit
<SpamapS> wavded: and you might consider dropping the log redirection too, and just use 'console log'
<SpamapS> wavded: that will log to /var/log/upstart/your-job-name.log
<SpamapS> wavded: could you raise log-priority to info (sudo initctl log-priority info) and start your job.. then pastebin any logs that end up in /var/log/syslog from that action?
<wavded> SpamapS: sure
<wavded> SpamapS: one question, does restart <job> not reload the config if it changed?
<SpamapS> wavded: no it does not
<SpamapS> wavded: stop/start to do that
<wavded> ahh learned that yesterday, the hardway :)
<wavded> ok its not starting now for some reason: I get: un 22 10:17:26 adc-staging-web2 kernel: [307549.693232] init: redi respawning too fast, stopped
<SpamapS> wavded: should give you an exit code too
<jodh> wavded: I'd guess /usr/bin/node is failing since HOME is not set for user sawyer.
<wavded> status 2
<SpamapS> jodh: hey howdy btw. :) Really loving job logging, btw
<jodh> SpamapS: hi - how's things?
<SpamapS> jodh: oh 'bout the same
<jodh> SpamapS: :)
<SpamapS> jodh: yourself? About done with that rewrite of upstart in go? ;)
<wavded> ok, i tried adding env HOME=/home/sawyer to the config, didn't help, should i do it some other way?
<SpamapS> wavded: you should have some logs giving you a hint as to why it is failing
 * SpamapS goes afk for a bit
<jodh> SpamapS: well I was thinking fortran might make a comeback...
<wavded> ahh checked upstart log, looks like the /var/log/node/redi.log wasn't writable by sawyer
<wavded> does 'console output' handle that stuff
<wavded> ahh nm, got it, console log works, thanks for your help
<jodh> this might come in useful for others in the future: http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
#upstart 2013-06-17
<leehambley> hi all, can anyone tell me if there's a way to skip starting services when they're installed, I'm fighting netatalk and samba, i've implemented a policy-rc.d which forbids samba/etc -
<leehambley> my policy rejected them both, and I see the syslogs from my policy-rc.d - but I still ended up with /etc/init/{sa,nm}bd.conf files, and the services both started
<erkules> ahoi, I want to 'globaly' define a tmpfile pass a value from pre-start to exec. For that I would like to do something like env ARGUMENT=$(mktemp) in the 'global' section. It doesn't work and using a fixed path is no solution for me :(
<xnox> leehambley: echo "manual" | sudo tee /etc/init/NAME.override
<leehambley> xnox: thanks -- is the lack of support for policy-rc.d a known problem?
<xnox> leehambley: where NAME is whichever job you want to override, e.g. sabd.override to override sabd.conf
<leehambley> thanks
<xnox> leehambley: there is full support for update-rc.d in saucy and up, not sure about policy-rc.d. Need to check....
<leehambley> thanks
<xnox> erkules: you should define environmental variables outside of any block, and then set it in pre-start, and read it in script/post-start.
<xnox> erkules: http://upstart.ubuntu.com/cookbook/#export ? should work. Can you pastebit your example that is not working?
<leehambley> xnox: after creating that file, do I have to do anything to make upstart recognise it, it doesn't seem to be working
<xnox> leehambley: define "working" ? what did you put into the .override file and what did you expect to change?
<xnox> leehambley: if it has stanza "manual" init, upon boot that job will not automatically start.
<leehambley> xnox: I expected that service not to start when it's installed, and not to restart if I kill it (kill -9 <thepid>)
<leehambley> the second part isn't working
<leehambley> I put the word manual(\n) in that file
<erkules> xnox: I can setting an variable 'outside' works. But doing some expansion stuff doesn't i.e. env ARG=$(mktemp) or env ARG=`mktemp` then ARG is set to $(mktemp) and not the output of the command mktemp
<xnox> erkules: correct. do env ARG=; in pre-start ARG=$(mktemp); and then in exec/script/post-start/pre-post-stop it should be available.
<xnox> erkules: also please paste your job. Why don't you do everything in "script; end script"? =)
<xnox> leehambley: first you need to stop them with "sudo stop NAME"
<leehambley> alright, roger that
<xnox> leehambley: then in .override put "pre-start script \n stop \n end script"
<xnox> leehambley: thus any attempts at starting/respawning jobs will be, well, denied.
<leehambley> thanks, that looks just like a bigger hammer than "manual"
<xnox> leehambley: yeah. manual, only negates "start on" conditions, but package upgrades do "start NAME" explicitly more or less.
<leehambley> thanks for the clarification xnox :-)
<erkules> xnox: http://paste.debian.net/10938/
<erkules> xnox: Your workaround didn't worked. So I did it statically 
<xnox> erkules: can errors go to stdout or stderr? as they will be collected into /var/log/upstart/mysql anyway.
<xnox> erkules: ah you are parsing it as well...
<erkules> xnox: every tip is welcome
<erkules> :)
<xnox> erkules:" A script section cannot modify the value of a variable defined in a job configuration file for other script sections."
<xnox> sigh
<xnox> erkules: http://upstart.ubuntu.com/cookbook/#environment-variables
<erkules> xnox: thats why my original plan was to do ARGUMENT=$(mktemp) outside. Which as you rightly told is not working.
#upstart 2013-06-18
<agend> hi - I need help with controlling uwsgi which is installed with pip - how should the /etc/init/uwsgi.conf look like?  http://pastebin.com/vMK3Wyrb - i have this now
<xnox> agend: http://uwsgi-docs.readthedocs.org/en/latest/Upstart.html is fairly good and comprehensive guide.
<xnox> agend: looks ok.
<agend> my problem is that it doesn't want to restart
<agend> sudo service uwsgi stop                stop: Unknown instance: 
<xnox> agend: see the doc I linked to, and use die on term option.
<agend> before sudo service uwsgi start gave me that: uwsgi start/running, process 16272
<agend> yeah I use die-on-term
<xnox> agend: and ideally use emperor option as well.
<agend> not sure i need emperor
<xnox> agend: check with ps, that the pid of uwsgi actually matches what status uwsgi gives you.
<agend> and when i do: pgrep uwsgi  - i can't see any process with this nr
<agend> it does not match
<xnox> in that case they way you are starting uwsgi it either forks or demonizes and expect is then wrong.
<agend> uwsgi start/running, process 16534
<agend> vagrant@one:~$ pgrep uwsgi
<agend> 16536
<agend> 16541
<agend> 16542
<agend> 16543
<agend> 16544
<xnox> start with minimal sample, I'm not sure what all of your yaml options cause uwsgi to do.
<xnox> looks like you want to add: expect daemon
<xnox> to the upstart job.
<xnox> it's best to simply run uwsgi in the foreground. and then logs will be collected in /var/log/upstart/uwsgi
<xnox> agend: also at this point you'd have to manually  kill that uwsgi.
<agend> xnox: man - you are awsome - works now :)
<agend> xnox: sorry - i meant to say awesome - i just checked that awsome might mean something opposite, so yeah u r great thanks a lot
<erkules> is there a way to make upstart do some checks if I do a status $service?
<xnox> erkules: why would you need that?
<xnox> erkules: generally no. status purely reports status of the pid from upstart's point of view. If it's still running & present than it's all good.
<xnox> erkules: maybe you should use monitoring e.g. nagios or check_mk ?
#upstart 2013-06-19
<erkules> xnox: thx
#upstart 2013-06-20
<Grivvel> Hello! I'm having an issue where upstart seems to be respawning my process if it shuts down during the pre-stop script. As far as I can tell from the documentation, that isn't intended. Does anyone know what might be causing it?
<Grivvel> Aha, nevermind. It looks like this is already a documented bug https://bugs.launchpad.net/upstart/+bug/568288 . But it looks like there are workarounds :)
<Sargun> Is there a good way to manipulate user upstart jobs from system upstart jobs?
<xnox> Sargun: no, not really, you could drop/edit new jobs in one of the "user upstart job" locations - e.g. /etc/xdg/upstart/
<xnox> Sargun: and system jobs can send events that user upstart jobs notice.
<xnox> Sargun: but you wouldn't be able to start/stop/status user upstart jobs from within system one.
<Sargun> Hm
<xnox> Sargun: what do you want to do & why? =)
<xnox> Sargun: sudo -u foo start bar
<xnox> should work.
<xnox> ;-)
 * trapni waves
<trapni> Hey. As of 6.13.2, I'm having a worker.init upstart file that spawnes a worker with a given $ID, then I have a generic workers.init that spawns all workers with their given ID, just like in the cookbook. Now, however, I want to globally restart them without writing the loop everytime again, just by `initctl restart workers` - but that doesn't seem possible, is it ?
#upstart 2013-06-21
<joaojeronimo> does anybody happen to have a handy riak upstart job config ?
#upstart 2013-06-22
<maxiaojun> "Packages of Fedora are available from Fedora 9 onwards." is no longer true
#upstart 2013-06-23
<Sargun> win 11
#upstart 2014-06-16
<CharlieSu> What is the best way to redirect UpStart logging for a service to a custom filename?  ( not /var/log/upstart - Ubuntu) 
<xnox> CharlieSu: du it yourself, e.g. by using "logger" command to take daemon log, or ask daemon itself to log elsewhere.
<lfaraone> I'm writing a job to start a process in a chroot. I have two processes I want to start, they're just in different chroots. Do I need two jobs, or can I do something cool with events?
#upstart 2014-06-17
<xnox> lfaraone: you need two jobs.
<lfaraone> xnox: okay. Can I, like, make them symlinks and key off the job name>
<lfaraone> *?
<xnox> lfaraone: no, symlinks are rejected
<lfaraone> xnox: hard links?
<lfaraone> :)
<xnox> lfaraone: you can make an "instance job" and thus have variable(s) that are replaced, but at boot only one instance would be started, unless you provide for multiple events to be emitted
<xnox> lfaraone: look at e.g. networking-interface.conf job in ubuntu
<PierrePaul> hi everyone :)
<PierrePaul> got a very good upstart question (I think)
<PierrePaul> I want to pass ENV vars to my process, the values of those vars are in /etc/environment
<PierrePaul> I'd like to use the 'env myvar=value' in my upstart script as defined by documentation
<PierrePaul> but I cant see to be able to do : env myvar=$MYVAR
<PierrePaul> so I tried to inject it in the exec, exec SUPERVAR=bleh /usr/sbin/php5-fpm .......
<PierrePaul> but exec of course hated that
<PierrePaul> so I moved my exec() to a 'script ... end script' stanza
<PierrePaul> but now it seems to affect some other internals, I would guess it calls start-stop-daemon internally and the $NAME is wrongly set 
<PierrePaul> anyone has an idea?
<occupant> so I'm running ancient upstart that doesn't have uid/gid. yeah, centos.
<occupant> is there any way to start something as another user and have respawn actually work?
#upstart 2014-06-18
<ion> occupant: You could use su and make the program avoid damonizing.
<ion> exec su -s /bin/sh -c 'exec "$0" "$@"' username -- program and args
#upstart 2014-06-19
<SpComb> how do I fix openvswitch-switch to start before the glusterfs mounts in /etc/fstab
<lazypower-travel> SpComb: Upstart uses signals. I dont have a specific example - but you can set your glusterfs upstart job to listen to your openvswitch job, and execute only after it's received that event.
<SpComb> glusterfs doesn't have an upstart job, it's mouned from /etc/fstab
<SpComb> but it seems to solution was to set '_netdev' in /etc/fstab for the glusterfs mounts
#upstart 2014-06-22
<wyattjoh> Having some issues with my script when I add setuid/setgid, it fails without writing any error messages. Running Ubuntu 14.04 and upstart 1.12.1
<wyattjoh> Config here: http://pastebin.com/JxzxTN71
<wyattjoh> Suggestions?
#upstart 2015-06-17
<catern> dear #upstart
<catern> why do I see logs for my failing job running post-stop 
<catern> and no logs of it running, you know, "start"
<catern> nvm I figured it out :)
#upstart 2015-06-20
<tomased> I have a process which takes a while to terminate running via upstart, when I run stop via terminal it will wait for the process to terminate properly but if I shut down the server it seems to kill it way early. I have setup kill timeout which works fine when stopping manually 
#upstart 2016-06-26
<eran> hey everyone
<eran> is anyone available for some upstart help?
<eran> hey again, is anyone alive?
<hallyn> irc is asynchronous - ask away, someone will most likely answer
<hallyn> oh s/he's gone
<eran> hey
<AnrDaemon> eran: Just ask your question and wait for answer. Peple are in tens of channels at once often.
<eran> sure, wasn't sure if anyone actually listens
<AnrDaemon> Don't make me laugh, please.
<eran> I'm running Ubuntu 14.04 with 1.12.1-0ubuntu4.2
<eran> I'm trying to setup an upstart script that starts a Python script
<AnrDaemon> 5 lines. Of which, 3 are informational.
<AnrDaemon> 2 are**
<eran> this Python script runs as a non-root user (it requires some environment settings).
<eran> so I setup a sysV script to start/stop this python script
<AnrDaemon> Well, add the lines for "non root user" and the environament you need.
<AnrDaemon> Either way, pastebin your current state.
<eran> ok
<eran> this is my current upstart config file:
<eran> http://pastebin.com/0Yngpsyw
<eran> I can start/stop the service through /etc/init.d
<eran> my question is, how can I start an event after for example an ansible-playbook as finished
<AnrDaemon> Remove "respawn"â¦ Now. start on - don't you have any better events to start on?
<eran> my ansible-playbook runs on /etc/rc.local
<eran> so I thought started on rc would be the place
<AnrDaemon> *facepalm*
<eran> :/
<eran> and why remove respawn?
<AnrDaemon> When you forget about existence of rc.local already?
<eran> yeah well
<AnrDaemon> Because you don't have a working script yet.
<eran> oh, ok 
<AnrDaemon> And respawn is a good way to kill your system with a broken upstart.
<AnrDaemon> job
<eran> good to know
<eran> how would you do it?
<AnrDaemon> Write upstart jobs for everything of course.
<eran> for both ansible-playbook command and the Python script?
<AnrDaemon> If you always need to start your script after that ansible thingy, the "start on stopped ansible-whatever"
<AnrDaemon> Of course. Why such a question ever raised?
<eran> ok, sounds good
<eran> other than that
<AnrDaemon> If your playbook is a short-living script, then makr it as "task".
<eran> yeah, obviously
<AnrDaemon> mark*
<eran> thanks a lot, I will try this 
<eran> I hope you're here tomorrow
<AnrDaemon> And avoid wrapping your jobs in a script ... end script, if at all possible.
<AnrDaemon> Someone will answer, if you ask a question.
<eran> I tried just using exec $DAEMON
<eran> but for some reason it failed starting
<AnrDaemon> "console log" and look for clues.
<AnrDaemon> Also http://upstart.ubuntu.com/cookbook/
<eran> just out of curious, why script/end script is bad?
<AnrDaemon> Because upstart does not execute these scripts by itself, but call /bin/sh -e -c for that.
<AnrDaemon> Which means, it does not monitor correct PID from the beginning.
<eran> ok
<eran> which leads me to the last question
<eran> the Python script is a wrapper for a C++ application
<eran> either way it won't know the correct PID, isn't it?
<eran> although I use expect fork, daemon
<AnrDaemon> So, fork or daemon?
<eran> fork
<AnrDaemon> As long as it monitoring correct PID in the end, should be fine.
<eran> will give it a try soon. 
<eran> I appreciate your time
<AnrDaemon> While you are "giving it a try", remove expect and respawn, both.
<AnrDaemon> Or you may get upstart stuck and will need to reboot the box.
<eran> will do!
<eran> thanks for your insight!
<eran> see ya
