#upstart 2006-12-12
* Starting logfile irclogs/upstart.log
<Keybuk> Testing control_handle_event()
<Keybuk> ==11675== Invalid read of size 4
<Keybuk> ==11675==    at 0x40F3EC: control_watcher (control.c:377)
<Keybuk> ==11675==    by 0x407C53: test_handle_event (test_control.c:853)
<Keybuk> ==11675==    by 0x407D88: main (test_control.c:873)
<Keybuk> ==11675==  Address 0x4D92740 is 80 bytes inside a block of size 128 free'd
<Keybuk> ==11675==    at 0x4A20423: free (vg_replace_malloc.c:233)
<Keybuk> ==11675==    by 0x4A2089D: realloc (vg_replace_malloc.c:306)
<Keybuk> ==11675==    by 0x410A00: nih_free (alloc.c:340)
<Keybuk> ==11675==    by 0x41226E: nih_list_free (list.c:168)
<Keybuk> ==11675==    by 0x40F3D5: control_watcher (control.c:375)
<Keybuk> ==11675==    by 0x407C53: test_handle_event (test_control.c:853)
<Keybuk> ==11675==    by 0x407D88: main (test_control.c:873)
<Keybuk> *sigh*
<Keybuk> I hate valgrind
<Keybuk> :p
<AlexExtreme> :)
<Keybuk> it keeps finding bugs
* theCore smiles
<AlexExtreme> heh
<Keybuk> happily they're usually just bugs in the test suite
<AlexExtreme> in other news, i just killed a box by accidentally using the wrong target when putting LinuxBIOS on it.... :p
<Keybuk> oops :p
<Keybuk> killed how badly?
<AlexExtreme> let's just say it's my new doorstep ;)
<AlexExtreme> doesn't even put anything out to the serial console
<Keybuk> d'oh
<Keybuk> oh, wow, that one was a real bug
<AlexExtreme> uhh, Keybuk, you might wanna disable anonymous comments on your blog or something, 'cause it's insanely full of spam
<AlexExtreme> :)
<AlexExtreme> bbl, food
<Keybuk> AlexExtreme: it doesn't have any concept of anonymous
<theCore> Keybuk: http://www.netsplit.com/blog/articles/2006/11/27/slippery-slopes#comments
<Keybuk> I tend to clear the feedback of spam every week or so
<theCore> maybe you should add a mini captcha
<theCore> Like: "What is the sum of 4 + 2:" 
<Keybuk> no idea how to do that
<theCore> http://sw-guide.de/wordpress/math-comment-spam-protection-plugin/
<Keybuk> it's not wordpress
<Keybuk> it's typo
<theCore> hmm...
<theCore> typo seems to be abandoned
<Keybuk> how do you figure?  a new version came out not long ago
<theCore> well, their website is http://typosphere.org/
<Keybuk> that's not abandoned, that's "doing a new website"
<theCore> click a link
<Keybuk> *shrug*
<theCore> it been flagged "under construction" for about 6 months now 
<Keybuk> do you have a better blog hosting suggestion
<Keybuk> ideally Python or Ruby and MySQL
<theCore> the best with Python would be to use Django, but it would a lot effort for a blog
<theCore> Wordpress is really the best right now
<Keybuk> Wordpress is PHP
<Keybuk> the guy who hosts my website won't run PHP
<theCore> ah
<Keybuk> he prefers his box to not get hacked a few times a week
<theCore> hehe
<_ion> http://tnx.nl/php.jpg
<Keybuk> I don't have the money or motiviation to have my own CoLo box
<Keybuk> and certainly don't have the time to admin it
<theCore> well, I could host it... 
<theCore> I got paid hosting
<Keybuk> that wouldn't make the situation much different, I'd be still relying on someone else, and what they can provide -- and I'd be a bit stuck if I lost contact with you
<Keybuk> at least thom is a close friend :)
<theCore> Keybuk: I would give you the full ssh access
<theCore> so, you wouldn't rely on me
<Keybuk> <Keybuk> and certainly don't have the time to admin it
<Keybuk> :p
<theCore> hehe
<theCore> ah well
<Keybuk> I have ssh access now
<thom> heh
<theCore> Keybuk: would you like to support me for the membership?
<thom> Keybuk: disallowing non-ajax comments has killed a lot of my spam
<Keybuk> theCore: of ubuntu-dev ?
<theCore> Keybuk: no, just ubuntumember
<theCore> I going to next, in #ubuntu-meeting
<Keybuk> thom: yeah, I've enabled that and "max links"
<theCore> to be the*
<Keybuk> meh, CC week
<Keybuk> theCore: sure
<theCore> thanks
<theCore> hopefully, I won't cut by everyone else ...
<thom> Keybuk: nods
<AlexExtreme> back
<Keybuk> do I need to say anything? :p
* Keybuk isn't sure how these things work <g>
<theCore> Keybuk: thanks
<Keybuk> theCore, Amaranth: congrats
<theCore> thanks
<Amaranth> thanks
#upstart 2006-12-13
<Keybuk> thom: no new spam since requiring ajax comments
<Keybuk> sweet
<thom> noice
<Keybuk> now I just have to delete the 50 pages of spam that appeared in the last week <g>
* Keybuk wishes there were a way to increase the page size
<thom> heh, yeah, did that for trackback spam yesterday
<thom> presumably page size is template dependent?
<Keybuk> no idea
<Keybuk> I mean the size of the feedback admin page
<Keybuk> 40 is too low
<thom> ah, right
<thom> yeah
<Keybuk> thom: (re: laptops) I'd guess you'd be championing the Lenovo still?
<thom> yep, my x60s is awesome love
<thom> (and core 2 duo parts should be available soon)
<Keybuk> still no touchpad though
<thom> feature not bug
<Keybuk> for you maybe
<Keybuk> I can't use the nipples
<thom> that explains a lot *g*
<Keybuk> the Dell D420 looks nice
<thom> but Dull.
<Keybuk> why Dull?
<thom> generic term for dell, innit. i've never been impressed with their build quality
<Keybuk> the build quality of the new Lenovos some people had at UDS didn't look great either, tbh
<thom> and i know what you do to laptops
<Keybuk> the new HPs looked fairly rugged
<thom> yeah? not seen one
<Keybuk> and jdub's Dell looked pretty rugged too
<thom> the lenovos around here have taken some pretty hefty battering
<Keybuk> someone had one of the new T? series Lenovo - 15" thing
<Keybuk> the case had already cracked, and they'd only had it a month or two
<Keybuk> I don't really want a 14" laptop though, 12" is what I'm after, and Lenovo don't have a good range
<Keybuk> very few options, underpowered comparatively to others in the same range, no touchpad, etc.
<Keybuk> screen is somewhat small now too
<Keybuk> somewhat low-res, I should say
<thom> yeah, 1024x768 is about my only complaint
<Keybuk> everyone with an X60 at UDS/AllHands had severe problems getting them to work with projectors
<Keybuk> have you had that?
<thom> never tried
<thom> i'm pretty sure ross has his working though
<Keybuk> AlexExtreme: ping
<AlexExtreme> Keybuk, pong
<Keybuk> AlexExtreme: need an e-mail address for the ChangeLog
<Keybuk> is alex@alex-smith.me.uk ok?
<AlexExtreme> yes, that's the right one :)
<Keybuk> thanks
<_ion> keybuk: Shouldn't TEST_FILE_RESET in nih/test.h have do { } while (0) around the definition?
<Keybuk> _ion: yes, probably
<_ion> http://johan.kiviniemi.name/tmp/nih_test.h.diff
<Keybuk> thanks
* Keybuk is particularly proud of TEST_CHILD <g>
<_ion> Yeah, it's neat. :-)
<Keybuk> TEST_FILENAME needs a do { } while (0) too
<Keybuk> AlexExtreme: did you ever solve bug #69950 ?
<AlexExtreme> it's a splashy bug I think
<AlexExtreme> so close it if you want
* ..[topic/#upstart:Keybuk] : Upstart 0.3.1 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs
<AlexExtreme> whoo, 0.3.1 ;)
<Keybuk>  28 files changed, 3020 insertions(+), 5350 deletions(-)
<Keybuk>  26 files changed, 4891 insertions(+), 7806 deletions(-)
<Keybuk> (upstart and nih)
<AlexExtreme> cool
<Keybuk> quite an impressive code changage, mostly confirmed to the unit tests :p
<Keybuk> confined, even, not confirmed
<Keybuk> heh
<AlexExtreme> :)
* AlexExtreme tests 0.3.1
<AlexExtreme> brb
<AlexExtreme> seems to work ok
<Keybuk> :-)
<Keybuk> it's not much different from 0.3.0, other than the minor bug fixes
<AlexExtreme> yeah
<AlexExtreme> now, i can play with syslog-ng sometime
<AlexExtreme> bbl
<Keybuk> hmm
<Keybuk> my machine doesn't boot
<Keybuk> I'm sure upgrading to 0.3.1 is a mere coincidence
<Keybuk> la la la
<Keybuk> *shrug* fine that time
<Keybuk> weird
<AlexExtreme> back
* maro reboots :)
<AlexExtreme> heh, that's just annoying
<AlexExtreme> i just bumped the gdm package, then a new gdm version gets release
<AlexExtreme> *released
<Keybuk> always the way
<Keybuk> http://upstart.ubuntu.com/wiki/JobStates
<Keybuk> ^ Would appreciate some eyes on that
<Keybuk> I think it's finally stable and actually correct
* AlexExtreme looks
<maro> ah, nice, initctl list looks normal again :)
<AlexExtreme> Keybuk, looks fine to me
<AlexExtreme> (nice diagram, btw ;))
<Keybuk> wasabi: ^
<wasabi> hi
<wasabi> oh ok
<Keybuk> does that look right?
<wasabi> reading
<_ion> keybuk: Looks good.
<wasabi> Keybuk: Random little thought I had while falling asleep. How does the system shutdown right now?
<wasabi> And how should it shutdown? We've talked a lot about starting, but what about system teardown?
<wasabi> There are two things I see, the teardown of existing jobs, then the execution of new jobs to put the machine into an off state
<wasabi> There's obviously the shutdown signal? How should that be used appropiatly?
<Keybuk> one moment
<wasabi> I was just modeling it in my head...  Say you have a "poweroff" task. Should that task be invoked on a signal named "shutdown"? Or is that task something which the user executes (by starting it using a control)
<wasabi> s/signal/event/
<wasabi> If it was a task, it could do stuff like:        for each mounted file system { emit file system unmounting; unmount; emit file system unmounted; } signal kernel to power off.
<wasabi> The unmounting of every file system in turn obviously causes everything to stop.
<Keybuk> right
<Keybuk> so there's a couple of distinct parts to this
<wasabi> And it can of course block on emitting both signals, causing it to wait until everything is shutdown.
<wasabi> That introduces another interesting thing. Windows has this thing where some services consciously do not stop on poweroff. They don't go through the effort of anything. The system just powers off.
<wasabi> They get the stop signal, but know it was caused by the system powering down, and so don't do any work.
<wasabi> filesystem unmounted will be available to those jobs that start explicitly because of it, but it's also not a good indicator of the reason for the file system being unmounted.
<wasabi> events being causes by other events, etc. Makes me wonder if $UPSTART_JOB should represent that stack. =)
<wasabi> Err, $UPSTART_EVENT
<wasabi> # The primary process is run when entering the start
<wasabi> state.
<wasabi> there's no "start" state defiend on the graph, just "exec process"
<wasabi> minor inconsistency i suspect
<wasabi> I really do feel that all events emitted internally should block though.
<wasabi> perhaps just for consistency.
<Keybuk> sorry, juggling a dozen things at once
<wasabi> s'ok, me too
<Keybuk> so right, two distinct parts
<Keybuk> one is the services that are running; those I think will be defined in terms of other things
<Keybuk> we can largely ignore them from a startup pov. because they're started as a side effect of things like "fhs filesystem", "networking", etc.
<Keybuk> likewise I think we can ignore them from a shutdown pov, because they're stopped as a side effect of the same things going away
<wasabi> yup
<Keybuk> the side effect here is that it'd negate teardown a little
<Keybuk> otoh, they'd all happen in parallel and most wouldn't have post-stop scripts
<Keybuk> the goal of teardown was to avoid shell scripts that just did kill -TERM with some time-wasting stuff
<Keybuk> we did the kill -TERM *anyway* since we sent kill signals
<Keybuk> the real problem is the shutdown tasks
<Keybuk> the mirror of the startup tasks
<Keybuk> the startup tasks are chained off "startup", and do things like mount the filesystems
<Keybuk> I think likewise, the shutdown tasks are chained off "shutdown" and do things like unmount them
<wasabi> Is shutdown in fact an event?
<wasabi> I know it is now.
<wasabi> Is that right, is that proper?
<Keybuk> it is currently
<Keybuk> I think it has to be, as you need to do something to start bringing things down
<wasabi> That seems more like using shutdown as a method call.
<Keybuk> I tend to think of events as method calls anyway :p
<wasabi> Heh.
<wasabi> If "shutdown" was a job/task, would that be any different/better/whatever?
<wasabi> Other than looking stupid:
<wasabi> initctl shutdown start
<Keybuk> I think that having it as a job is a little less flexible
<Keybuk> you could only do one thing with it, by modifying that task
<Keybuk> by having it as an event, you can write any number of tasks to happen simultaneously
<wasabi> Well, depends how you want to take it. What happens, in what order, on shutdown?
<Keybuk> e.g. bring the filesystem and network down at once
<Keybuk> shutdown is tiny
<wasabi> You can do that too. The task can emit furthur signals.
<Keybuk> kill all processes
<Keybuk> unmount filesystems
<wasabi> With more specific meanings.
<Keybuk> reboot()
<wasabi> Are we commiting to reversing the killall processes with unmounting file systems?
<Keybuk> right, but I think that it's better that if a distro wants to do that, they write a task that emits those signals "on shutdown"
<Keybuk> more flexible
<Keybuk> reversing?
<wasabi> hmm.
<wasabi> well, we are no longer going to kill anything in direct response to shutdown.
<wasabi> Them stoppnig will be a byproduct of their dependencies becoming unavailable:
<wasabi> networking, file systems.
<wasabi> That's what makes me think about the shutdown task.
<Keybuk> you'd still need an equivalent to "killall -TERM"
<Keybuk> otherwise you can't unmount the filesystems
<wasabi> It can do the work of unmounting the file systems, which indirectly emit filesystem-unmounting, and bring down services.
<_ion> Can't you do a lazy unmount?
<wasabi> And then it can do the work of killall -TERM.
<wasabi> Where is that work going?
<Keybuk> _ion: shutdown ... kinda critical it happens before we power off :p
<wasabi> Hmm... interesting thing, we aren't actually unmounting file systems on shutdown, either...
<wasabi> We are just making them RO, aren't we?
<Keybuk> wasabi: I figured there'd be a shutdown task started by the shutdown event :)
<Keybuk> wasabi: currently we unmount them
<Keybuk> we make the root ro
<wasabi> even /?
<_ion> kebyuk: Ah. :-)
<wasabi> And there is some sort of guarentee that /bin is on the same fs as /
<wasabi> heh
<wasabi> guess there'd have to be he
<wasabi> and /usr shouldn' tmatter.
<Keybuk> yeah, you can't have /bin and /sbin different to / :)
<Keybuk> otherwise you don't have /sbin/init and /bin/sh <g>
<wasabi> So, the shutdown task loops file systems, determines which it should unmount, does so, resulting in services stopping.
<wasabi> I'm thinkiing this
<Keybuk> windows services knowing stop was caused by poweroff ...
<Keybuk> we have that now in two ways
<Keybuk> 1) UPSTART_EVENT = "shutdown"
<wasabi> for fs in / /usr /usr/local /var /whatever_some_user_has; do ( initctl emit fs-bye-bye $fs *BLOCKING*; umount $fs; initctl emit fs-gone ) *; done
<wasabi> Err, that last * should be a &
<Keybuk> 2) any event after shutdown (or not) can be matched using complex-event-config
<wasabi> UPSTART_EVENT won't == shutdown.
<wasabi> It will equal something sill like network-going-away
<Keybuk> right
<wasabi> s/sill/silly/
<wasabi> Which is what makes me wonder. Should UPSTART_EVENT be the stack?
<Keybuk> it could be
<wasabi> That wa you could go if [ $UPSTART_EVENT starts with "shutdown" ] 
<Keybuk> start state defined on graph => it's defined as the name of the "exec process" node in the text below the graph
<wasabi> Another interesting thing... from the "shutdown" task.
<wasabi> If it sees that an event it emits breaks, such as fs-umounting, it can revert.
<wasabi> If /usr can't be umounted, it can log, then remount everything.
<wasabi> or just issue "startup" again.
<Keybuk> right
<wasabi> That can go all the way down to being unable to remount / ro
<Keybuk> started/stopped being blocking events => while it would be "consistent", they wouldn't actually block anything
<wasabi> quite interesting. ;)
<Keybuk> the interesting thing about the starting/stopping events is that they can actually block the job from starting or stopping
<Keybuk> started/stopped are emitted at the end of a state transition -- so if they block, it has absolutely no effect
<wasabi> That's true.
<wasabi> You are right. ;)
<Keybuk> so it'd be an extra code headache to produce no discernable effect :p
<wasabi> I guess, what I'd be afraid of, is by making shutdown an event, is that other software will in fact attempt to shut itself down on shutdown.
<Keybuk> no worry about that
<Keybuk> e.g. getty :p
<wasabi> When it should really not do so, it should wait for it's required resources to go away
<wasabi> And I think there needs to be one entry task for the procedure of shutting down... so it can do network/filesystem/whatever and detect failures to revert both.
<wasabi> network for instance doesn't go down in response to an event, it goes down because something tells it to.
<Keybuk> (back in 15-30 min)
<Keybuk> ok
<Keybuk> yeah for the most part I agree
<Keybuk> I think the reason I dislike having a forced shutdown task is that it's ... icky
<Keybuk> of course, I guess we could define neither in upstart, and just let distros decide whether they do "initctl start shutdown" or "initctl emit shutdown"
<Keybuk> but again, that's kinda icky, because it removes some consistency
<Keybuk> they'd all have a different /sbin/shutdown
<theCore> how often the bzr branch (http://bazaar.launchpad.net/~keybuk/upstart/main/) is sync'd?
<Keybuk> te
<Keybuk> theCore: dunno, hourly or so I guess
<theCore> rev 23?
<Keybuk> 297
<Keybuk> syndicate scott% bzr revno http://bazaar.launchpad.net/~keybuk/upstart/main/
<Keybuk> 297
<theCore> oh.... 
<theCore> nevermind
<Keybuk> did you bzr pull?
<theCore> yes
<theCore> the tree is sync'd
<Keybuk> ...but...?
<theCore> bzr's wasn't clear
<theCore> bzr's output
<theCore> Using saved location: http://bazaar.launchpad.net/~keybuk/upstart/main/
<theCore> All changes applied successfully.
<theCore> 23 revision(s) pulled.
<theCore> I thought it was rev23
<Keybuk> ah, heh
<Keybuk> nah, it means you got 23 new revisions
<Keybuk> top one should be NEWS: Updated
<theCore> yeah, I figured it out
<theCore> bzr log -r 10..23
<theCore> was kinda weird
<Keybuk> bzr log -r $(($(bzr revno) - 23)..
<Keybuk> err
<Keybuk> bzr log -r $(($(bzr revno) - 23))..
<Keybuk> :p
<theCore> ah, I just found better way
<theCore> bzr log -r -10...
<theCore> er, bzr log -r -10..
<Keybuk> ooh
<Keybuk> that's shiny
<Keybuk> I didn't know about that <g>
<theCore> me, either
<Keybuk> theCore: pushed the "Bump version to 0.3.2" revision
<Keybuk> see how long that takes to show up
<theCore> ah, I know what I am going to do
<theCore> I will translate upstart in French :)
<Keybuk> sweet
<Keybuk> I haven't yet worked Rosetta out
<Keybuk> I'm vaguely nagging for it to just have a bzr branch with the translated po files on it :)
<Keybuk> so I can just bzr merge http://rosetta.launchpad.net/products/upstart
<Keybuk> :p
<theCore> oh
<Keybuk> I click a button, it sends me a tarball
<Keybuk> all seems a bit ... primitive
<theCore> Writing in French with a English keyboard is painful
<theCore> I almost never write in French
<theCore> I only speak it
#upstart 2006-12-14
<Keybuk> interesting
<Keybuk> upstart's tests consistently fail on the buildds
<Keybuk> (null):alloc.c:416: Assertion failed in nih_alloc_size: ptr != NULL
<Keybuk> FAIL: test_file
<Keybuk> passed on powerpc and sparc
<Keybuk> failed on both real architectures, and itanium
<drakeoutlaw> hi all, can we boot to a non gui console with the single command?
<drakeoutlaw> !single
<Keybuk> drakeoutlaw: depends on the distribution; which are you using?
<drakeoutlaw> edgy, but there is no /etc/inittab
<Keybuk> yes, you can still use "single" to get to single-user mode
<drakeoutlaw> ok, but how to change the default run level?
<Keybuk> see /usr/share/doc/upstart/README.Debian.gz
<drakeoutlaw> ok willdo
<Keybuk> hmm
<Keybuk> again I can't help but think that "failed" shouldn't be a separate event, but should be an argument to the "stopped" event
<Keybuk> (or stopping)
<wasabi> Keybuk: I agree with that. It makes the job easier for other people who want to know when the job is "no longer running"
<wasabi> Without having to explicitly say stopped or failed
<wasabi> And most dependencies care about the fact that the server is gone, less about the particulars about why it is gone.
<Amaranth> so can we actually start writing useful jobs or whatever with 0.3? :)
<Keybuk> well, failed was always going to be followed by stopped
<Keybuk> the reason I was thinking of merging them is that there's no way right now to say "until this job succeeds"
<Keybuk> e.g. ntpdate, you only want to run once
<Keybuk> on network-interface-up and from startup until $NTPDATE_DIDNT_FAIL
<Keybuk> Amaranth: that's the intent
<Keybuk> 0.2 was "let's see if the daemon code works, and is sound in principal"
<Amaranth> heh
<Amaranth> i'll have to look into converting willowng to use it
<Amaranth> although it's not particularly complex, just starting and stopping, no fancy stuff
<Keybuk> that's a dbus service?
<AlexExtreme> hmm, Keybuk: when you do that talk at linux.conf.au, will there be any way of seeing a video/audio of the talk? i'd quite like to see it but I can't easily get to Australia for it ;)
<Keybuk> I've no idea
<Keybuk> I suspect, given jdub, that they'll all be live streamed or something
<Keybuk> I'm in the big hall, so it's possible
<AlexExtreme> great
<Keybuk> Amaranth: looking at the willowng package in edgy; it'd be something like
<Keybuk>      start on started dbus
<Keybuk>      stop on stopping dbus
<Keybuk>     exec /usr/sbin/willowng
<Amaranth> yeah, real simple :)
<Keybuk> I'd probably write it as
<Keybuk>     from started dbus until stopping dbus
<Keybuk>     respawn /usr/sbin/willowng
<Keybuk> so it gets respawned as well; and acts statefully
<Amaranth> wow, i love upstart
<Amaranth> the init script is like 20 lines of garbage
<Amaranth> that's 2 lines that tell you exactly what's going on
<AlexExtreme> yeah
<AlexExtreme> it's the simplest i've ever seen
<AlexExtreme> none of the other "next-gen" init systems do that as simply as that
<Amaranth> There is a lot of magic behind the scenes to make things that simple, I'm sure.
<AlexExtreme> see the specifications for upstart on launchpad ;)
<Keybuk> I like reading the really old specs, and being amused by how much has changed in a year
<AlexExtreme> yeah
<Keybuk> the PDF on the upstart website is particularly good <g>
<Keybuk> "The basic design of upstart is that tasks exist in one of three states:"
<Keybuk> we have something like 8 now
<AlexExtreme> :P
<_ion> :-)
<Keybuk> and that goes on about "edge events" and "level events"
<Keybuk> we do still need to rename /etc/event.d
<AlexExtreme> why's that?
<Keybuk> it's not very descriptive of its content
<Keybuk> it contains definitions of services, tasks and states
<Keybuk> not events :)
<AlexExtreme> so, servicetaskstate.d? :)
<AlexExtreme> gotta go
<Keybuk> http://opensolaris.org/os/project/smf-profiles/;jsessionid=A8CF91BE41ED07443BFA5A4F686515D0
<Keybuk> interesting
#upstart 2006-12-15
* ..[topic/#upstart:theCore] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs
<Keybuk> phew
<Keybuk> it looks like the upstart test failures on the buildds is caused by EELMO
<Keybuk> I suspect their kernels have inotify disabled
<maro> EELMO?
<Keybuk> elmo likes to build custom, module-less kernels
<maro> oh, heh :)
<_ion> Why not just run stock kernels on buildds?
<Keybuk> because they scare him
<wasabi> fear is a mind killer, or something
<Keybuk> heh
<wasabi> nice. on site interview next week.
* wasabi cheer.
<Keybuk> wasabi: sweet
<steev64> the Getting Started page link to example jobs is 404
<Keybuk> fixed
<steev64> thanks :)
<steev64> as much as people are going to hate me for it (not necessarily *in here*), I am trying to get upstart working on Gentoo
<Keybuk> seems to be quite popular :)
* Keybuk peers at libdbus
* AlexExtreme prods at libdbus
<AlexExtreme> not one of my favourite libs...
<AlexExtreme> ;)
<Keybuk> I like it about as much as implementing my own IPC
<Keybuk> not very much
<AlexExtreme> heh
<Keybuk> trying to decide whether the init/initctl communication should be done with a peer-to-peer libdbus connection
<Keybuk> and whether that'll make it easier on the code at each end
<AlexExtreme> but still, upstart already has it's own IPC which works for the purpose intended, why change it?
<Keybuk> because it's a pain in the arse
<Keybuk> in fact, upstart has two different IPCs
<AlexExtreme> oh?
<Keybuk> the one it uses between init and initctl
<Keybuk> and the one it uses when it re-execs itself after an upgrade to transfer job/event state
<Keybuk> I'd rather there was just one
<AlexExtreme> ah
<Keybuk> and I'd rather that one was actually easy to deal with
<Keybuk> e.g. right now, to send job information from one process to the oehter
<Keybuk> upstart packs that into an UpstartMsg struct
<Keybuk> which has a UpstartJobStatusMsg struct inside it
<Keybuk> message->job-status.name = ...
<Keybuk> and tags the UpstartMsg struct with the type
<Keybuk> message->type = UPSTART_JOB_STATUS;
<Keybuk> then has to arrange for that to be sent asynchronously to the requesting/subscribed process
<Keybuk> so it has to _COPY_ that structure into a ControlMsg struct for each process that could receive it, a field at a time
<Keybuk> when the socket is writable, it then grabs the info, and packs it into an iovec buffer
<Keybuk> and writes it to the receiving process
<Keybuk> which has to unpack the iovec buffer into an UpstartMsg struct
<AlexExtreme> right, so the point you're trying to make is that is far too complex and also reinvents the wheel (doing something dbus already does) ?
<Keybuk> examine the type to determine what message type it is
<Keybuk> unpack the info from the message->job_status struct back into a Job
<Keybuk> and only then decide whether *it* needs to send a reply
<Keybuk> etc.
<Keybuk> yeah
<Keybuk> it's a pain in the arse :p
<AlexExtreme> sounds like it :)
<Keybuk> I'm not sure that something like libdbus is any better though
<AlexExtreme> hmm
<Keybuk> I suspect the problem is the method of IPC
<Keybuk> e.g. "send me the status of job FOO" => "bulk reply of job foo"
<AlexExtreme> bbl
<eMish> I have several questions about updtart
<eMish> upstart
<eMish> (1) Does it come without automatic convertor of inittab to it's /etc/event.d ?
<eMish> (2) DO I need to convert all of /etc/init.d, /etc.rcN.d to /etc/event.d ?
<eMish> (3) can upstart run alonside with old init ?
<Keybuk> 1 - the ubuntu package has one that handles getty and control-alt-delete changes
<eMish> not kuubuntu, the upstart itself
<Keybuk> 2 - no, there are example jobs on the website that handle running the /etc/rcN.d directories alongside upstart jobs; therefore you can convert them at your leisure, or even not at all
<Keybuk> 3 - what do you mean by "old init" ?
<eMish> ok, actually I'd prefer (3), running it alongside existing init then. Can I ?
<Keybuk> eMish: the tarball itself doesn't contain the perl script, mostly by omission at the moment
<Keybuk> eMish: the existing /sbin/init -- or the existing /etc/init.d stuff?
<eMish> yes
<eMish> doesn't upstart want to overwrite it ?
<Keybuk> yes to which?
<eMish> i compiled upstart and saw that upstart contains init
<eMish> is it supposed to be a replcement for /sbin/init and the inittab ?
<eMish> can I run upstart alongside with existing /sbin/init ?
<Keybuk> it's a replacement for /sbin/init
<eMish> can I run upstart alongside with existing /sbin/init ?
<Keybuk> so no, you cannot run it alongside the existing one
<eMish> fuck
<eMish> anyway
<Keybuk> you can install it to a different location, and alternate between them at boot time
<eMish> heh
<eMish> it's OS
<eMish> anyway
<Keybuk> ie. --prefix=/opt/upstart then boot with init=/opt/upstart/sbin/init
<eMish> no, that's irrelevant
<eMish> i want old init and upstart together
<Keybuk> what's the context for wanting to run it "along side" ?
<eMish> heh
<eMish> wait
<eMish> does upstart has ability to specify, per job, a "health-checking script" that tells if process is ok or needs to be restarted ?
<eMish> and that needs to be run periodically ?
<Keybuk> it's a planned feature, yes
<eMish> good
<Keybuk> (upstart's still in development, so often the answer tends to be "yup, on the list")
<eMish> why exactly it can't be run alongside old init ?
<Keybuk> because it's process #1
<Keybuk> it's designed to be process #1
<eMish> why it can't be process # 123 ?
<Keybuk> because then it wouldn't be the parent of all daemon processes
<Keybuk> so couldn't supervise them
<eMish> i want to invoke upstart-init from old init
<eMish> ah, i see
<Keybuk> by assuming it's process #1, it can take advantage of several tricks
<eMish> why wouldn't it just understand old inittab format then
<Keybuk> it's intended to be a complete replacement
<eMish> to allow for gradual and smooth igration
<eMish> revolution, yes
<Keybuk> nobody in reality modifies /etc/inittab much
<Keybuk> just old hands who know about it
<eMish> i do all the time
<Keybuk> most people believe that init starts at /etc/init.d
<Keybuk> so we decided to begin compatibility there
<eMish> i believe you made couple of mistakes forgetting about "backward compatibility"
<Keybuk> an /etc/inittab parser can easily be written that registers jobs with upstart
<Keybuk> such as?
<eMish> such as not parsing old /etc/inittab format
<eMish> so I could migrate tasks one by one by rewriting lines and sending -HUP 1
<Keybuk> why is that a mistake?
<eMish> why forgetting about backward compat is what ?
<Keybuk> seriously, you'll find that in 99% of Linux installations, /etc/inittab is unmodified from what the distro installed
<eMish> i fall into 1%
<eMish> i always fall into that 1%
<Keybuk> I'm not disputing that
<Keybuk> that 1%, however, is either
<eMish> of course those 99% are happy with old init
<Keybuk> a) set in their ways, so unlikely to switch
<Keybuk> b) technically competent enough to switch by hand
<eMish> look, you're the guy which can help me
<eMish> we have small router appliance, linux0-based of course
<eMish> and we have our own process management 
<eMish> written in C by some bum
<Keybuk> heh
<wasabi> I'm not following why you're using Upstart before you've ported your process.
<eMish> i am fixinf bugs in it and the more i fix it the worse it looks
<eMish> i'm looking for a comlpete repalcement
<Keybuk> pretty much similar to our story; we had a small linux distribution and realised we needed some kind of process management, so we wrote Upstart
<eMish> the big missing part is, we need to specify health-checking cripts for each process
<eMish> actually now that i think about it, i think checking script can restart the process
<eMish> but how would i schedule health-scheking script with upstart ?
<eMish> but i don't understand the installation part. /etc/eventd.d is empty
<Keybuk> in theory?  (not yet implemented)
<eMish> am I supposed to convert inittab manually myself ?
<Keybuk> something like "hourly from started JOB until stopping JOB"
<Keybuk> in the job definition of the checking script
<eMish> i trid initng, doesn't ghave this, too
<eMish> what do you think about initng
<Keybuk> eMish: yes, or use the example jobs tarball which is based on Ubuntu's inittab
<eMish> i don't understand
<Keybuk> init-ng is an excellent implementation of a dependency-based init system
<Keybuk> upstart and init-ng are so different, I don't really see them as competitors
<eMish> not automatically converting your existing setup if the mistake initng have, too
<eMish> different ? both try to replce your /sbin/init
<Keybuk> yes, but both replace it with things that are fundamentally different
<Keybuk> to the original /sbin/init, as well as to each other
<Keybuk> so, first, to answer the converting the existing setup problem ...
<Keybuk> upstart is still in development
<Keybuk> we're releasing early, and often
<Keybuk> and are not far past the "early" stage
<eMish> I see
<Keybuk> the 0.2 series was "get a daemon written that's good enough to do the job of sysvinit"
<Keybuk> the 0.3 series is going to be "have something that's good enough to do a much better job"
<eMish> i didn't realise it's early
<Keybuk> by the time we reach 1.0, I fully suspect we'll have a suite of migration and compatibility tools for people to deploy
<eMish> i want char-based (curses) service controller
<eMish> so i can walk list of services and enable/disable them
<eMish> stop/start 
<eMish> add services, too
<Keybuk> (phone call, brb)
<Keybuk> look in util at initctl :)
<eMish> I made 'make install', am I screwed up now ? I see that /sbin/init is not replaced
<Keybuk> it probably went to /usr/local/sbin ?
<eMish> yea
#upstart 2006-12-16
<_ion> Please correct me if i'm wrong, but isn't the version number change in configure.ac just a sign of the beginning of 0.3.2's development, not the release of 0.3.2?
* ..[topic/#upstart:_ion] : Upstart 0.3.1 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs
#upstart 2006-12-17
* netjoined: irc.freenode.net -> brown.freenode.net
<Keybuk> wasabi: heyhey
<Keybuk> BAD: wrong value for iovec.iov_len, expected 4 got 8
<Keybuk>         at tests/test_wire.c:65 (test_write_int).
* Keybuk loves the new test framework
<AlexExtreme> heh
<AlexExtreme> thank goodness that's over
<AlexExtreme> (been christmas shopping)
<Keybuk> what?
<Keybuk> ahh
<Keybuk> I've yet to do most of mine
<wasabi_> hi Keybuk
<Keybuk> how goes it?
<wasabi_> pretty good
<wasabi_> trying to get dates/contacts working properly 
<maro> Keybuk: is there a reason why initctl writes to stderr?
<maro> (initctl list in particular)
<AlexExtreme> i wouldn't have thought there would be a reason, it's most likely a mistake
<maro> or it's on purpose for a reason I'm not yet familiar with :)
<Keybuk> err, it does?
<Keybuk> oh yeah
<Keybuk> oops
<Keybuk> :p
<user_> keybuk nice blog ;)
<maro> Keybuk: will there be a way to ignore jobs?
<maro> for example, if X is starting to freeze the system and gdm is launched from upstart
<maro> with sysvinit you'd just boot into another runlevel
* ..[topic/#upstart:_ion] : Upstart 0.3.1 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://www.netsplit.com/blog/articles/2006/12/14/upstart-0-3 | irc logs: http://people.ubuntu.com/~fabbione/irclogs
<wasabi_> maro: We've only done some basic discussion about that.
<wasabi_> I'm a bit fond of two ideas... a set of profiles which enable/disable jobs by name, and are chosable at boot time (kernel cmdline), and also some sort of passing flags at boot that jobs can retrieve and disable themselves with.
<wasabi_> Keybuk: Your blog entry does describe "starting" or "stopping".
<wasabi_> s/does/doesn't/
<wasabi_> The events.
<wasabi_> oh wait you did.
<wasabi_> n/m. my eyes are just crossed. =)
<Keybuk> :D
<wasabi_> start on network-interface-up/failed
<wasabi_> & oops
<wasabi_> What's up with the /
<Keybuk> I couldn't think of a better way to denote "failed" events
<wasabi_> hmm.
<wasabi_> I wonder if it's even important to denote them to anybody other than their issuer.
<Keybuk> dunno :p
<wasabi_> Might be better to forget about it until a use case can be created. ;)
#upstart 2007-12-10
<j__> hi
<j__> there is an upstart developper availlable ?
<soren> j__: It's much easier for everyone if you just ask your question.
<j__> I've actualy an instablility of upstart
<j__> I don't have the same comportement at each boot
<soren> comportement?
<j__> comportment/behavior
<soren> ok.
<soren> You realise you need to provide some more information, right? "Something doesn't work" isn't quite enough to fix anything.
<j__> I agree
<j__> I create some script like that
<j__> start on network and dbus_started
<soren> "like that"?
<j__> first the script do not start and sometimes I've an dbus_started evend failed
<j__> I've 3 scripts
<soren> Ah, I've just noticed Keybuk isn't around. It's probably him you want to pester.
<j__> one that emit dbus_started
<j__> when dbus is available
<j__> on other that emit network when the network is configured
<j__> and a deamon script that start when the both are done
<j__> Am I doing something wrong?
<soren> Not sure. You should ask Keybuk.
<soren> Ah, he's off today. He should be around tomorrow, though.
<j__> ok
<j__> soren: did you have mode complex example with and for updstart script?
<j__> re
<j__> soren or other I'm currently builiding the last upstart from bazar
<j__> and I've this error
<j__>  /bin/install -c -m 644 'errors.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/errors.h'
<j__>  /bin/install -c -m 644 'inotify.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/inotify.h'
<j__>  /bin/install -c -m 644 'test.h' '/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/image//usr/include/nih/test.h'
<j__> make[2]: Leaving directory `/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/work/upstart-0.3.9/nih'
<j__> make[1]: Leaving directory `/usr/targets/trunk-WYBOXA-V0200-7109-debug/build/portage/sys-boot/upstart-0.3.9-r1/work/upstart-0.3.9/nih'
<j__> Making install in upstart
<soren> How is that an error?
<j__> /bin/sh: line 17: cd: upstart: No such file or directory
<j__> make: *** [install-recursive] Error 1
<soren> Ah.
<j__> any idea?
<soren> File a bug? 
<soren> ..or wait for Keybuk to show up tomorrow. :)
<ion_> That sounds like a bug in the gentoo packaging.
#upstart 2007-12-11
<j> ion_: about yesterday it's not a gentoo bug
<j> the current trunk does not build 
<j> is Keybuk will come today?
<j> Keybuk: hi
<Keybuk> hey
<j> I'm currently using 0.3.9
<j> and the "and" does not wrok
<j> so I try to compile the last trunk
<j> but it does not build
<j> I've this error : /bin/sh: line 17: cd: upstart: No such file or directory
<j> make: *** [install-recursive] Error 1
<j> after the install of the nih header during the make install
<Keybuk> "and" wasn't supported in 0.3.9
<Keybuk> it only exists in trunk, and there isn't really finished
<j> Keybuk: when it will b finished?
<Keybuk> that's hard to answer
<Keybuk> the "and" support is pretty low on my list at the moment
<j> how can it will become up?
<Keybuk> need to solve the whole events issue, really
<j> ok
<Keybuk> work out what they mean
<Keybuk> how they'll be used
<Keybuk> where they come from
<Keybuk> and how they'll be combined
<Keybuk> that's the major problems with roadmaps
<Keybuk> it prevents you from making minor releases
#upstart 2007-12-14
<ion_> Chuck Norris is the main source of entropy for /dev/random.
<Keybuk> hmm?
#upstart 2008-12-09
<keesj> HI
<keesj> I gave up on 0.5 and even have my doubts about 0.3.9. what a mess
<keesj> what is "wait for daemon" called in 0.3.9
<sadmac2> Keybuk: looks like Alan doesn't want to be our friend :(
<johnflux_> Hey all
#upstart 2008-12-10
<keesj> hi
<kysucix> hi
<kysucix> how can I generate a custom event from a script? (not with emit from command line)
<notting> dumb answer: have your script call initctl emit
<sadmac2> Keybuk: around?
<Keybuk> yup
<sadmac2> Keybuk: So, I've been assessing things, and in order to start writing the state machine, I need 1) to know the rough protocol for talking to pid 1 (mostly the division of responsibilites. specifics can come later) 2) Libnih needs to unblock me
<sadmac2> 1 I think we could hash out fairly quickly
<sadmac2> 2 is kind of bugging me. I don't like that things are hung because of libnih, and I might seriously propose going without it for awhile
<sadmac2> at least on my end
<Keybuk> what's the panic'd rush?
<sadmac2> eager beaver syndrome
<sadmac2> runs in my family
<Keybuk> I'm really not expecting to start serious work on any of this until next year
<sadmac2> I've been thinking of writing a state machine as a separate project in the meantime.
<sadmac2> when you're ready you can pick it up, or we can scrap it and write a new one
<ion_> I should take a good look at this state machine thing of yours.
<ion_> I skimmed through the ruby prototype, but didnât manage to understand it only based on the code.
<sadmac2> the fact that its a very conceptually declarative task being implemented in a high level imperative language makes it a bit hard to follow
<sadmac2> there's some odd hackish bits that are there to keep things sync'd
<ion_> Is there some documentation for this state machine thing?
<sadmac2> ion_: there's that huge mailing list posting...
 * sadmac2 checks to see if there's any RDoc
<sadmac2> there's some minimal rdoc
<sadmac2> the test cases are probably more worth looking at than the state machine itself
<sadmac2> from a "what the hell's going on" perspective
<ion_> Ah, i forgot about the mailing list post. Iâll take a new look at it.
<ion_> sadmac: Btw, i found out about Cucumber recently, you might find it interesting. http://github.com/aslakhellesoy/cucumber/wikis/
<sadmac2> ion_: interesting
<sadmac2> ion_: I think being that high level has its dangers though. When its that close to plain english it becomes unclear where the formal subset ends.
<ion_> sadmac: Real-life examples for the state machine would be helpful for understanding it.
<sadmac2> ion_: my mind always goes blank when I get asked for an example
<sadmac2> :)
<ion_> sadmac: About cucumber, http://goruco2008.confreaks.com/01_helmkamp.html (/me is watching it right now)
<sadmac2> ion_: I'll hit it up when I get home tonight :)
<sadmac2> ion_: ah, so the thing doesn't really "understand" english
<sadmac2> its a simple pattern match
<ion_> Indeed
<sadmac2> hmm, a logo contest
#upstart 2008-12-11
<keesj> I have about the same problem as kysucix. I need to control system scripts
<keesj> and need to do stuff initctl can do
<keesj> the pain is that libnih and the upstart libs are gpl so I can not even write my own initctl using the nih libs
<keesj> in ubuntu 8.10 there is not even a libnih
<Keybuk> why can't you write your own initctl?
<Keybuk> you can link to gpl libraries from gpl applications just fine
<keesj> I am not writing a gpl app
<keesj> making the libs lgpl would really help 
<Keybuk> *shrug*
<Keybuk> then I have no interest in helping you
<Keybuk> if you do not want to contribute your source code
<Keybuk> then don't touch mine
<Keybuk> the libraries are GPL for a reason
<keesj> dont' start the lame gpl story. If I am on this channel its because my company tries to use upstart. 
<keesj> and it 's not because I am writing closed code that I can not help people
<keesj> just like I did no this channel many times
<Keybuk> you can write as much closed code as you like
<Keybuk> you just can't link to my code
<Keybuk> I am happy that inconveniences you
<Keybuk> I spent a lot of time and effort on my code
<keesj> Well you should not.
<Keybuk> and its open for all to use
<Keybuk> it's frankly insulting that you want to benefit from it commerically without opening your code in return
<keesj> I spend a lot of time on upstart and having ideas. if you can't value that.  or don't value other good your are probably thinking to much of open-source as a software only thing
<Keybuk> I'm not talking about having ideas, or helping out here
<Keybuk> that's more than welcome
<keesj> it about people. I am really shocked that you don't value whay I do
<Keybuk> I'm only talking about you asking me to lgpl the libraries
<Keybuk> which is only a software thing
<Keybuk> my code is open
<keesj> I am asking you to understand that upstart like any ohter open-source thing need people can companies behind it. and I represent such a company.
<Keybuk> and free for you to modify, derive and link as you see fit
<Keybuk> *provided* that you open yours in return
<Keybuk> if your company isn't willing to open its code, then I don't see that as backing upstart's code development
<Keybuk> obviously you can help in other ways
<keesj> that why lgpl exist .I did not have much needs to modify upstart. it works quite well out of the box (the 0.3.* series)
<Keybuk> but I'm not interested in a company making commercial derivatives or taking private benefit from my code
<keesj> I can only help and am only interested in upstart because we want to use it. that is WHY is am here. no matter what I do with it. and apparently you have no way of showing that you value that in code :P
<Keybuk> I only value code I have the same rights to as code you clearly value
<Keybuk> (or more rights to :p)
<Keybuk> code that I'm not allowed to see is inherently uninteresting
<Keybuk> code that improves my work, that I'm not allowed to see, is ... well, insert rude words here
<keesj> the result of this disc doesn't really matter (almoost flame stuff).
<Keybuk> I don't see this as a flame
<keesj> I did not modify your code. but I want to listen to upstart events from my closed system and that is apparenly aksing to much
<Keybuk> yes, your closed system benefits from, and is improved by, upstart
<Keybuk> but we, in return, can't benefit from and be improved by your system
<Keybuk> because it's closed
<Keybuk> this is unfair
<keesj> that part is unfair yes. but that is not the whole story
<Keybuk> as far as the code and licence goes, that is the *entire* story
<keesj> you one yout hand will get "upstart is used in blabla". Me who at least tried to help in thinkgs about upstart. me helpin people on irc. and somebody else using your system and giving feedback
<Keybuk> honestly, and I'm sorry if this sounds conceited, but:
<Keybuk> between Ubuntu, Fedora and RHEL; I have probably 20-25 million users of Upstart
<Keybuk> that's such a large level, I could never possibly hope to receive all the feedback
<Keybuk> so additional users are nice, but not something I really seek
<Keybuk> my goal is to have it adopted by the major Linux distributions
<Keybuk> and that's really the end of my goal
<keesj> what I see is 3 user cases , 1 coder and a few developers
<Keybuk> it's nice to hear about people trying to use it for other things (hi, Cisco!) but they're so far off my radar, it's not something I worry about
<keesj> it an enrightment
<Keybuk> yeah
<Keybuk> that's 2 use cases too many ;)
<keesj> Well I am in the embedded PND world
<Keybuk> Post Natal Depression?
<Keybuk> (that's the only expansion of that tla I know)
<keesj> Portable navigation devices
<Keybuk> GPS units?
<keesj> I wonder what upstart version maemo will be using...
<keesj> yes GPS
<Keybuk> keesj: I don't know, they've never even been in touch to say that they would be using it
<Keybuk> I found out because someone showed me a slide from a presentation
<Keybuk> I guess bugs or patches will land in due course
<Keybuk> (or it works perfectly, which I'd be surprised about, because I'm pretty sure our arm build threw a nut)
<keesj> arm builds work just fine
<keesj> I did not check on ubuntu mobile lately
<Keybuk> BAD: wrong content in file 0x2a0401e0 (output), expected 'foo [#1000] (start) waiting
<Keybuk> ' got 'test: foo [#1000] main process killed by SEGV signal
<Keybuk> '
<Keybuk> 	at tests/test_initctl.c:874 (test_start_action).
<Keybuk> /bin/sh: line 4:  9780 Aborted                 ${dir}$tst
<Keybuk> FAIL: test_initctl
<Keybuk> we're still waiting for porting boxes, so haven't had a chance to look at it yet
<Keybuk> \o/ for test suites
<Keybuk> of course, it should be noted that you communicate with Upstart 0.5.0 onwards through D-Bus
<Keybuk> so you don't need the library to link to talk to it
<Keybuk> the D-Bus library licence is more liberal than the GPL
<keesj> http://www.paste-it.net/public/u31bbbc/
<keesj> this is what the output of initctl list looks like under qemu-arm
<keesj> (0.5) that is , I was under the impression that this was just a bug
<keesj> but apparently you are saying that initctl list (or status) looks nicer under x86?
<keesj> or is tat 0.3.9
<Keybuk> the _5f bit?
<Keybuk> that's a bug
<keesj> a known one?
<Keybuk> yeah
<Keybuk> casey just outputs bits of dbus object paths there
<Keybuk> and doesn't convert them back into names
<Keybuk> (which, in all fairness, is because I didn't add the properties to the job objects)
<Keybuk> right bed
<keesj> :P
<fbond> Hi.  When entering runlevel 2, an event is emitted.  Is an event emitted after the init scripts for that runlevel have finished executing?
<fbond> I guess I can use "start on started rc2"?
<notting> and then stopped
<fbond> notting: Right, "stop on stopped rc2".
<fbond> Or maybe "stop on stopping rc2" would be better...
<fbond> Is there an upstart manual?
#upstart 2008-12-12
<fbond> "start on started rc2" doesn't really do what I want.
<fbond> I think what I want to do would require the rc2 job to emit an event like "rc2-finished".  This is different from "stopped rc2" because that happens regardless of whether or not rc2 was killed due to switching runlevels or rc2 finished normally (and we're in runlevel 2).
<fbond> Am I thinking about this wrong?
<fbond> Can I do conditional "start on " directives?
<fbond> Like "start on runlevel 2 and stopped rc2"?
<fbond> That doesn't seem like it would work because it's not an event that happens at a specific time...
<sadmac2> fbond: I believe the stopped event has an environment variable (I think its RESULT) that says whether it was a success or a failure
<sadmac2> fbond: so start on stopped rc2 RESULT=ok
<fbond> sadmac2: My only concern is a race condition.
<sadmac2> fbond: what race condition?
<fbond> If we go into runlevel 2 and then switch to runlevel 3 before rc2 has totally finished, is it not at all possible that some odd timing (rc2 finishes just after we enter runlevel 3) will lead to me receiving the events out of order?
<fbond> Let me be more explicit:
<fbond> I want a job with:
<fbond> start on stopped rc2 RESULT=ok
<fbond> stop on runlevel [!2]
<fbond> This will make sure the job doesn't get started until after the rc2 init scripts have finished.
<sadmac2> those two lines should do it
<fbond> But what if rc2 init scripts finish normally just after runlevel 3 is entered but before upstart kills rc2?
<fbond> Is that not possible?
<fbond> If that happened, my job would be running in runlevel 3.
<fbond> (Sorry if I'm making this overly complicated.  I'm just wondering what does upstart do to prevent this?)
<sadmac2> I don't know that that can happen
<fbond> I think it can...
<sadmac2> but I'm not certain now...
<fbond> Because runlevel 3 is an event, so it happens before upstart kills rc2.
<fbond> That leaves a brief window for things to go wrong (unless I'm missing something).
<sadmac2> fbond: upstart is single-threaded internally, so I think that the normal exit of rc2 and the runlevel event would be serialized
<sadmac2> fbond: if the runlevel event happened first, upstart would register rc2 as "killed" even though it had terminated successfully
<sadmac2> I think
<fbond> sadmac2: The runlevel event *must* happen first, right?
<fbond> Because rc2 has "stop on runlevel [!2]"
<fbond> sadmac2: Okay, is upstart smart enough to say "rc2 failed because I would have killed it"?
<fbond> Time to look at the source I guess...
<sadmac2> fbond: its more dumb enough I think :)
<fbond> sadmac2: ;)
<fbond> Any idea where in the source I ought to look?
<fbond> This is hard to grep for :)
<sadmac2> fbond: init/job.c will be helpful
<fbond> sadmac2: thanks
<fbond> sadmac2: Doesn't look good.
<fbond> job_child_reaper appears to set the job status as failed based on process exit status.
<fbond> That doesn't take into account what upstart may have wanted to do to the process. ;)
<sadmac2> fbond: but that's fine
<fbond> It is?
<sadmac2> fbond: because the runlevel event hasn't been processed at all yet
<sadmac2> fbond: so runlevel 3 hasn't been received by anything
<fbond> I don't see how.
<sadmac2> fbond: upstart can only be doing one thing at a time
<fbond> You are saying the event has been emitted but not finished processing?
<sadmac2> fbond: not even started processing.
<fbond> That can't be true.
<fbond> Because stopping rc2 happens in response to the runlevel 3 event.
<fbond> Right?
<sadmac2> fbond: that's a different case though :)
<fbond> I'm not sure I follow you.  I've been talking about the same case the whole time. ;)
<fbond> sadmac2: Do we agree that there is a race in that particular case?
<sadmac2> fbond: for your race condition, either the child is reaped before the runlevel event is processed (in which case it appears rc2 finished before runlevel was ever emitted) OR the runlevel event is processed before the child is reaped (in which case upstart tries to kill it anyway and just registers a failure)
<fbond> sadmac2: There is a third case.
<fbond> The process dies just before upstart tries to kill it.
<fbond> The failure isn't registered because the process exited normally.
<sadmac2> fbond: upstart should call it a failure if it explicitly killed something
<sadmac2> fbond: and I think it won't even wait for the reap result.
<fbond> sadmac2: That's not what the code I'm looking at says (unless I'm missing something).
<sadmac2> fbond: I have to be somewhere. I'll be back a bit later
<fbond> If you reviewed the code and told me I was wrong I would be exceedingly pleased.
<fbond> sadmac2: Okay, no worries.
<sadmac2> fbond: ah, looks like I have more time than I thought
<fbond> sadmac2: Good for you. ;)
<fbond> sadmac2: BTW, I'm looking at upstart source from Hardy (0.3.9-2).
<sadmac2> fbond: ohh
<sadmac2> fbond: I was looking at 0.5.0
<sadmac2> hold on...
<sadmac2> fbond: ok, the RESULT variable is new in 0.5.0
<sadmac2> so that won't work :)
<fbond> sadmac2: Ah.  So I should just write an init script, I guess.
<sadmac2> fbond: that's an option
<sadmac2> probably the best option
<fbond> sadmac2: Okay, KISS, I guess.
<sadmac2> heh
<fbond> sadmac2: Too bad, though.
<fbond> I just want upstart to take over already.
<fbond> Can't use it to replace an init script until all of the init scripts are gone.
<fbond> That's a bummer.
<fbond> sadmac2: I think that still leaves an obvious use case for upstart that is not well supported ... ?
<fbond> sadmac2: But I won't be needing it for my current project.
<fbond> sadmac2: Thanks for your help!
<sadmac2> fbond: np
<keesj> fbond: itsn't that a contraditon ?
<keesj> fbond: I was reading the backlog. I see you found something
#upstart 2008-12-13
<fbond> keesj: Sorry, which contradiction?
<keesj> start on stopped rc2 RESULT=ok
<keesj>  stop on runlevel [!2]
<keesj> but I have simliar thing/problems. 
<keesj> I do emit sometimes from within the "script" method of command. but to prevent deadlocks I need to make ohter emits having a "emit --no-wait blabla"
<fbond> keesj: Oh, that's not a contradiction... (rc2 runs at the beginning of runlevel 2 but the ends and runlevel 2 continues)
#upstart 2009-12-07
<johan> heya
<johan> Keybuk: are you around?
<johan> I have a two-lines patch which skips fsck on remote mounts, it's necessary for me to be able to bootup on an nfsroot using upstart 1.0 in karmic 
<johan> The patch is here, http://pastebin.com/f4a1801a6 I'm wondering if it's the right approach
<Keybuk> why not just put "0" in the check part of your fstab?
<johan> I have that already
<johan>  /dev/nfs	/	nfs	defaults,rw,nolock,tcp 0 0
<johan> and for non-root mounts: anthem:/home	            /home	    nfs defaults,nfsvers=3,tcp,async,noatime,rw,rsize=32768,wsize=32768 0 0
<Keybuk> they shouldn't be being checked then?
<johan> right, but mountall hangs if I don't skip it
<johan> it tries to remount the devices afaict, and it's not able since portmap isn't started yet
<Keybuk> I wonder if it's the /dev/nfs thing confusing it
<Keybuk> it probably never gets told that device name is ready
<johan> I tried /dev/root as well
<johan> right, I have neither /dev/root nor /dev/nfs on my udev
<sassyn> hi
<sassyn> can someone please help
<sassyn> i wrote a rule under ubuntu 9.10
<sassyn> in the init dir
<sassyn> it basicly start a X session
<sassyn> not GDM!
<sassyn> now it is working
<sassyn> but sometime after restart the X doesn't run
<sassyn> doing restart again and X is up
<sassyn> how Can i debug this?>
<sadmac> sassyn: sounds like an X issue. /var/log/messages should help
<sassyn> sadmac - says nothing
<sassyn> it is so strage
<sassyn> I reboot working
<sassyn> restart not working
<sassyn> reboot again working
<sassyn> reboot again not working
<sassyn> reboot again working
<sadmac> you'll need logs from one of the times it doesn't work
<sassyn> do u want me to send u the X init script?
<sassyn> i'm getting crazy
<sassyn> all the day i'm trying to debug this
<ion> Itâs not as if computers can be expected to be deterministic.
<sadmac> sassyn: you can pastebin it if you like
<sassyn> http://pastebin.com/dfacd31
<sassyn> sadmac - 10x
<sadmac> sassyn: looks ok
<sassyn> SO WHAT CAN BE THE PROBLEM? i CONFIGURE THE XORG.CONF MYSELF
<sassyn> IT IS WORKING
<sassyn> IT IS NOT A PROBLEM WITH THE XCONF
<sadmac> please don't capslock
<sassyn> sorry
<sadmac> try init=/sbin/init --verbose on the kernel command line
<sassyn> OK
<sassyn> what should i look for?
<sassyn> this is a good thing
<sassyn> since i didn't know how to debug the init
<Keybuk> compare the output with it working vs. it not working
<sadmac> ^^what he said
<sassyn> 10x :-)
<sassyn> really !
<sadmac> np
 * sadmac to lunch
<sassyn> doing reboot now
#upstart 2009-12-08
<mistergibson> is this the channel for ubuntu networking stuff?
<xopah> Hello could someone help me in a matter where I have hard to connect to a multiple SSID WLAN network?
<Keybuk> xopah: that has nothing to do with Upstart, sorry
<ion> Two persons from totally different parts thought this channel has something to do with networkingithin a couple of minutes? Interesting occurrence.
<ion> networking within
<xopah> keybuk: could you please point me in the right direction?
<xopah> Wher shuld I turn?
<sadmac> xopah: #ubuntu would be a good next stop
<xopah> ion: we were recommended to go here from #ubuntu ...
<sadmac> Keybuk: ^^WTF?!?
<xopah> sadmac: thanks. I'll try there again.
<sadmac> xopah: np
<sadmac> hmm. Is #ubuntu having troll problems?
 * sadmac imagine's Scott's "you're making absolutely no sense" face
<Younder> I am having problems with programs due to a pygtk not beeing seen
<Younder> there are multiple python versions and it worked under gentoo
<sadmac> Younder: how does this relate to upstart?
 * sadmac begins to get a sinking feeling
<Younder> sorry I'll go back to the python group.. take my chances
 * Keybuk wonders whether there's a channel mode flag
<Keybuk> to refuse entry to people also in #ubuntu
<sadmac> Keybuk: wouldn't that block, say, you for example?
<Keybuk> no
<Keybuk> I'm not in #ubuntu
<sadmac> Keybuk: heh. maybe I don't understand #ubuntu
 * sadmac is in #fedora
<Keybuk> Ubuntu is where users go to ask questions
<Keybuk> err #ubuntu
<sadmac> Keybuk: yeah. so is #fedora. I like to meet the people
<Keybuk> we have more users than you
<Keybuk> a LOT more users
<Keybuk> they whine more too
<sadmac> Keybuk: yeah, I don't know that I'd like to meet /your/ users. Ours troll more than yours I'd imagine though
<Keybuk> at least yours might know something of what they're talking about :p
<sadmac> Keybuk: actually I think 3/4 of the people giving help at any time in #fedora just have irssi set up to periodically say "www.justfuckinggoogleit.com"
<ion> sadmac: Just for fun, join #ubuntu for a minute. Itâll be an... interesting experience. :-P
<ion> âI visited #ubuntu shortly and survivedâ
<sadmac> Keybuk: again though, if you do have so many more users, wouldn't you also be blocking half the relevant portion of the internet?
 * raphael__ wonders how #ubuntu, #fedora and #debian compare
<sadmac> ion: My God, its full of stars!
<ion> Itâs full of trolls and the blind trying to lead the blind! rather.
<sadmac> #debian is nearly as big and not 1/10 as noisy
<notting> ion: that doesn't help me delineate between the three
<sadmac> ion: they seem to be under the impression that they're linux users of some kind
<sadmac> from what I've heard, #debian has all /their/ advice macro'd to "go install Ubuntu"
<raphael__> sadmac: don't think so, it's usually /msg dpkg foo
<sadmac> raphael__: the users know what dpkg is? sounds like a nice place.
<Keybuk> sadmac: dpkg is a bot on #debian
 * raphael__ wonders how long Keybuk is going to wait before setting mode +m to stop this offtopic conversation :)
<sadmac> Keybuk: oic
<Keybuk> raphael__: this channel rarely gets on-topic :p
<raphael__> Keybuk: but from what I've seen off-topic conversations don't last this long ;)
<sadmac> Keybuk: fine. on topic: I'm finally edging near a workable nih_parse, which is, of course, making me want to replace nih_error while I'm at it :)
<Younder> Yes, it would be terrible if that actual users of upstart got a say :)
<sadmac> Younder: what are you talking about?
<Keybuk> sadmac: what were you going to change?
<Younder> Well at present the boot process, to me at any rate, is very confused. I can't see where sysv ends and upstart begins.
<sadmac> Keybuk: probably not change so much as a new mechanism, along the lines of the lisp condition/restart thing that I've poked at a few times
<Keybuk> Younder: depends which distro you look at
<Younder> ubuntu 9.10
<sadmac> Keybuk: it would also make a nice replacement for nih_log while we're at it (probably with no API change there)
<Keybuk> most actual Linux distributions tend to have the Upstart /sbin/init daemon run the SysV-style rc scripts (/etc/init.d)
<Keybuk> some distributions (like Ubuntu) do far more in a Upstart native way than others (like Fedora)
<Keybuk> embedded Linux platforms (Chrome OS, Palm Web OS, Maemo, etc.) often use Upstart entirely natively
<Keybuk> Younder: read you read "man runlevel" ?
<Keybuk> sadmac: I know I'm going to regret this, but ... explain? :p
<sadmac> notting: since I'm thinking of it, when do you want 0.6 tagged into rawhide? Will you just do it yourself when initscripts is ready?
<Keybuk> Younder: that should be "man 7 runlevel"
<sadmac> Keybuk: basically there is a function/macro called nih_sig()
<Younder> Keybuk, sure, but gtk is not on any runlevel. Tomcat and apache, however, are.
<Keybuk> Younder: that's because GTK+ has nothing to do with Upstart
<Keybuk> and Upstart has nothing to do with GTK+ either
<Keybuk> my toaster is also not on any runlevel
<sadmac> Keybuk: if (some_error) nih_sig (TYPE_OF_ERROR, &some_info, &some_more_info);
<notting> sadmac: hrm. i haven't looked at the other apps. so i'll probably work on it tomorrow or thursday
<Keybuk> yet I can still make toasted goodness
<Keybuk> sadmac: that's basically how nih_error behaves, no?
<Younder> and ubuntu has nothing to with upstart either..?
<sadmac> Keybuk: well, what nih_sig does is interesting
<Younder> They just created it
<Keybuk> Younder: Ubuntu uses Upstart, yes
<michas> hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible?
<ion> Younder is clearly a troll. Letâs not feed it anymore. :-P
<Younder> I guess what I wnat to know is: is there a reference manual for upstart?
<sadmac> Keybuk: nih_sig runs a handler for the error, which is a function pointer registered beforehand
<Keybuk> Younder: plenty, start at "man upstart" on your system?
<sadmac> Keybuk: that function runs right away, and either 1) corrects the error (notice the args passed by ref) 2) longjmps, or 3) aborts
<Keybuk> ah
<Keybuk> more like dpkg-style
<Younder> Keybuk, info?
<Keybuk> you have ohshit()
<raphael__> btw, what's all the nih_foo? I saw it on ureadahead and seemed like it is being used in other places, but it's sort of strange that it doesn't seem to be a shlib
<sadmac> Keybuk: never seen dpkg code
<Keybuk> ohshit calls any registered error handlers and longjmps back up
<Keybuk> raphael__: it is in lucid
<Younder> never mind
<sadmac> Keybuk: the nih_log thing comes in under the "corrects the error" option. nih_log just calls nih_sig (LOG_EVENT_$LEVEL, log_text)
<Keybuk> oh, I see where you're going with that
<sadmac> Keybuk: the default handler does just what nih_log does now, but because there's a handler stack, the log line is now also a sort of tracepoint when you're debugging
<Keybuk> it'd be nice if you could thwart the error ;)
<sadmac> Keybuk: yeah, that too
<Keybuk> e.g. if you raise ENOFILE, an error handler could increase the rlimit, then make you try again
<sadmac> Keybuk: precisely the idea
<Keybuk> but then that requires while loops and stuff ;)
<Keybuk> while (some_syscall (...) < 0)
<ion> Yeah, the condition/restart thing is powerful.
<Keybuk>   nih_sig (...)
<Keybuk> ie. assume that nih_sig solves the problem or longjmps you out
<Keybuk> this is basically how dpkg works
<sadmac> Keybuk: I'm pulling apart libunwind now to see if it has anything to make some of the uglies around longjmp
<ion> More powerful than plain exceptions.
<Keybuk> I spent a long time maintaining dpkg
<Keybuk> nih_error was originally written for dpkg2 ;)
<Keybuk> it doesn't behave the same way for a reason
<sadmac> ion: and, ironically, easier to do in C
<Keybuk> a *lot* of problems with dpkg were caused by errant error handlers
<sadmac> Keybuk: I think it can be made cleaner than it has been.
<sadmac> I'll play with it if I get to it. right now I want to get the parser standing up so I can finish the early triggers stuff and push some of it.
<michas> hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible? (Any hint?)
<sadmac> michas: add a line to the jobs that says "console output"
<michas> sadmac, well, it is an old init.d script. IIRC "console output" works only in the real upstart scripts.
<michas> the first "log_action_begin_msg" prints, but any further echo or log doesn't print anymore. I assume it ist upstart filtering the output or something...
<sadmac> michas: that's going to depend on how upstart is being used to run sysv scripts in ubuntu. you'll have to ask in an ubuntu related channel
<ion> michas: If the script sources /lib/lsb/init-functions, try log_action_msg "foo" or something like that.
<Keybuk> still won't work ;)
<Keybuk> michas: write to a different file, e.g.  echo blah blah >> /dev/my.log
<michas> ion, it does use init-function. the first log message works. the second does not. - that's why I suspect upstart.
<Keybuk> nothing to do with upstart per se
<Keybuk> Ubuntu has a "no messages on console during boot" policy
<ion> michas: Please ignore what i said and do what Keybuk said. :-)
<Keybuk> they get hidden with extreme prejudice
<michas> Keybuk, ok, that will surely do. but I'm still wordering wtf is goin on there. ;)
<Keybuk> michas: there are ways to make them appear
<Keybuk> you can add "console output" to /etc/init/rc.conf and /etc/init/rc-sysinit.conf
<Keybuk> and something like console=tty1 to your kernel command-lien
<Keybuk> making sure not to run usplash
<Keybuk> that brings most of them back
<michas> ah, thanks, that looks good. I'll try that.
<Keybuk> but if it doesn't work, try #ubuntu ;)
<ion> :-D
<michas> allright, I'll do. thanks.
<michas> one last real upstart question: ist there a way to do something like "start on *" f.e. to monitor all events?
<Keybuk> no
<ion> Why would you want that?
<Keybuk> such a thing would match itself, for a start
<Keybuk> including its own stopped event ;)
<Keybuk> if you instanced it, you'd end up with a fork bomb
<michas> I just started to read about all the upstart stuff. And then I wondered what events will happen at a startup on my system.
<sadmac> there used to be a way to dump them as they happened, but we removed it.
<sadmac> kind of a dangerous thing. People do horrible things when you give them access to that sort of thing from shell scripts.
<michas> :) ok, guess you are right. :)
<Keybuk> you can still see them with --verbose
<Keybuk> there's thousands in the startup of a typical ubuntu system
<michas> where do I have to put that --verbose?
<ion> keybuk: --verbose or --debug?
<Keybuk> michas: kernel command-line
<Keybuk> ion: I tend to recommend --verbose these days
<ion> Alright
<Keybuk> --debug adds things you generally don't want to see
<sadmac> michas: you could also systemtap them out if you have a recent enough version and a little elbow grease to apply
 * sadmac makes a note to add stap tracepoints to upstart for doing that sort of thing
<michas> are those options documented anywhere?
<Keybuk> michas: no
<michas> ok :)
<Keybuk> (unless you count "init --help" :p)
<michas> oops. too easy.
<michas> ok, thanks a lot. (That current upstart/rc mix in ubuntu is quite confusing, once things don't work as expected... Hope, they switch to upstart completely soon.)
#upstart 2009-12-09
<oh_noes> Is it possible to replace getty in tty2, with a bash script that reconfigures network information?
<oh_noes> the bash script I already have (accepts input, writes interfaces file, restartes networking) but I'm not sure the correct to call the script in replacement of tty2.
<oh_noes> I want to do it so the script can be run without the user logged in (getty > /my/script) not (getty > /bin/login)
#upstart 2009-12-10
<mbiebl> Keybuk: hi, remember my problem I had with bridge devices on karmic?
<Keybuk> yes
<Keybuk> remember that I said they don't work? :p
<mbiebl> I thought I turn the libvirt-bin sysv init script into an upstart job
<mbiebl> and use start on (net-device-up IFACE=br0 and net-device-up IFACE=br1 and filesystem)
<mbiebl> but that didn't work as expected
<Keybuk> you'd still have the fundamental problem that br0 and br1 won't come up
<mbiebl> /etc/init/networking.conf only seemed to bring up br0
<mbiebl> although I had both br0 and br1 configured as auto in /e/n/i
<Keybuk> you were lucky it even did that
<mbiebl> what happens is, that "initctl emit" in /etc/network/if-up.d/upstart is blocking
<mbiebl> so ifup -a hangs at that point
<Keybuk> you know how mountall carefully waits for devices, and has code to know that it needs two or more devices, and then only fscks and mounts devices when they are ready?
<Keybuk> we need an equivalent for network devices
<Keybuk> which we don't have
<mbiebl> I used -n in the if-up.d hook and now it works fine for me
<Keybuk> yes, the -n will break other things
<Keybuk> (most particularly, the UEC images iirc)
<Keybuk> the right fix is to get rid of "ifup -a" as a "bring up anything we forgot" tool
<mbiebl> yeah
<mbiebl> the -n hack is just a workaround for my particular setup
#upstart 2009-12-13
<Keybuk> ion: I have merged your branch
#upstart 2010-12-13
<davidstrauss> Am I correct to interpret the docs as saying the minimum for an upstart script is simply an "exec" line?
<ion> Thatâs optional, too.
<ion> The minimum job definition is an empty file.
<ion> There are a number of important use cases where a job doesnât have a main process.
<davidstrauss> ion, dependency routing?
<ion> For instance, something that changes the system state in some way in the pre-start script and changes it back in the post-stop script, such as /etc/init/apport.conf
<davidstrauss> ion, One more question. What does this mean by "optional arguments to pass to it"? "exec gives the path to a binary on the filesystem and optional arguments to pass to it"
<ion> % echo foo
<ion> foo
<davidstrauss> ion, Should that instead say "and, optionally, arguments to pass to it"
<ion> âfooâ here is an argument. From Upstartâs point of view, all program arguments are optional.
<davidstrauss> ion, Sure. I'm just trying to figure out if the doc is trying to say that (1) upstart manages optional arguments to an executable in some configurable way or (2) that upstart allows you to pass in arguments on the exec line
<ion> 2
<davidstrauss> ion, OK. Where can I file a request to revise the docs?
<ion> As a bug report on Launchpad, or as a merge request on Launchpad.
<davidstrauss> ion, the getting started guide doesn't appear in the source branch; am i missing something?
<ion> Ah, i was thinking you were reading init(5) or something.
<davidstrauss> ion, I'm reading this: http://upstart.ubuntu.com/getting-started.html
<ion> I guess one could still report a bug against Upstart, since the web page is part of the project, kind of. Or bug Keybuk on IRC. :-)
<davidstrauss> ion, https://bugs.launchpad.net/upstart/+bug/689939
#upstart 2010-12-14
* Keybuk changed the topic of #upstart to: Upstart 0.6.7 "Return of the Mole" | http://upstart.ubuntu.com/ | UDS Videos | Upstart Q&A http://blip.tv/file/3606758 | Desktop & Upstart http://blip.tv/file/3621723 | Plenary Talk http://blip.tv/file/3622104 (~15 min in)
* Keybuk changed the topic of #upstart to: Upstart 0.6.7 "Return of the Mole"
<davidstrauss> If a process can optionally daemonize itself, is it better to tell upstart that it's daemonizing or disable self-daemonization?
#upstart 2010-12-16
<ristok> Hello.
<ristok> Studying ubuntu boot -> upstart.
<ristok> Just studying how it all works from scratch..  And..
<ristok> I get...  Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused..  I am clearly missing something, but what ?
<JanC> ristok: when do you see that?
<ristok> Well, I have a very minimal system.
<ristok> Which I boot up.
<ristok> And then generally everything fails to that.  Which is related to upstart.
<ristok> e.g. init.d scripts
<ristok> "start app" -> Maybe even better example.
<JanC> ristok: are you using Ubuntu or trying upstart on another OS?
<ristok> Well, studying how it all goes together -> I did just add files while going forward.
<ristok> Mainly putting together debian packages.
<ristok> Then I wanted to try upstart as well.
<ristok> And ended up to this.
<ristok> googling did not give perfect results either.
<JanC> do you have any upstart jobs yet?
<ristok> Yes.
<ristok> But probably not running yet ;)
<ristok> So if I try to start something, it always says this.
<ristok> So probably I have to start something, or create something to make it click.
<ristok> I was first thinking it is some dbus symbol or something.  But it seems to also need upstart to run.
<JanC> upstart uses the dbus protocol
<JanC> and of course upstart needs to be run as the init daemon
<ristok> But I cannot start dbus because of this.
<ristok> Well, I am actually trying to debug why the upstart hangs for me.
<JanC> upstart has a --verbose option
<ristok> I am using.
<ristok> Wait..  I will boot..
<ristok> It just hangs.
<ristok> Pretty early.
<ristok> I think it is not able to run any jobs yet, at that phase.
<JanC> I wonder if you start enough jobs to have a working system?
<ristok> But sure, I am studying how it all should work..  So I probably make mistakes here and there.  But I sure would like to know how it all works.
<JanC> ristok: did you look at the upstart jobs in an Ubuntu system to compare?  (or other OS that comes with upstart by default)
<ristok> I have ubuntu installed, so I just checked from there what it will probably need.
<JanC> for example, are you starting TTYs?
<ristok> So I am using ubuntu packages as well.
<ristok> I did create those manually.  Then I was thinking that maybe those ttyX.conf files do the same ?
<ristok> Actually now it fails to mount something, which I have not defined..  And then asks root passwd.  So maybe I actually fixed something.
<ristok> But I have not set any root passwd.
<ristok> Is there any good documentation from this ?
<JanC> ristok: outside of the man pages?
<ristok> Which is the best soruce for information at the moment ?
<Keybuk> ristok: if you see that message, you are not running Upstart
<Keybuk> that is the error from initctl when it's run on a system where /sbin/init is *not* Upstart
<ristok> Indeed, it is not possible to "debug" the system.
<ristok> I just noticed it.
<ristok> I was also missing /etc/default/rcS.
<ristok> Now all is working, a bit further.
<ristok> Yep, I do not know at all how to put it together.  I think that is the part I have to go through to learn it.
<Keybuk> sure it's possible to debug
<Keybuk> I debug all the time ;)
<Keybuk> I also tend to bug
<ristok> But I mean, it is now frozen to one task, does not continue.  So I am missing something for sure.
<ristok> And rather hard to figure it out from here, that what I am actually missing.
<Keybuk> boot with --verbose
<ristok> Yes, I get bunch of stuff to my screen.
<ristok> I have the verbose.
<ristok> But I think I am missing a job.
<Keybuk> depends what you want your system to do, really ;
<Keybuk> :p
<ristok> I want it to open busybox ash actually.  So probably I need something to start it...  Right ?
<Keybuk> right
<Keybuk> start on startup
<Keybuk> console owner
<Keybuk> exec busybox sh
<Keybuk> that's probably the most minimal unix config ever of course
<Keybuk> if that's all you have in /etc/init :p
<Keybuk> for a start, the filesystems will be readonly, etc.
<ristok> Well, there is already some stuff under /etc/init.  Some defaults.
<Keybuk> depends what you start with
<Keybuk> upstart itself ships with a few example ones
<Keybuk> but they probably don't boot out of the box without help
<ristok> Ok.
<ristok> Help ?
<ristok> Paths, etc. ?
<Keybuk> yeah you need all the pinnings of a distro really
<Keybuk> no, code, scripts, executables, things
<ristok> That is for later..  Now I am happy if the base is ok ;)
<Keybuk> typical bootish things:
<Keybuk> - check the filesystems
<Keybuk>  - mount the filesystems
<Keybuk>  - load device drivers
<Keybuk>  - create device nodes in /dev
<Keybuk>  - start services
<Keybuk>  - start login services
<Keybuk> upstart doesn't come with jobs to do any of that
<Keybuk> because that stuff is fundamentally different on every distro
<ristok> I understand..  I am actually a bit lazy hacker, just installing packages from ubuntu.  And at least with those there are .conf files.
<Keybuk> *nods*
<Keybuk> ubuntu is a good place to star
<Keybuk> t
<Keybuk> the key package is montall
<Keybuk> mountall
<Keybuk> typing ... hard
<ristok> I have that one.
<Keybuk> you'll need udev as well
<ristok> I have that one as well.
<Keybuk> then you're pretty good to go
<ristok> I ahve also dbus.
<ristok> initscripts
<ristok> etc.
<Keybuk> *nods*
<ristok> Ok, I did add the .conf file with the stuff you mentioned before..  And it just hangs.  I think it is not running the .conf.
<Keybuk> you may be missing other packages
<Keybuk> if you don't have ubuntu-minimal installed, install that
<Keybuk> (or each of the packages listed until you find the one that makes thing work)
<ristok> I have ubuntu minimal as well.
<Keybuk> are you using the ubuntu upstart deb or the upstream tgz?
<ristok> deb.
<ristok> But my miniubuntu does not have upstart.
<Keybuk> huh?
<ristok> Maybe I have then some old version.  But I downloaded less than month ago from miniubuntu page, the last stable.
<Keybuk> I don't know what miniubuntu is
<ristok> Aah.. ok.
<ristok> There is a minimal cd for installation.
<Keybuk> if you want to learn how Upstart works, you're MUCH better off starting with a working system
<ristok> I have a working system as well.
<ristok> But have to admit that it is kinda blindfolded without console.  Just trying to figure out what is missing.  No error messages nothing.
<Keybuk> why would you have an error message?
<Keybuk> if you haven't told upstart to create a console, it wouldn't know to give an error
<ristok> I did add the script you told me.  I understood that was the simplest way to start it ?
<Keybuk> there are *plenty* of Linux systems without consoles
<Keybuk> and did that job run?
<ristok> Probably not.
<ristok> Or else I would have a console, right ?
<Keybuk> that's not a very helpful answer
<ristok> Well, I do not know if that was run or not.
<ristok> I do not have any logs to check.
<Keybuk> ok, that's the first thing to debug then
<Keybuk> boot with verbose and a scroll lock
<Keybuk> page through the output
<ristok> The log ends to tty device added
<ristok> As far as the history goes.
<ristok> Those seem to go ok.
<Keybuk> then upstart is clearly running jobs and processing events
<ristok> Finished block-device-changed event was the last one.  And I think it also worked just fine.
<ristok> Yes, upstart is working.
<Keybuk> http://upstart.ubuntu.com/wiki/Debugging
<ristok> But there is no information why the script to start console did not run.
<Keybuk> there is. it's probably just scrolled off the top of your screen
<ristok> Highly possible.
#upstart 2010-12-17
<curtlee> If I split my script into common and pre-start scripts, I only get "start: Unknown job: fastcgi-php" when I try to start it.
<curtlee> http://paste.ubuntu.com/545073/
#upstart 2011-12-13
<db-> I'd like to add a dependency to libvirt-bin.conf to wait either for open-iscsi to finish or wait for kernel event that device /dev/sdd is up. Some hints for?
<db-> thanks
<db-> /dev/sdd is created by open-scsi
* jodh changed the topic of #upstart to: Upstart 1.4 | http://upstart.at/ | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
#upstart 2011-12-14
<joern> i may be stupid or blind, but somehow i cannot find documentation about when exactly "emits" is processed
<joern> is it before the exec, directly after the exec, a second later,...?
<broder> "emits" is just metadata - it doesn't cause an event to get emitted
<broder> (it's intended to annotate, e.g., "the executable i'm about to call is going to emit these events at some point")
<broder> it's used by things like initctl show-config and initctl check-config for verification
<joern> so the executable has to do whatever initialization and then somehow emit this event
<broder> but if you want to emit some event, you should use initctl emit in the exec/script line
<joern> ok
<joern> and for "started foo", when is that event generated?
<broder> that's emitted when the job changes states from "starting" to started
<broder> when that happens depends on the expect line and whether it's marked as a task or not
<broder> possibly other things, too
<joern> so with "expect fork", as soon as fork(2) returns, i take it?
<broder> or possibly when fork is called. i don't recall
<joern> i would imagine there could be nasty race conditions then - although very hard to hit
<joern> anyway, thanks!  i believe i have enough rope to hang myself now
<broder> well, you just have to make sure your daemon is actually ready whenever you trigger that transition
<broder> so do all your setup (binding to ports, setting signal handlers) before you fork
<joern> and maybe spend a night reading all existing /etc/init/*.conf files before writing my own
<broder> if you're writing a daemon/binary targeted at upstart specifically, i'm a fan of "expect stop"
<broder> then you just do "raise(SIGSTOP);" whenever you're done with setup
<joern> i would actually like not to have any dependencies on upstart.  we currently have tons of subtle dependencies and my unwritten job description is to find them all and remove them - or at least make them explicit
<joern> would be nice if i was the last person to suffer this pain
<broder> you should check out the upstart cookbook, btw, if you haven't
<joern> 4.3.1 seems to be the answer to most of my questions.  thanks!
<lamal666> Hi, im trying to write an upstart job to execute a script but when i run it- nothing happens
<lamalex> http://paste.ubuntu.com/770327/
<lamalex> ha clearly i cp'd another conf file..
<lamalex> sudo start coverity 
<lamalex> coverity start/running, process 2518
<lamalex> is what i get
<lamalex> but the server doesn't really start
<ion> http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section
<lamalex> ion, so i dont have a script stanza- i just have exec
<lamalex> can i just put this above the exec line
<lamalex> or do i need script stanza
<xaka> hi! is anyone from dev team here?
<ion> lamalex: Change
<ion> exec foo
<ion> to
<ion> script
<ion>   exec >/path/to/log 2>&1
<ion>   set -x
<ion>   exec foo
<ion> end script
<lamalex> ion, also is it possible to write a custom stop job?
<ion> Use pre-stop.
<lamalex> ah cool thanks
<xaka> is there any way to specify dependencies? like i want to start service A on runlevel 2345, but after service B has been started
<ion> A: start on started B, stop on stopping B
<ion> B: start on runlevel [2345], stop on runlevel [!2345]
#upstart 2011-12-15
<joern> i have a problem that may actually not be between keyboard and chair
<joern> conf-file contains these bits:
<joern> start on (started foo and started bar and started baz)
<joern> stop on (stopped foo or stopped bar or stopped baz)
<joern> initially, when foo, bar and baz start, this service starts as well, good
<joern> when stopping baz, this service stops, good
<joern> when restarting baz (foo and bar are still running), this service does not start
<joern> does upstart require every one of (foo, bar, baz) to transition into started, or only the entire expression to transition?
<tylerflint> so let's say I need to send a signal to a process that was started with upstart
<tylerflint> what is the best way to do so?
#upstart 2012-12-10
 * xnox ponders if jodh is lost in testing 1.6.1
* xnox changed the topic of #upstart to: Upstart 1.6.1 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
<xnox> slangasek: https://bugs.launchpad.net/libnih/+bug/672643/comments/2 <--- is your bug.
<xnox> with a patch.
<slangasek> xnox: sweet, so it was xfs :)
<xnox> slangasek: i'm not sure which branches we can merge that patch.
<xnox> slangasek: well there are other "popular" filesystems that are affected.
<slangasek> xnox: packaging branches only, AIUI Scott is still upstream for libnih
<xnox> slangasek: ack. but it does mean that potentially upstart does not do the right thing on xfs/reiserfs and other filesystems.
<slangasek> right
<slangasek> so we should definitely get that fixed
<slangasek> would you mind opening a bug against the Debian package for me?
<xnox> slangasek: ok.
<slangasek> stgraber, xnox, jodh: so regarding https://code.launchpad.net/~stgraber/upstart/upstart-prctl/+merge/136759
<slangasek> has anyone actually talked to the desktop team (and in particular, Ted) about this constraint that upstart jobs won't work on 14.04 until you reboot?
<slangasek> this is something they should be involved in discussing, we shouldn't assume we know the right solution for them
 * xnox didn't discuss it with -desktop.
<xnox> but yeah, I agree we should.
<xnox> something like a mail to -devel with cc to seb&ted?
<stgraber> I believe we covered it in the spec before we asked the desktop team for feedback, but we didn't get any really useful feedback from them
<stgraber> so yeah, might be worth asking specifically about the prctl case
<stgraber> and explain exactly what won't work (spawning, events, ... will be fine, it's just respawning and stopping that won't quite work)
<stgraber> well, stopping could probably work as long as we don't expect to get SIGCHLD
<slangasek> stgraber: well, please reach out to Ted specifically
<slangasek> he and his team will be the most impacted, I think, so he needs to understand the implications here
<stgraber> ok, will send an e-mail this afternoon and Cc upstart-devel
<slangasek> stgraber: perfect, thanks
<slangasek> xnox: what is the value of d_type on these filesystems?
<slangasek> xnox: is it set to DT_UNKNOWN?
<slangasek> xnox: commented on the merge with suggestions for improvement
#upstart 2012-12-11
<skyion> unusual instance where upstart is stopping during the boot process on "init: Handing mounting event" though I am unable to determine which mounting event it is referring to?
<xnox> slangasek: thanks for the review, will look into testing / implementing it.
<PaulePanter> slangasek: Is Upstart 1.6 going to be included in Debian Wheezy?
<PaulePanter> I saw your blogpost about it being in Sid/unstable and wonder about the roadmap.
<slangasek> PaulePanter: having it in wheezy is certainly the goal, yes
<slangasek> xnox: +1 for your latest version of the xfs fix
<xnox> slangasek: ack. Shall I upload to debian & ubuntu? Or will you take of one or both?
<xnox> s/take/take care/
<slangasek> xnox: if you have time to upload it to to Debian, I would appreciate it, otherwise I was going to prepare an NMU
<slangasek> xnox: for Ubuntu, definitely upload please
<slangasek> (as for NMUing, I was going to mark this bug 'serious' severity for Debian)
<xnox> slangasek: ah. /me thought you maintain libnih in debian. Ok, i'll file an nmu bug in debian.
<slangasek> I don't, at least not yet
<slangasek> I may wind up having to do so
<slangasek> file an nmu bug> you already opened a bug, just bump its severity? :)
<xnox> slangasek: actually, add nmu patch to the existing bug.
<xnox> =)))))))
<slangasek> yep
<toabctl> stgraber, what's left to do for the dconf bridge?
<toabctl> xnox, do you have a branch for the gtk-doc generation for libnih?
<stgraber> toabctl: I think it's mostly ready, we "just" need the upstart user session to be fully implemented now so we can actually use it
<toabctl> "just" :-)
<xnox> toabctl: not yet sorry. need to find it against & push it. Will ping you when I do this. I ended up just reading the header files & using jodh's slides from the UDS.
<xnox> toabctl: the gtk-doc generated documentation will not have more than that.
<toabctl> xnox, I know. But it's possible to integrate the gtk-doc stuff into devhelp and that's what I use mostly for development docs
<toabctl> xnox, thanks!
<xnox> toabctl: yeah.
<PaulePanter> slangasek: Nice. Any time estimate when you will send an unblock request?
<slangasek> PaulePanter: heh, the unblock request was sent a while ago; now it's a matter of straightening out the prerequisites
<PaulePanter> slangasek: I see. Are the prerequisites listed somewhere?
<slangasek> PaulePanter: bug #686387 is the unblock bug; 'grep-excuses upstart' shows what's actually blocking at present
<PaulePanter> slangasek: Thanks!
<PaulePanter> I see you uploaded a new version. So first wait 10 days and then hopefully the release team will unblock the transition.
<PaulePanter> slangasek: Again, your blogs post were very interesting! So if the changes in 1.6.1 <https://launchpad.net/upstart/1.x/1.6.1> warrant a new post, it would be great if you write it. ;-)
<slangasek> PaulePanter: 1.6.1 itself probably isn't anything interesting to a general audience.. I do have a couple of blog posts in my queue though
<PaulePanter> Awesome!
<PaulePanter> slangasek: Wanting to test it in Wheezy, besides upstart obviously, Iâd need udev, json-c and mountall from unstable?
<slangasek> yep
<slangasek> and you'll want to be aware of a couple of outstanding bugs on related packages
<slangasek> bug #695566, and bug #694499
#upstart 2012-12-12
<xnox> does nih_list_add_before exist?
<Varazir> Hello 
<Varazir> Hello I have made a script to run on up start http://pastebin.ca/2291905 I get error  " /proc/self/fd/9: 18: [: on: unexpected operator" if I run the script by it self like this http://pastebin.ca/2291900 it works 
<SpamapS> Varazir: thats interesting...
<SpamapS> Varazir: it kind of looks like the variable expansion isn't working right
<Varazir> ok 
<Varazir> is there a way to easy debug ? 
<SpamapS> Varazir: but I don't see any obvious reason that would fail
<SpamapS> Varazir: set -x
<SpamapS> Varazir: also if you're on 12.04 or later, you should get any uncaught output in /var/log/upstart/yourjobname.log
<Varazir> it's where I found the error msg 
<Varazir> set -x didn't give any more info 
<xnox> Varazir: what is $1?
<Varazir> 8 or 0 
<Varazir> err 5 or 0 
<Varazir> the script starts up my TV and AVR befor lightdm starts XBMC
<Varazir> using a CEC adapter 
<jrib> Varazir: maybe you can check what the value of $power actually is before it enters until?
<SpamapS> the ""'s should, in theory, handle that
<SpamapS> Varazir: I see what xnox is asking. There's a reference to $1 without anything setting it. Upstart certainly won't set it
<SpamapS> On line 21
<SpamapS> power=$(cec_power $1) >/dev/null 2>&1   # Assign power state to $power 
<SpamapS> thats basically always going to be just   $(cec_power)
<Varazir> yes it's inside a function 
<Varazir> that I call with the value 0 or 5 
<jrib> oh,  yes, line 21 is part of the cec_power_on() definition... I missed that
<Varazir> echo "test $power" should give me output in the upstart log file correct ? 
<jrib> *cough* indentation *cough* :)
<SpamapS> oh right, its indented horribly ok
<SpamapS> Varazir: yeah, you really need to start indenting things
<Varazir> I have just that pastebin dosn't show it 
<Varazir> err it indenting stuff 
<Varazir> I see I should ofc indent the untill loop too
<Varazir> I added echo "test $power" but nothing came up in the log file 
<Varazir> it's strange that it keeps running the untill loop 
<Varazir> I can see in my own logfile that the $power is set 
<Varazir> tested the script again standalone and it worked like a charm 
<SpamapS> Varazir: perhaps the cec tools expect some env vars to be set.
<Varazir> I can't see it's that complaning over 
<jrib> you have = in one script and == in the other by the way
<Varazir> that's changed 
<Varazir> http://pastebin.ca/2291931
<jrib> Varazir: if you change "#!/bin/sh" to "#!/bin/sh -e", the result is the same?  I'm not sure why it would matter, but let's see...
<Varazir> worked
<Varazir> same result 
<Varazir> http://pastebin.ca/2291935 output with set -x running the script 
<Varazir> init-checkconf /etc/init/start-htpc.conf
<Varazir> ERROR: failed to ask Upstart to check conf file
<slangasek> xnox: do you plan to take care of Debian bug #695604 in libnih, or should I add it to my list?
<Varazir> http://pastebin.ca/2291936
<Varazir> jrib: and SpamapS: I need to go I'm back in 1.5 
<Varazir> hour 
<Varazir> ello 
#upstart 2012-12-13
<xnox> slangasek: i will do it today/evening. Probably will push nmu branch to collab-maint repository and attach git am patch to the bug.
<xnox> toabctl: http://people.canonical.com/~xnox/nih/
<xnox> toabctl: & lp:~xnox/ubuntu/raring/libnih/gtkdoc
<toabctl> xnox, thanks!
<xnox> toabctl: there are a few functions not documented & there are parse errors & it's for nih only (no nih-dbus, no upstart). But it's a start...
<xnox> toabctl: atleast devhelp lookups should work from emacs / alternative IDEs.
 * xnox thinks XDG spec is ambigious about file names.
<xnox> "If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used."
<xnox> what counts as empty? is " " empty?
<slangasek> xnox: ok, cool :)
<jtane> hi does anyone know if there is an "official" way to enable user jobs? 
<jtane> all i could find was this: http://bradleyayers.blogspot.com/2011/10/upstart-user-jobs-on-ubuntu-1110.html
<jtane> ion: any idea? saw you were one of the developers maybe..
<SpamapS> jtane: your best bet is slangasek
<SpamapS> slangasek: ^
<jtane> SpamapS: ok great, thanks!
<jtane> slangasek: is there an "official" way to enable user jobs?
<jtane> slangasek: i found this - http://bradleyayers.blogspot.com/2011/10/upstart-user-jobs-on-ubuntu-1110.html
<jtane> slangasek: but wasn't sure if it was the best way
<slangasek> I couldn't say; I've never enabled user jobs
<slangasek> they're disabled because they're not considered ready for use in Ubuntu yet
<jtane> slangasek: i see, thanks
<jtane> slangasek: this feature would be very useful to me - do you know if anyone is actively working on this?
<jtane> slangasek: or, just trying to get an idea of whether this is a project priority at all...
<slangasek> oh, user jobs are definitely a focus for upstart development during the current Ubuntu release cycle
<slangasek> but they're not currently in a state that's useful
<jtane> slangasek: thanks a lot
<slangasek> sure
<slangasek> for reference, the blueprint is here: https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-upstart-user-session-enhancements
<jtane> slangasek: interesting
<jtane> slangasek: naive question - how can i dl the source?
<slangasek> jtane: bzr branch lp:upstart
<xnox> jtane: the "current" way of enabling user jobs is documented http://upstart.ubuntu.com/cookbook/#user-job but that's merely gives ability to add/run your own jobs as your own user.
<xnox> this cycle we are working on making upstart manage the whole user session and that's still in development state as outlined in the blueprint.
<jtane> xnox: thanks - i saw that and got the right Upstart.conf file from the source
<jtane> xnox: what does "user session" mean exactly?
<jtane> xnox: w/r/t to upstart at least...
<xnox> jtane: user jobs = when user logs in read ~/.init/*.conf and launch/manage them as appropriate.
<xnox> jtane: user session = when user loggs in gnome-session is started that spawns a lot of process: bluetooth, update-manager, gwibber, network manager, etc....
<xnox> upstart user session means that instead of gnome-session loosing track of above process,  upstart manages them starts/stops/respawns them as appropriate.
<jtane> xnox: i don't know if this changes anything, but i'm using ubuntu server
<xnox> jtane: we do plan to have "text upstart user sessions" but probably not this cycle.
<xnox> jtane: on the server, I found it useful to enable "upstart user jobs" such that developers can drop init files in their home directory to run django/ruby/what-not daemons for test/development code.
<jtane> xnox: yes that is my intention
#upstart 2012-12-14
<jtane> xnox: it works well
<jtane> xnox: except no events?
<xnox> jtane: on the other hand if nobody directly logs into the server. you can simpy use "setuid" in a custom upstart job.
<xnox> jtane: there are still /some/ events & you can emit your own if there is need.
<jtane> xnox: true, i guess i was hoping to hook network or filesystem on boot
<xnox> jtane: you can / should be able to do so with "user jobs"
<jtane> xnox: as the user will probably never actually login
<xnox> jtane: if the user never logs in, it might be better to use a system job with "setuid" or crontab with @reboot.
<jtane> xnox: i guess i take that back, they may need to login at some point and start and stop their services
<jtane> xnox: so requiring root here is a pain
<xnox> jtane: experiment a little =)))) i see. I haven't done user jobs in a while (no longer deal with webops stuff). But if you try to do something and it doesn't work, just shout out with a sample job.
<xnox> and I am sure one of the regulars here will help you out =)
<jtane> xnox: how would you feel about a system job that loops over users and starts the jobs using something like ```sudo -u $USER -H $HOME start $SERVICE```
<jtane> xnox: just to have a boot hook
<jtane> xnox: everything else seems to work well
<jtane> xnox: ps, thx for your help
<jtane> xnox: better example - https://gist.github.com/4281324
 * xnox ponders if there is a way to emit the dbus call and autostart user jobs.
<jtane> xnox: interesting - https://bugs.launchpad.net/upstart/+bug/1065965
<xnox> jtane: =)))) yeah... so for "upstart user sessions" we are working on playing back / re-emiting important events such as network-up for the user jobs.
<xnox> it would help to fix the above bug.
<jtane> xnox: i guess the workaround he suggests (wait for dbus then emit a user-jobs event) is good enough for now
<jtane> xnox: er, i guess for any of this to work, my system job needs to manually create user sessions? how can i start a user session as root?
<slangasek> that's the trick, isn't it? :)
 * xnox is pondering this in my head, but i am not sure 
<slangasek> starting user jobs without an associated user login session is non-obvious
<slangasek> certainly in the general case, jobs can't be expected to work the same way when started from a user session than when not
<slangasek> because of things like kerberos credentials / afs tokens, ecryptfs home directories, etc
<xnox> slangasek: pushed gtkdoc branch update. but not doing debian nmu tonight, had christmas party drinks.
<slangasek> xnox: does the user sessions spec have any concept of a "login-session-started" event?
<slangasek> (I guess we should have such a thing)
<slangasek> xnox: hmph, there's no legal limit on Debian upload alcohol level ;)
<xnox> slangasek: yeah, but there are people who like to lol at typpos on OFTC ;-)
<xnox> slangasek: it's best you ask stgraber about the "login-session-started" event. he had some ideas on how to do that and also notify about the state of machine at login, e.g. networking events may have been missed but user-jobs should still find out about them.
<jtane> sort of grasp some of this... essentially the problem is that job dependencies may, in turn, depend on a login session for the process owner?
<jtane> also, is there a diff between the terms "login session" and "user session"?
<xnox> jtane: currently we use both interchangeably with roughly the same meaning and we have not yet formally defined the meaning of either of those.
<jtane> xnox: ok thx
<xnox> jtane: upstart has currently support for "sessions" - where pid 1 manages "user jobs" & "upstart in chroot jobs"
<xnox> jtane: and there is the bright undefined future of "login sessions" / "upstart managed user sessions"
<xnox> it is probably best to speak of "login sessions" as the brave new, yet to be defined future.
<jtane> i guess i'm confused as to why upstart cares about whether a user has a "session"
<jtane> i imagine "user jobs" as simply processes owned by a certain user that could be started and stopped by that user...
<jtane> maybe i'm missing something big here
<slangasek> xnox: oh, midair collision with your libnih branch, stgraber uploaded something :)
<stgraber> ah yeah, I uploaded my libnih fix this morning :)
<xnox> no worries =)
 * xnox will fix it up.... (look at the clock) later today =)
<jtane> hey so i just tested this: https://gist.github.com/4281324
<jtane> works great
<jtane> is "start" automatically creating user sessions?
<jtane> or do i even need to be conscious of "sessions" if this works?
<xnox> you should be good to go, things may change with new world order in the future type sessions.... but if they do, it should improve stuff to e.g. hopefully not require above hack.
<jtane> xnox: right, just wanted to check and make sure i'm not doing anything insane (i still don't think i grasp sessions)
<jtane> thanks a lot everyone for your help!
<tgm4883> I've created a new upstart job (followed http://upstart.ubuntu.com/getting-started.html ) and placed it in /etc/init/ and rebooted, but it still says "unknown job" when trying to work with it. Is there a better set of instructions somewhere?
#upstart 2012-12-15
 * stgraber waves from Europe
<stgraber> now to hope the jetlag will be over before the upstart sprint ;)
<consolers> 1. udevd shipped with quantal doesnt support /lib/devices anymore, as it states in the `man udev', instead the functionality is removed. how do i create /dev/xconsole at startup? 2. how do i overcome plymouth rules, so upstart doesnt hang at startup , waiting for some plymouth event which never happens? I want to get an unconditional prompt regardless of what happens to plymouth
<consolers> for example if initramfs doesnt start plymouth, upstart hangs waiting for some event, instead of spawning a login getty
<consolers> how do i stop that
<consolers> if you know and refuse to answer the question, may your head fall off your shoulders
<eruditehermit> hey, does anyone know how to create an upstart script that will trigger on loading of a kernel module?
#upstart 2012-12-16
<Varazir> start on <service has run before> 
<Varazir> can it be done ? 
<Varazir> nvm
<SpamapS> Varazir: did you figure out what you needed?
<Varazir> SpamapS: I think I solved the problem not exting my script 
<Varazir> I added and started htpc to the lightdm.conf file 
<Varazir> the orginal htpc.conf file had exit 0 
<Varazir> and then lightdm wouldn't start due to the script wasn't running 
<SpamapS> ah ok
<Varazir> SpamapS: Didn't work
<Varazir> for some reason my script do not start 
<Varazir> init-checkconf /etc/init/htpc.conf
<Varazir> ERROR: failed to ask Upstart to check conf file
<Varazir> And I don't get any error msg what I can see
<wakko> hi there
<wakko> i am lookup for a default set of jobs that does not use rc, does someone knows where i could find that ?
<wakko> slookup/looking/
<JanC> you mean without sysvinit compatibility?
<wakko> yes
<JanC> hm, I don't know about any default set like that
<JanC> I think it's only used like that in embedded systems
<wakko> actually i am trying to bake an embedded system
<JanC> I think Palm/HP webOS uses it like that
<wakko> thanks for the info
<JanC> I'm not sure how Google ChromeOS uses it
<wakko> for the moment i am stuck at the runlevel thing
<JanC> wakko: maybe also ask on the mailing list
<wakko> when i type runlevel it tells me "runlevel:/var/run/utmp: No such file or directory"
<JanC> you don't have to use runlevels
<wakko> i need to find out what does populate this file :)
<wakko> i would like not to use them indeed, but at the same time i'd like to have the reboot command to work
<JanC> "reboot --force" reboots the system without any need for runlevels
<JanC> but you'll have to make sure everything is topped properly before doing that yourtself
<JanC> *yourself
<JanC> and *stopped* (sigh)
<wakko> i don't understand why reboot is shipped with upstart and still relies on /etc/init.d/rc
<wakko> (according to the cookbook)
<JanC> there is also a reboot syscall BTW
<JanC> wakko: because of the sysvinit compatibility I suppose
<JanC> you don't want to reboot before your database that still uses a sysvinit script has written all data to disk, for example  âº
<wakko> i was thinking reboot would send an event to upstart thru dbus, and then upstart would call /etc/init.d/rc using a job 
<slangasek> that's correct
<JanC> well, that's more or less what it does
<slangasek> and then it's the init scripts that finish up tearing everything down, and calling the reboot syscall
<JanC> if you don't use --force
<slangasek> the reason for this is that event based systems make it much easier to respond to events quickly (on startup or shutdown or anywhere in between), but they make it *harder* to know when you're actually done processing
<JanC> if you don't use the sysvinit compatibility, you'll have to do that syscall yourself (e.g. by calling "reboot --force")
<wakko> JanC: i cannot use the reboot command without --force, so upstart still get a "reboot event" turns off all deamons and finally do a reboot --force ?
<JanC> well, you can do the "reboot --force" (or similar another way) from an upstart job, of course
<wakko> that would be nice
<JanC> I'm sure distros that don't use sysvinit have their own implementation of reboot & shutdown BTW
<JanC> e.g. Gentoo & CRUX
<wakko> Does Gentoo use upstart ?
<JanC> no, (certainly not by default)
<JanC> but they don't use sysvinit either
<JanC> they have their own init system
<wakko> i think it's OpenRc by default
<JanC> yes
<JanC> which was originally derived from bsd init IIRC, but evolved a lot since
<wakko> i think i could keep the runlevel stuff :) so i'll don't have to rewrite them and i can stay with upstart "builtins"
<JanC> well, it would be interesting to see upstart working without sysvinit/runlevels/etc.
<JanC> but I understand you probably have time constraints about getting this to work  ;)
<wakko> the cookbook says reboot does a "runlevel RUNLEVEL=6 PREVLEVEL=2"
<wakko> i think i could keep the runlevel logic but skip the rc scripts
<JanC> that would probably work
<wakko> JanC, slangasek, thanks for your help
<JanC> it's more or less what happens if /etc/init.d/* & /etc/rc.local are empty, I suppose  âº
<wakko> :)
<wakko> maybe, but i still need to clarify some points so i can tell
<wakko> lol it works now...
<wakko> i'll definitely write an article or something later
<wakko> gn all and thanks again
#upstart 2013-12-09
<mgorbach> Very strange. How come sometimes I see logging from upstart on TTY7, and sometimes it's completely empty?
<mgorbach> Seems to work about 30% of the time on each reboot of this server machine.
<xnox> mgorbach: wait.... maybe it didn't come up yet. tty7 upstart job needs to start and it's racing in parallel with pretty much everything else =)
<mgorbach> How come sometimes I see logging from upstart on TTY7, and sometimes it's completely empty?
<mgorbach> Seems to work about 30% of the time on each reboot of this server machine.
<tseliot> hi all, if I wanted to make sure that a job such as the following doesn't start unless a file is available, would I simply have to test the existence of this file and exit 0 if the file doesn't exist? http://paste.ubuntu.com/6546310/
<tseliot> or is there a better way (also compatible with precise)
<tseliot> xnox: ^
<xnox> tseliot: which file are you testing for?
<xnox> tseliot: in general if it's the executable binary "/usr/bin/nvidia-persistenced" simply do
<tseliot> xnox: the actual binary /usr/bin/nvidia-persistenced
<xnox> tseliot: right, in that case simply do: exec /usr/bin/nvidia-persistenced --user nvidia-persistenced
<tseliot> xnox: so, I let it fail?
<xnox> tseliot: upstart will notice that the exectuable is not there, and the job will never start and move to stop/failed state. Which is equivalent to any other reasons job may fail to start or not suppose to start.
<xnox> tseliot: if you wish you can do
<tseliot> xnox: if that's acceptable, then it saves me the effort to work around it
<xnox> tseliot: pre-start [ ! -x /usr/bin/nvidia-persistenced ] && { stop; exit 0 }
<xnox> tseliot: pre-start exec, but that's entirely redundand.
<xnox> tseliot: yeah, that's absolutely acceptable, after all all packages can be removed, but not purged and hence init files left around.
<xnox> tseliot: upstart was designed for debian/ubuntu like systems ;-)
<tseliot> xnox: I'll keep it as it is then, thanks a lot :)
<xnox> =)
<tseliot> xnox: so, apparently if that file is a link to the binary, upstart won't use it
<xnox> tseliot: can you send / point me to the sample packages?
<tseliot> xnox: it's this one https://github.com/tseliot/nvidia-graphics-drivers/tree/331-updates (the 331-updates git head)
<tseliot> xnox: and these two patches on top of it: http://paste.ubuntu.com/6546735/ http://paste.ubuntu.com/6546738/
<tseliot> and the actual error in /var/log/upstart/nvidia-persistenced.log is "/bin/sh: 1: exec: /usr/bin/nvidia-persistenced: not found"
<tseliot> the file is there though, it's a link
<tseliot> it's a link because it shouldn't show up and/or run when we disable the discrete nvidia card and use only the integrated Intel card on systems with hybrid graphics
<xnox> tseliot: why are you using variables?
<xnox> tseliot: do you need it to be configurable / overridable?
<tseliot> xnox: in the job? That comes from nvidia
<xnox> tseliot: why is your job "exec $VAR", instead of "exec nvidia-persistenced"
<xnox> tseliot: with $VAR you are forking a shell, with "exec nvidia-persistenced" i gets directly execed without a fork to a shell.
<xnox> tseliot: i'm nearing end of day and still have a few things to finish off.
<tseliot> xnox: that's something that I take straight from the nvidia-installer. I can replace with my own upstart job if needed
<tseliot> (I didn't write it myself)
<tseliot> xnox: no problem, thanks for your help
<xnox> tseliot: can you try: http://paste.ubuntu.com/6546826/
<tseliot> xnox: nvidia-persistenced is a daemon BTW
<xnox> tseliot: =)
<tseliot> xnox: oh, I failed to mention that if I start the job manually it seems to work
<xnox> tseliot: so how do you start it that makes it fail?
<xnox> tseliot: or how does it get started to fail?
<tseliot> xnox: start on runlevel [2345]
<tseliot> when that happens, I get the error
<xnox> tseliot: try my job and reboot.
<tseliot> xnox: I think I know where you're getting at ;) Let me try
<xnox> tseliot: rm the /var/log/upstart/nvidia*.log first, to make sure you are not looking at old messages.
 * xnox been there, done that.....
<tseliot> :)
<tseliot> xnox: I'm not even getting a log now... weird
<tseliot> and it doesn't start
<tseliot> unless I do it manually
<xnox> tseliot: weird. I'll look into it tomorrow.
<tseliot> xnox: thanks :)
#upstart 2013-12-11
<jderose> So I have some experience with system jobs, and am experimenting with session jobs on 13.10. Am I correct that there currently are no dpkg hooks or other package magic for dealing with sessions jobs?
<jderose> For example,  I was surprised that my session job wasn't shutdown when the package was removed (what I would expect with a system job).
<xnox> jderose: correct.
<xnox> jderose: upstart upstream doesn't define what the behaviour should be, distributions do.
<jderose> xnox: is that something planned for the future? is there a current best practice i should follow for shutting down a session job when the package delivering the foo.conf file is removed?
<xnox> jderose: so what should happen on package upgrade/downgrade/install/remove/purge/configure/deconfigure is something for a distribution to define.
<xnox> jderose: Debian policy doesn't define it, nor do Ubuntu policies.
<jderose> xnox: so in the case of ubuntu then... well there ever be similar behavior to how system jobs are currently handled?
<xnox> jderose: you should not start, nor shutdown jobs on install/removal.
<xnox> jderose: because e.g. a package is removed during upgrade, and the current instance should keep on running, otherwise you may cause data loss.
<xnox> jderose: at the moment Ubuntu policy is following the general guidelines of Debian, where user running processes / data / any files in $HOME should not be modified.
<xnox> jderose: i cannot speculate what may or may not happen, as no discussions about the Policy for the user sessions jobs has happened yet.
<jderose> gotcha, thanks
<xnox> jderose: if you want a better opinion / discussion about this, please start a discussion on ubuntu-devel-discuss or ubuntu-devel mailing lists.
<jderose> xnox: which list is better for this sort of thing?
<jderose> also, thanks for your help :)
<xnox> jderose: ubuntu-devel-discuss, or if you have access (ubuntu membership) ubuntu-devel.
<jderose> okay, ubuntu-devel it is then
<jderose> xnox: so i notice that none of the session jobs in ubuntu 13.10 are using any 'start on dbus-activation org.foo.Bar'... is this feature not considered stable enough yet, or is it just a matter of things transitioning still?
<xnox> jderose: as in to start job when a given bus name appears?
<xnox> jderose: (the syntax you provide is not correct, and i am not sure specifically what you mean)
<jderose> maybe i'm misunderstanding the features... i was thinking start when that bus name is requested
<jderose> xnox: i was looking at the example here - http://upstart.ubuntu.com/cookbook/#run-a-job-when-a-user-logs-in
<jderose> and also looking at the comment in /usr/share/upstart/sessions/hud.conf
<xnox> jderose: 11.13 section does not work in Ubuntu 13.10, therefore please don't try to use it.
<jderose> xnox: okay, thanks :)
<xnox> jderose: it is on track to get fixed in Ubuntu 14.04
<xnox> jderose: there are some other releases were it does work, can't remember off the top of my head at the moment.
<jderose> xnox: hmm, so in 13.10, if you did `stop hud` and then requested something from com.canonical.hud over DBus, would you end up with a hud instance that upstart wasn't aware of, wasn't managing?
<xnox> no. hud will be started again under upstart.
<jderose> ah, /usr/lib/x86_64-linux-gnu/hud/dbus-activation-hack.sh, okay, now i understand :)
<xnox> jderose: please don't follow that as best practices example. just wait until dbus-activation proper will be fixed in 14.04 and then all of these hacks will be gone.
<jderose> xnox: so my DBus service currently uses an xdg autostart file to start after login, and then DBus activation to start it otherwise if it's not running for whatever reason. if i switch to upstart for my remaining 13.10 releases, what do you recommend i do? wouldn't i need to use an approach like the dbus-activation-hack.sh?
<xnox> jderose: does your service ever self-shutdown? if not that simply add upstart job + xdg override in /usr/share/upstart/xdg/ (such that xdg-autostart is disabled under upstart)
<xnox> and still keep the normal xdg autostart
<jderose> no, doesn't self shutdown... sure run for the entire desktop session.
<jderose> xnox: thanks for explaining /usr/share/upstart/xdg/... i was wondering why packages with session jobs were still including an xdg autostart .desktop file
<jderose> xnox: one issue i see with the above: session jobs don't seem to automatically get started when the package is installed. so if a user installs my app and (without logging out or rebooting) opens one of the UI bits which needs the service, i'd get a instance of the service started through dbus activation, that upstart doesn't know about... right?
<xnox> yes, and that's absolutely fine.
<xnox> upstart user sessions is optional, and on other desktop environments without upstart in user session it should still work as per above.
<jderose> so what i'm trying to fix with upstart is that in my very quirky use case, i need to be careful to cleanly shutdown the service otherwise i end up with a lingering couchdb process that lives on even *after* the user logs out (which will cause untold havoc should the user log back in)
<jderose> currently i'm using org.gnome.SessionManager, but it's a bit fragile and doesn't work on the other ubuntu flavors
<jderose> but upstart seems to do the trick, when it stops the service i don't have any lingering processes is the process group, even without using org.gnome.SessionManager
<jderose> ie, why i'm not keen to have an instance of the service that isn't managed by upstart :)
<jderose> xnox: anyway, thanks again for all the help! you seem to help me no matter what irc channel i'm asking questions in =D
<xnox> jderose: add a second job, which "start on desktop-end" (or whatever the event is) which properly finds and kills _your_ coundbs and not anybody elses.
<xnox> jderose: you should have started with that question.
<xnox> jderose: "i have run away processes, how do i reliably kill them on logout?"
<xnox> jderose: instead of making up a solution, and then asking how to implement your solution. =)
<jderose> well, but assuming the service *is* managed by upstart, i don't have any issues with the run away process. the only missing thing is lack of dbus activation in upstart for 13.10.
<jderose> but i see your point. either way, i learned a lot more about upstart :)
<jderose> xnox: interesting, so even without a session job, without my org.gnome.SessionManager hack, on 13.10 i don't have any lingering couchdb processes after logout
<jderose> whereas on 13.04 if i turn off my org.gnome.SessionManager hack, there is definitely a couchdb process still running after logout
<xnox> jderose: i believe on 13.10, session init upstart does make a prctl call to make sure all processes are parented to session-init and do not get reparented to pid1.
<jderose> so i guess the difference must be that the upstart managed user session is just much better at properly cleaning up after itself, even stuff that wasn't an explicit session job
<xnox> jderose: can you look and compare the ps tree? and check whos is the parent of couchdb?
<jderose> yeah, just a sec...
<jderose> xnox: yeah, after logout the parent of couchdb is 1
#upstart 2013-12-13
<distilledchaos> Could somebody explain why if statements appear to work incorrectly in an upstart script?
<distilledchaos> https://gist.github.com/skeggse/7939519
<distilledchaos> I've worked this down to a small test case, which I appear to be able to reproduce
<adrien_oww> if he comes back: he was using '==' instead of '=' in the script
#upstart 2013-12-15
<rojaro> hi, i am trying to bootstrap a ubuntu machine and in the post-install process (pre-boot) i want to install a few services like openvpn, but the installation of these packages fails because upstart is not yet running (which it will be after the reboot) ... is there a way around this problem, besides rebooting and installing the services afterwards??
<xnox> rojaro: do they simply fail to start, or do the packages fail to install/configure?
<rojaro> i found the solution ... https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224/comments/58
<rojaro> thanks anyway :)
<rojaro> cu
<nchoosek> anyone have tips on how to ensure my gfx drivers are loaded as part of an upstart condition? here's my best shot but it doesnt seem to be working: https://gist.github.com/nchoosek/a1fa513bad5e8262a4ef
#upstart 2014-12-10
<DzAirmaX> hi all
<DzAirmaX> I have a problem concerning this script here http://guide.munin-monitoring.org/en/latest/example/rrdcached/upstart.html#example-rrdcached-upstart
<DzAirmaX> can someone check and tell me if there is a writing pb in it ?
<DzAirmaX> is someone alive here ?
<cwillu_at_work> DzAirmaX, what's the actual problem?
<switchflip> Hi everyone... relatively new to chef, but I'm trying to use chef resources inside of ruby_block... having trouble and scratching my head.
<switchflip> the resource in particular is remote_file.
#upstart 2014-12-12
<hramrach_> hello
<hramrach_> what do I do if my system does not start?
<hramrach_> /var/log/upstart is empty
<hramrach_> getty is not spawned
<hramrach_> ssh is not running
<hramrach_> last processed event seems to be killing mountall-net
<hramrach_> ok, installing sysvinit gives diagnostics
<hramrach_> I have SYSFS_DEPRECATED or old kernel apparently
<hramrach_> hmm, replaced kernel, sysvinit no longer complains, reinstalled upstart, still does not start system
<hramrach_> no diagnostic, of course
<hramrach_> ok, I guess I get back to sysvinit :s
<hramrach_> btw is upstart sensitive to time skew? I have no hwclock. never observed issue with other clockless systems, though
<tsaavik> hey all, upstart newb with dumb question. I just created my first job but I don't see it in description "munin-node"
<tsaavik> author "Chuck Short <zulcss@ubuntu.com>"
 * tsaavik fails at cut and paste
<tsaavik> I don't see it in: initctl list
<tsaavik> ah, I don't think it liked me doing env ipaddress=$(facter ipaddress) inside the pre-start script, shows up now
<tsaavik> s/inside/outside
<tsaavik> Is there a way to synatx and/or lint check an upstart job?
#upstart 2016-12-16
<harrse> seems fun
#upstart 2016-12-17
<\\\\\\\\\\\> \quit
<\\\\\\\\\\\> \exit
<\\\\\\\\\\\> Sorry, I forgot to tmux, and also how to irssi apparently.
<\\\\\\\\\\\> Hello. I am migrating some deployment scripts from SysV init to Upstart and was wondering if there was a way to interpolate the standard job environment variables in an env stanza. 
<\\\\\\\\\\\> I am trying to do this, but it does not work:
<\\\\\\\\\\\> env CLIENT=${UPSTART_JOB%%-*}
<\\\\\\\\\\\> ${UPSTART_JOB%%-*} works in the exec stanza, so I could just go with that, but the variable name is more readable. 
