#upstart 2007-03-12
<Keybuk> morning
<_ion> That.
<Keybuk> :)
<_ion> Btw, last night i saw a dream where i found out how to overflow the variable type of the universe's coordinate system. :-)
<Keybuk> eerrrrr?
<_ion> :-)
<Keybuk> a more interesting question, if you overflowed your location in the universe, would you return to the start?
<_ion> I don't remember how the dream continued. :-(
<Keybuk> (cur) (last)  04:45, 11 March 2007 Mrzaius (Talk | contribs) (See also - rm eINIT redlink - not really article worthy, as it has yet to be adopted by any distro, and isn't even fully supported by gentoo)
<Keybuk> aww
<Keybuk> wikipedia's editing stance is somewhat harsh
<_ion> I wrote a small util that might be handy with some upstart jobs. When called as lread, it cats each file from the argument list to stdout, while placing a shared lock on them. When called as lwrite, it places an exclusive lock on the file and cat stdin to it.
<soc> hi I just visited upstart.ubuntu.com, the site is nice but I couldn't find information about the projects status ...
<soc> the thing is, upstart should replace cron, atd, anacron, init, telinit, udev, acpid, apmd, ifupdown, module-init-tools, inetd, xinetd, update-rc.d, etc.init.d, /etc/rc*d and some things I have probably forgotten
<soc> wouldn't it be nice to have a table with wo columns, one for the service it should replace and one for the status (maybe green, yellow, red)?
<soc> that would be nice for visitors who are interested but not so experienced to grab the svn source, compile it and find it out
<soc> someone here, who manages the upstart site/wki?
<soc> it's done on http://www.gnome.org/projects/tracker/
<soc> on th first look, the visitor will see what already works and what not, so he can decide if the project is relevant for him ...
<soc> someone here?
<soc> or am I talking to /dev/null?
<soc> :-)+
<soc> damn ... no one listening?
#upstart 2007-03-13
* netjoined: irc.freenode.net -> zelazny.freenode.net
<_ion> Note to self: when Keybuk returns, ask him whether it would be a reasonable idea to integrate something like http://irccrew.org/~cras/security/data-stack.html to libnih.
<Keybuk> yay
<Keybuk> we have little upstart icons on beta lp now
<mbiebl> url?
<Keybuk> mbiebl: you have to be a member of the launchpad beta-testers group to see it
<mbiebl> ah, ok 
<Keybuk> http://quest.netsplit.com/~scott/beta-lp-bugs.png
<Keybuk> ("private screenshot") :p
<mbiebl> just read the note ;-)
* pkt is away:    .
<_ion> The launchpad beta is cool.
<_ion> Btw,
<_ion> ti124335 < _ion> Note to self: when Keybuk returns, ask him whether it would be a reasonable idea to integrate something like  http://irccrew.org/~cras/security/data-stack.html to libnih.
<Keybuk> will look at that in a sec
<_ion> last black
<Keybuk> eh?
<_ion> Forgot the / from '/last black'. :-)
<Keybuk> heh
<asdaf> does anybody knows a reason why upstart can't create @/com/ubuntu/upstart socket?
<asdaf> *know
<asdaf> release 0.3.5
<Keybuk> almost certainly because it's already running?
<Keybuk> what's the error?
<Keybuk> it won't just say that it can't create it, it'll tell you why it couldn't create it
<asdaf> i noticed it because initctl fails connecting to it
<asdaf> it doesn't show in /proc/net/unix
<Keybuk> then you're not running upstart
<Keybuk> upstart would've failed to even boot
<Keybuk> lsof /dev/initctl
<asdaf> i don't have lsof (it's an embedded) but looking at /proc/1/fd dir there is no reference to a unix socket
<asdaf> same system on another box works fine
<asdaf> i'm wondering what can make the difference
<Keybuk> can you give me the ls -l of /proc/1/fd
<Keybuk> _ion: doesn't seem to give anything that nih_alloc doesn't already do?
<Keybuk> frame = nih_alloc (NULL, 0);
<Keybuk>   /* alloc everything with frame instead of NULL */
<Keybuk> nih_free (frame)
<Keybuk> unless he's combining it with a slab allocator, of course
<asdaf> Keybuk, pvt?
<_ion> keybuk: You'd need to pass the frame variable to function calls etc.
<Keybuk> asdaf: sure
<Keybuk> _ion: true
<Keybuk> it'd make the whole "allocate temporary stuff that we throw away again" thing easier
<Keybuk> that's a little cumbersome with nih_alloc
<_ion> keybuk: I haven't actually read his implementation, but he says "No memory fragmentation".
<Keybuk> *shrug* probably a slab allocator to return the things you ask for
<Keybuk> (that's where you allocate memory in pages at a time, and split it into managed chunks)
<_ion> Yeah
<_ion> He also says "FAST, most of the time allocating memory mean only updating a couple of pointers and integers. Freeing the memory all at once also is a fast operation", which sounds like slab, too.
<AlexExtreme> mmm
<AlexExtreme> nice icons on launchpad beta :)
<Keybuk> yeah
* AlexExtreme likes the launchpad beta
<AlexExtreme> hmm, i think i made a mistake with my job files... i installed the ones that I wrote on my host system, it didn't quite work ;)
<Keybuk> oops
* asdaf is away: I'm busy
<_ion> Sigh
<_ion> keybuk: Btw, what might the syntax of the scripting language built around syscalls you've envisioned look like?
<_ion> Hahaha, the comment in the latest libnih commit :-D
<Keybuk> probably a bit like Perl. now I think more <g>
<Keybuk> need to work out what's in the box for 0.3.9 I guess
<Keybuk> http://www-128.ibm.com/developerworks/library/l-boot-faster/index.html
<AlexExtreme> nice#
<AlexExtreme> *nice
#upstart 2007-03-14
* asdaf is back (gone 15:46:02)
<_ion> Sigh.
<_ion> keybuk: Btw, how about LUA for an alternative to sh in jobs? liblua* are so small that moving them to /lib shouldn't be a problem.
<_ion> It's a quite nice language.
<Keybuk> it's a nice syntax, but it's a pain since you have to code every single damned function primitive yourself <g>
<_ion> keybuk: Btw, are you familiar with the dovecot library?
<_ion> keybuk: cvs -d :pserver:anonymous@dovecot.org:/home/cvs co dovecot, see dovecot/src/lib
<Keybuk> no?
<Keybuk> I'm familiar with dovecot, obviously
<Keybuk> most C programs end up acquiring their own "standard library"
<Keybuk> or they use another like glib wholesale
<_ion> The library is somewhat similar to e.g. libnih and glib. The interesting thing is the data stack / mempool stuff.
<_ion> (It's not dovecot-specific, although it has been developed with dovecot. At least icecapd+irssi2 use it in addition to dovecot.)
<Keybuk> yeah, I do have a long-running nih todo about temporary memory
<Keybuk> upstart does use it to a small degree (mostly in message processing)
<Keybuk> I'd somewhat like it to be compatible with nih_alloc though, as being able to steal temporary data is useful
* Keybuk has also been a little concerned about the memory usage of nih_alloc
<Keybuk> the overhead for a job definition is quite high
<Keybuk> I have a vague thought about it though
<Keybuk> allocations with no parents could have a certain minimum size, say one page
<Keybuk> if child allocations to those could be fitted into that page, they would
<Keybuk> I'm not sure how to structure that to reduce overhead though
<_ion> keybuk: Jobs need to be able to *programmatically* create new jobs. :-)
<_ion> A pseudo-code example for the mount job:
<_ion> start on startup
<_ion> start ruby  # Not that Ruby is ever going to be an Upstart scripting language
<_ion>   # ...
<_ion>   mountpoints.each do |mountpoint|
<_ion>     deps = mountpoint_deps mountpoint
<_ion>     job = Upstart::Job.new "mount-" + mountpoint.sanitize
<_ion>     job.on job.and(deps.map {|dep| "filesystem-mounted " + dep })
<_ion>     job.start :script, 'mount $1; emit filesystem-mounted $1'
<_ion>   end
<_ion> end lua
<_ion> I didn't think about race conditions etc, though. It's just a quick example.
<_ion> I also forgot to add 'and block-device-added ...' to the 'on' list.
<Keybuk> start ruby, but end lua ? :p
<Keybuk> err
<Keybuk> how is that different from just emitting an event with the requisite details?
<_ion> Hah. I first wrote 'start lua, end lua' but then thought i'd use ruby instead. Forgot to change the end line. :-)
<Keybuk> the trouble with trying to define a job like that is ... what happens if the event happens before the job is registered? :p
<_ion> Yes, filesystem-mounted events must not happen before that's processed. Perhaps make a special pre-startup event for metajobs, and process other job after they have done their thing.
<_ion> It would seem cleanest if the mount job computed the prerequisite mountpoints instead of the fsck job that emits the event the mount jobs act on.
* Keybuk isn't convinced
<_ion> Another approach: http://soijabanaani.net/tmp/upstart-mount
<Lrrr_> hello, how do I make upstart reread it config files?
<_ion> He was in a hurry.
#upstart 2007-03-15
<_ion> Hi Keybuk
<Keybuk> hey
<_ion> Did you receive my MemoServ message?
<Keybuk> just looking at it now
<Keybuk> _ion: I think my main aversion here is a strong desire that upstart should take care of the prereqs for you
<_ion> I was thinking of programmatic metajobs exactly for that reason.
<_ion> So the metajob would parse fstab and generate a job for each mountpoint.
<_ion> How about the idea about locking(1) which would be used to run fsck? Should upstart handle that part also?
<florin> hi everyone
<Keybuk> hi
<_ion> Hi
<florin> i'm a Lunar Linux developer. I've managed to install upstart on my system. So far it work just fine with the old sysvinit scripts. I'm learning now how to create event based init scripts. You've done a good job.
<Keybuk> thanks :)
<florin> yw
<Keybuk> http://upstart.ubuntu.com/
<Keybuk> ^ added quite a bit more
<_ion> Cool
<Keybuk> hopefully that'll address a few of the usual complaints/comments
<_ion> I moved the contents of the earlier link to http://johan.kiviniemi.name/blag/2007/03/15/upstart-and-mounting-partitions/
<Keybuk> cool
<Keybuk> btw, have definitely decided to accept delayed watch
<_ion> Nice :-)
<Keybuk> and am going to integrate it directly into nih_watch since it's such a common use
<_ion> Yeah. If someone doesn't want it, she can simply put a zero for the delay.
<Keybuk> exactly
<_ion> Perhaps the link bar at the top of the Upstart website should be emphasized somehow: for example, a light gray background color, or bold text.
<_ion> keybuk: It would also be really, really nice if the link to the currently open page didn't disappear from the bar.
<Keybuk> heh
* Keybuk has a fiddle
<_ion> A literal fiddle, or a figure of speech i'm not familiar with? :-)
<Keybuk> the problem with having a background colour is that it doesn't cover the image
<Keybuk> cf.
<Keybuk> http://quest.netsplit.com/~scott/upstart/
<Keybuk> see how the boxes don't go round the images
<_ion> In fact, that might be a nice effect. :-)
<_ion> Perhaps add a bit of padding to the left and to the right, but the image being higher than the background color actually looks nice IMO.
<Keybuk> check now
<_ion> Really nice otherwise, but you'll need to add an invisible border or some padding to the non-hover style, otherwise the links jump when being hovered upon.
<_ion> They seem to jump two pixels, i.e. the width of the border when hovered.
<_ion> Really nice!
<Keybuk> that seems to work
* Keybuk is still waiting for the launchpad icon :-/
<_ion> The agreement not to publish screenshots also means you can't grab the favicon from beta.launchpad.net? :-)
<cwillu> ping
<_ion> Network unreachable.
<cwillu> :/
<cwillu> respawn \n script \n Xorg <blah blah blah> \n end script
<cwillu> will that do what I hope it'll do?
<cwillu> and do it in a manner that doesn't make you shudder too much?
<_ion> If you only have a single line in the script, you can replace it with 'exec Xorg ...'
<_ion> I'd expect that to work, but go ahead and try for yourself. :-)
<cwillu> but other than that, I should be able to have another job "on start <above script's name>", and it'll work with the above?
<_ion> Exactly what do you want to achieve? What would that another job do?
<cwillu> I need an extremely minimal x session, I have no desire to involve gdm or xdm or whatnot
<cwillu> I want another job to launch an xwindow, with respawn set on that as well
<_ion> You might want to use xinit.
<cwillu> although there is the somewhat ugly race condition of waiting for Xorg to come up first
<cwillu> hmm
* cwillu man xinit
<cwillu> that looks reasonably, thanks
<Keybuk> _ion: the favicon is tool small; the lp designer promised me a tango-style 24x24 icon today
<Keybuk> but went to bed
<Keybuk> lol
<_ion> Hehe
<mdales> are there any obvious things wrong with using upstart on a live CD? I'm using an edgy live CD that I've added some packages too, and generated some new scripts in /etc/event.d, but when I try to start them I get "start: Unknown job: vncsession"
<Keybuk> yeah
<Keybuk> the inotify stuff doesn't work across UnionFS
<Keybuk> it ends up watching the read-only directory underneath
<mdales> ah
<mdales> bollocks 
<mdales> is there any way around this?
<mdales> other than adding a level of indirection
<Keybuk> not known
<mdales> I can put static scripts in event.d on the CD that point to generated scripts I assume
<_ion> Perhaps upstart should reread the job files using nih_walk on SIGHUP.
<Keybuk> yeah it should
<Keybuk> I have a whole bunch of stuff like that to fix
<Keybuk> the signal handlers should be set to a generically useful function
<Keybuk> and there should also be control messages to do the same thing
<Keybuk> e.g. re-exec, reload jobs, pause/unpause the event queue
<Keybuk> the main problem with HUP is noticing deletes <g>
<_ion> previous = [foo, bar, baz] ; walk(CONFIG_DIR)  {|file| previous -= file; process file }; previous.each {|job| delete job }
<Keybuk> not quite that simple, since you may have deleted jobs in the hash still from last time <g>
<Keybuk> (and needs to cope with multiple config directories, and control-registered jobs in the future)
<_ion> Yeah
<Keybuk> yay my copious TODO list
#upstart 2007-03-16
<sadleder> Keybuk: hi, when and how will upstart jobs be integrated in feisty?
<Keybuk> sadleder: there will be an alternate repository around the time feisty releases
<sadleder> Keybuk: will the jobs be in a single package, or in their respective packages?
<Keybuk> respective packages
<sadleder> Keybuk: ah, ok, thx.
<sadleder> Keybuk: btw, your work on upstart is just formidable
<sadleder> Keybuk: so users will see those when feisty releases, but not before?
<Keybuk> yeah, basically we missed the feisty feature freeze for it -- and want to get it right instead
<Keybuk> "around feisty release time" is just a guess
<sadleder> Keybuk: and what about testing?
<Keybuk> I don't follow?
<Keybuk> anyone who uses the repository will be testing them :)
<sadleder> Keybuk: hmm, ok, does that mean, they won't go into feisty, but rather into feisty+1?
<Keybuk> right
<Keybuk> exactluy
<sadleder> ok, now i understand
<sadleder> so feisty will just have upstart-compat-sysv
<Keybuk> yes
<_ion> Good ideas from AlexExtreme at the mailing list.
* Keybuk gives up decoding the cherry data sheets
<_ion> Matthias Ulrichs' idea of list-style variables would be nice.
<_ion> cherry?
<Keybuk> I can find a G80-3000LSCGB-0, which is only one letter out from my current G80-3000LSMGB-0
<Keybuk> and appears to have the right  description
<Keybuk> keyboards
<fatzeus> hi, i'm trying to install upstart on gentoo
<Keybuk> fatzeus: hi
<fatzeus> hi
<fatzeus> i've some connection trouble...
<fatzeus> anyway..
<fatzeus> i see that there are some sample scrits
<fatzeus> that you have to modify to fit your distro configuration
<fatzeus> i've almost done...i think 
<fatzeus> but in the inittab file i've also something like this:
<fatzeus> rc::bootwait:/sbin/rc boot
<fatzeus> but with the examples i don't see any like this
<fatzeus> for example the si::sysinit:/sbin/rc sysinit in my inittab file
<fatzeus> i think is rcS
<fatzeus> ?
<fatzeus> maybe add rc boot into the rcS file after rc sysiniti??
<Keybuk> no idea, I'm not familar with Gentoo I'm afraid
<Keybuk> certainly each line in the /etc/inittab corresponds to one file in /etc/event.d
<fatzeus> yes...rc:bootwait
<Keybuk> bootwait and sysinit are different I guess
<fatzeus> is also mentioned in the man
<fatzeus> man /etc/inittab
<fatzeus> Further system initialization, brings up the boot runlevel
<Keybuk> after rcS, before rc-default I guess
<fatzeus> it doesn't say a lot...
<Keybuk> so make a new event.d file, exec /sbin/rc bin, start on stopped rcS; and change the rc-default to be start on stopped $new_file
<fatzeus> ok...thank i'll try this way
<fatzeus> if i see that it's not the correct order
<fatzeus> i've just to change after/before
<mbiebl> fatzeus: have you replaced /sbin/init or did you install it to another location?
<fatzeus> i placed it in /opt/upstart
<fatzeus> as suggested...
<mbiebl> good ;-)
<fatzeus> uhm...
<fatzeus> what does stop on means?
<fatzeus> i'll try reboot...
<Keybuk> _ion: watch delayed is merged into my branch now, and have also merged it into watch.c directly
<Keybuk> just doing some tests, etc. before I push
<_ion> Great
<Keybuk> thanks for your work on that, it should prove very useful
<Keybuk> sorry it took me a while to get to it :p
<_ion> No problem at all
<Keybuk> _ion: another way of looking at the whole stdint thing
<Keybuk> the C standard already guarantees type sizes
<Keybuk> char is "at least 8 bytes"
<Keybuk> int is "at least 16 bytes"
<Keybuk> long is "at least 32 bytes"
<Keybuk> and long long is "at least 64 bytes"
<Keybuk> so you don't need the stdint types unless you want an "exactly" restriction
<_ion> Right
<Keybuk> the other fun with ... applied to int8_t
<Keybuk> it gets promoted to an ordinary int, which might 32 or 64-bytes :p
<Keybuk> (or even 16-bytes on 286s)
<_ion> Heh
<concept10> hello all.  The above link (getting started is wrong)
<Keybuk> oh yeah] 
<Keybuk> heh
* ..[topic/#upstart:Keybuk] : Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
* Keybuk trims the topic
<Keybuk> since all those are now linked on the website
<concept10> Keybuk, what would be the equivalent to /etc/inittab?
<Keybuk> the /etc/event.d directory
<concept10> okay, I know that, but Im looking for the first file or script thats run
<mbiebl> All that have a "start on startup"
<mbiebl> startup is the first signal that upstart emits.
<mbiebl> Keybuk: question about libnih
<Keybuk> shoot
<mbiebl> why are the m4 macros installed to /usr/share.
<Keybuk> /usr/share/aclocal ?
<mbiebl> afaik they are only needed for compiling libnih
<mbiebl> Not for applications using libnih
<Keybuk> compiler.m4, etc.?
<mbiebl> yes.
<Keybuk> they're useful for any application
<Keybuk> so they're kind of an autoconf macro library as well
<mbiebl> It's just, that misc is a very generic name ;-)
<Keybuk> heh
<Keybuk> fair point
<Keybuk> they should be in a subdir or something, dunno if aclocal copes with that
<Keybuk> certainly there's no reason for a package to distribute them yet
<Keybuk> bbl
#upstart 2007-03-17
<r4nge> i dont quite understand the re-read.. i removed an entry from event.d and then terminated the process and it just restarts
<AlexExtreme> \o/
<AlexExtreme> My upstart-native jobs worked
<_ion> \/
<AlexExtreme> hmm, when i say worked... they booted ok, then when i tried to shutdown, they broke badly :)
<AlexExtreme> http://members.optusnet.com.au/clausen/ideas/upstart/index.html << does that have any relationship with the upstart we have now?
<_ion> Probably not. :-)
<_ion> I'll try to get the sysblock program done some day.
<_ion> So you can do 'sysblock --physdev /dev/mapper/vg-root' and receive '/sys/block/sda /sys/block/sdb'
<_ion> Or 'sysblock --dev --physdev /dev/sda1' and receive '/dev/sda' etc.
<AlexExtreme> cool
<_ion> And also the 'locking' program, so you can e.g. start 'locking sda sdb -- fsck /dev/mapper/vg-root' and 'locking sda -- fsck /dev/sda2' etc. simultaneously and have locking(1) take care of not running 
<_ion> multiple fsck instances on a single physical device.
<AlexExtreme> cool
<_ion> The idea on the mailing list about having the fsck job do something like 'initctl variable append filesystems-checked /dev/mapper/vg-root', 'initctl variable append filesystems-checked /dev/sda2' and the mount job do something like 'initctl variable list filesystems-checked | while read filesystem; ...' and 'initctl variable remove filesystems-checked /dev/sda1' etc. is really nice IMO.
<AlexExtreme> :)
<AlexExtreme> i might try to make a patch to do that sometime
<_ion> The ordering of the names in the list shouldn't matter, and there shouldn't be any duplicate entries.
<_ion> That is, duplicate entries should be ignored.
<AlexExtreme> yes
<concept10> Hello all.  Quick question, is bootchart compatible with upstart?
<_ion> I don't see why not.
<AlexExtreme> concept10, yes, i've used it with it
<concept10> _ion, AlexExtreme thanks guys
<AlexExtreme> mbiebl, do the upstart packages in experimental work on sarge or do i need unstable?
<mbiebl> AlexExtreme: You'd have to recompile them.
<AlexExtreme> damn
<AlexExtreme> oh well
<mbiebl> I'm also not sure if the 2.6 kernel in sarge is recent enough and has inotify support.
* AlexExtreme compiled his own kernel
<mbiebl> AlexExtreme: recompiling is simple then
<AlexExtreme> meh, probably the glibc and gcc in sarge are too old
<mbiebl> hm, right.
<AlexExtreme> one day etch will be out and it'll probably work there :)
<AlexExtreme> i would upgrade to testing anyway if my debian machine wasn't a server
<mbiebl> he
<AlexExtreme> damn
<AlexExtreme> i keep forgetting to add upstart-devel to CC when replying to the list
* AlexExtreme should use thunderbird's reply all button
<mbiebl> AlexExtreme: http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension
#upstart 2007-03-18
<sanityx> Anybody here?
<sanityx> How do I control what services run at boot with upstart?
<sanityx> This channel is ALIVE with activity.
<AlexExtreme> hmm... if i have a job with, for example, both 'stop on foobar 0' and 'stop on foobar 1', i know I can get the actual event name, foobar, in the scripts with the UPSTART_EVENT variable, but how can I get the arguments to the foobar event, in this case 0 or 1?
* AlexExtreme hopes that made sense
<Keybuk> $1, $2, $3
<AlexExtreme> ah
<AlexExtreme> ok
<AlexExtreme> thanks
<Keybuk> this works for exec too, through an evil trick
<AlexExtreme> yeah
<Keybuk> I have yet to work out the pattern by which the scrap van comes around our street
<Keybuk> SETI could analyse the periods between visits and discover new and unhidden depths in the complexity of the universe
<AlexExtreme> :p
<_ion> They're sending you secret messages through the periods between visits.
<_ion> You're not schizophrenic if they're really sending messages to you.
<Keybuk> that's paranoid
<Keybuk> schizophrenic is when you send messages to yourself
<_ion> I was finally able to order a decent monitor to replace these blussy CRTs. 
<_ion> blurry
<AlexExtreme> _ion, LCD? or another CRT?
<_ion> Samsung 226BW, a 22" widescreen flat monitor.
<AlexExtreme> nice
<AlexExtreme> this LCD has managed to get the outline of my top gnome panel etched into the screen...
<_ion> :-)
<AlexExtreme> shows how much I use it :p
<AlexExtreme> btw
<AlexExtreme> if I do this in my job for system-tools-backends:
<AlexExtreme> exec STB_NO_DAEMON="y" /usr/bin/system-tools-backends
<AlexExtreme> will upstart interpret that correctly by passing it to a shell and behave as you'd expect it to?
<_ion> exec env STB_NO_DAEMON="y" /usr/bin/system-tools-backends
<_ion> Even better:
<_ion> env STB_NO_DAEMON=y
<_ion> exec /usr/bin/system-tools-backends
<AlexExtreme> ah
<AlexExtreme> cool
<mbiebl> Keybuk: I think upstarts sysv compat utils are not compatible enough ;-) 
<mbiebl> I noticed that while adopting upstart for Gentoo.
<mbiebl> When in runlevel 0 or 6, reboot/halt/poweroff when called without -f, should *not* call shutdown.
<mbiebl> Other distros I checked do not have a "-f" in the final halt/reboot call.
* AlexExtreme noticed that about 5 minutes ago ;)
<mbiebl> I think it would also be nice, if the links would be the same as with sysvinit
<mbiebl> poweroff -> halt, reboot -> halt
<mbiebl> and not halt->reboot, poweroff -> reboot
<mbiebl> But that's just nitpicking.
<mbiebl> Besides that it was astonishingly painless to get upstart running on Gentoo ;-)
<AlexExtreme> Yeah, but then it'll be astonishingly painful to actually write upstart-native jobs for it ;)
<mbiebl> yeah, that is a different kettle of fish
<AlexExtreme> btw, i've got some new upstart-native jobs for frugalware here: http://ftp.frugalware.org/pub/other/upstart-jobs/upstart-jobs/etc/event.d/
<AlexExtreme> i haven't actually tested them yet though, i'm setting up a virtual machine because i don't want to kill my main machine :)
<mbiebl> hehe
<AlexExtreme> they're kinda ugly atm, i'm sure some stuff could be done better, and there's no event based networking or mounting yet
<mbiebl> when do you expect the first frugalware release with a fully upstart-native boot?
<AlexExtreme> 0.7 stable will definitely have it, it won't get into 0.6 because that's gonna be released in 4 days
<AlexExtreme> i'll try to get it into the development repo quite early in 0.7's development
<mbiebl> cool. what is your strategy for frugalware: will you dump sysvinit completely and go upstart only?
<mbiebl> Or will you ship both?
<AlexExtreme> just upstart
<mbiebl> Yeah, that makes it easier...
<AlexExtreme> but we'll leave the sysv compat stuff there for proprietry apps which provide their own init script like vmware
<mbiebl> Keybuk: about the "-f" behaviour of the compat tools
<mbiebl> Should I file a bug report?
<AlexExtreme> probably a good idea, then there's no reason for him to forget it ;)
<mbiebl> I just wanted to get his opinion first, but then it seems he is not around atm.
<mbiebl> AlexExtreme: Have you also written the udev rules already?
<AlexExtreme> http://ftp.frugalware.org/pub/other/upstart-jobs/upstart-jobs/etc/udev/rules.d/85-upstart.rules
<AlexExtreme> that's a base set of rules, maybe more could be added later
<AlexExtreme> Yep, he's not around ;)
<mbiebl> *grin*
* AlexExtreme prays and types reboot into the VM
<AlexExtreme> it seems my prayers have been answered. it works :)
<mbiebl> way cool!
<AlexUpstart> nothing seems to have gone wrong so far, although hald is being a little more verbose than I would like ;)
<AlexUpstart> http://frugalware.org/paste/955
* AlexExtreme hopes shutting down will work now
<AlexExtreme> awesome... it worked :)
<mbiebl> nice
#upstart 2008-03-10
<warren> sadmac, ping
<warren> sadmac, so upstart in fedora 9 is ignoring /etc/inittab.  Where is it defined to run mingetty on VT1 through VT7?
<sadmac> warren: upstart should ignore /etc/inittab . Check out /etc/event.d/tty*
<warren> ok perfect, exactly what I needed.
<warren> sadmac, btw, do you know how to run a root shell from /etc/event.d/tty* files?
<warren> sadmac, i've been trying things like /usr/bin/openvt -c # -w -l /bin/bash
<warren> that sort of works
<sadmac> warren: thought of /bin/bash < /dev/tty# > /dev/tty# ?? It isn't pretty, but...
<warren> oh
<warren> sadmac, I tried a variation of that before, had no job control
<warren> sadmac,  is the TTY number available as a variable or something to the scripts of /etc/event.d/?
<sadmac> warren: don't think so... not really applicable in most cases.
<warren> sadmac, if a file in /etc/event.d/ is blanked out does it become a no op without breaking anything?
<warren> sadmac, we have those files as %config(noreplace) in our event-compat-sysv package, which allows them to be edited and rpm upgrade wont blow away changes.  however I can't delete files from there or rpm upgrade will restore it.
<sadmac> warren: just about any syntax error causes the file to become a no-op :) so yeah
<sadmac> Keybuk: around?
<warren> sadmac, it will complain about it being empty?
<sadmac> warren: no. It fails silently
<warren> ok
<warren> good enough
<warren> sadmac, how does upstart know which runlevel to use by default?
<warren> sadmac, 3 text mode 5 graphics
<sadmac> warren: it appears we're still grepping that out of /etc/inittab (wanted to change that actually)
<warren> sadmac, could you let me know when you change that?  I have to adjust it elsewhere too.
<sadmac> warren: I'll tell you if/when we do.
<warren> thanks
<warren> sadmac, which distro are you affiliated with?
<sadmac> warren: fedora
<warren> sadmac, oh, just wondering because you aren't hanging out in #fedora-devel
<sadmac> warren: ...hmm...it seems I'm not
<warren> sadmac, we might also want to add something to our shipping /etc/inittab to tell people "not here!"
<warren> sadmac, I wonder how many things parsed /etc/inittab and would be broken
<sadmac> warren: that must happen. If we do get the default runlevel out of there we can just blow that file away (then start fixing things as they break)
<warren> sadmac, write a fuse filesystem module to provide a /etc/inittab that is put together in real-time based upon /etc/event.d? =)
<sadmac> warren: hell yeah
<warren> sadmac, sorry, I just said that bad idea for shock value.
<sadmac> warren: no no. thats the way to go. We can do it in java too.
<sadmac> warren: and we'll offer the ability to cluster your inittab processing while we're at it. And encryption,
<warren> oh god
<warren> you're worse than me
<sadmac> :)
<Keybuk> sadmac: yup, vaguely around (little busy today)
<sadmac_> Keybuk: what is the profiles implementation plan looking like (if any)? My thought would be to send the "startup" event only to jobs listed in the active profile
<Keybuk> there's a bzr branch for that I think
<Keybuk> http://bazaar.launchpad.net/~alex-extreme2/upstart/profiles
<Keybuk> (bzr merge --preview to see the resulting diff)
<Keybuk> it looks like it simply ignores all start events for disabled jobs
<Keybuk> which is the right thing to do I think
<sadmac_> Keybuk: sounds good
<AlexExtreme> that branch is horribly outdated, however ;)
<Keybuk> well, yes ;)
<sadmac_> AlexExtreme: so what is it that makes you more extreme than other Alexes?
<sadmac_> (Alexi?)
<AlexExtreme> heh, well. I've been meaning to change my nick sometime. I registered this nick *ages* ago when I first used IRC, and since Alex was taken I wanted something to stick on the end of it, "Extreme" was the first word I saw (was on a magazine on my desk IIRC), so it kinda stuck and now I use it for lots of things
<Keybuk> heh, nobody can ever change their nickname once it's stuck ;)
<ion_> sadmac: What is it that makes you sadder than other macs? :-)
 * AlexExtreme points at *the* Sad Mac icon
<sadmac_> ion_: my first person shooter name was sAdIsTiCmAcHiNe. sadmac was the inevitable shortening everyone stuck with, and was more polite.
<sadmac_> now and again I go by madsac for a bit.
<AlexExtreme> I try to use Alex where possible now
<sadmac_> Keybuk: for that matter, what's a keybuk?
<ion_> keybuk.com from MS-DOS
<sadmac_> ah.
<sadmac_> what's different on a UK keyboard? Apart from easier access to the GBP symbol?
<Keybuk> UK keyboard didn't get some of the changes the US keyboard did
<Keybuk> so is still in ASCII order
<Keybuk> our shift-number punctuation is !"$%^&*()
<Keybuk> at some point, US keyboards swapped " and @ around
<Keybuk> we have an extra key
<Keybuk> and a larger return key
<sadmac_> Heh. Wikipedia labels the Super key as the "win key"
<sadmac_> "Press here to win"
 * AlexExtreme despises the fact that keyboard manufacturers put a windows logo on there
<sadmac_> AlexExtreme: You can get keyboards without it. My boss' has a diamond.
<AlexExtreme> yeah, but most have it. I've seen ones with linux penguins (made by Cherry IIRC)
<Keybuk> the key didn't exist at all until it was the Windows keys
<sadmac_> AlexExtreme: There's this solution http://www.thinkgeek.com/computing/input/8396/
<AlexExtreme> hah, yes
<sadmac_> to class!
<ion_> http://johan.kiviniemi.name/pictures/keyboard/keyboard-01/original
<Keybuk> I'm surprised Cherry don't just sell the individual keys
<Keybuk> but I guess there's not much profit in that
<sadmac_> Keybuk: is UPSTART_EVENT set in post_stop?
<sadmac_> Keybuk: looks like it is from my test
<sadmac_> Md: what does your quit message mean?
<Md> I have many
<sadmac_> Md: "odium turbae sanabit solitudo, taedium solitudinis turba"
#upstart 2008-03-11
<Keybuk> sadmac_: yes
<Keybuk> though in 0.3.x it will probably contain the event that stopped the job
<Keybuk> whereas in trunk, UPSTART_EVENTS will contain the events that originally started it
<keesj> Hi
<Keybuk> hi
<keesj> The chance I wil use upstart are growing every day :p
<keesj> I am now looking into the kernel->upstart communication
<keesj> special I am looking at the udev from the replacement-initscripts http://paste-it.net/7162/raw/
<keesj> that script has a "emits block-device-added block-device-removed" section
<keesj> what it that good for?
<Keybuk> "emits" is just a documentation stanza
<Keybuk> you'd use it in the job definitions of services that are known to emit their own events
<Keybuk> and that way other frontend tools can draw pretty dependency graphs using things like dotty
<keesj> sexy :p
<Keybuk> it's not actually used by Upstart in any way, other than being available as a property
<Keybuk> the theory there is that that distribution would ship udev rules that looked something like:
<Keybuk>   SUBSYSTEM=="block", ACTION=="add", RUN+="/sbin/initctl emit block-device-added DEVPATH"
<Keybuk>   SUBSYSTEM=="block", ACTION=="remove", RUN+="/sbin/initctl emit block-device-removed DEVPATH"
<Keybuk>   SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/initctl emit network-device-added INTERFACE"
<Keybuk>   SUBSYSTEM=="net", ACTION=="remove", RUN+="/sbin/initctl emit network-device-removed INTERFACE"
<Keybuk> etc.
<Keybuk> alternately we may want an upstart-addon-udev or something so we could have a generic RUN+="socket:/com/ubuntu/upstart/udev" at the end, and let the addon daemon turn those into events
<Keybuk> OR we might just patch udev directly to emit events into upstart
<keesj> my system does not use udev, i currently use <linux/netlink.h> to recieve NETLINK_KOBJECT_UEVENT events
<keesj> I could just create a mini app that gets started and emits the kernel uevent
<keesj> hmm I will look into it 
<Keybuk> right
<Keybuk> you could have a little daemon to listen on the netlink socket and inject into upstart
<keesj> I do have the same kind of problems that are solved by udev , being that if a device get plugged before the daemon is started I will never know about
<keesj> I then have to write custom code to look at the status .
<Keybuk> why not just write to the uevent files like udev does?
<Keybuk> for each object under /sys that a uevent was originally emitted for, there will be a uevent file
<Keybuk> write "add" (no \0, no \n, etc.) to that, and the kernel will resend it
<keesj> Thanks for the tip , I will have to look into how that works!
<Keybuk> ion_: interesting thought of the day
<Keybuk> all of the dbus_bus_ calls block
<ion_> keybuk: Is that a problem?
<Keybuk> I'm not sure
<Keybuk> the fact that dbus_bus_get() can never return worries me enough :p
<ion_> Heh
<Keybuk> I guess it depends at what level of blocking we have to worry about in Upstart
<Keybuk> in some senses, blocking is actually not necessarily bad
<Keybuk> since it reduces system load
<Keybuk> e.g. upstart blocks while it sets up a process, even though that's happening the child
<Keybuk> and doesn't move onto the next until exec() completes
<Keybuk> so arguably, after starting dbus, blocking to connect to it and say Hello isn't too bad
<ion_> Yep...
<ion_> Donât they have a separate DBus (client) implementation in C#? Perhaps someone should NIH a DBus implementation that doesnât suck in C. ;-)
<Keybuk> ndesk-dbus
<Keybuk> the C API isn't really that bad
<Keybuk> the main problem is just figuring out how to dispatch methods
<keesj> ion_: that would be great
<Amaranth> @btlogin
<Amaranth> err
#upstart 2008-03-12
<telexicon> if i wanted to port a sysvinit script to upstart, is there a page documenting how to do this?
<keesj> hi
<keesj> telexicon: does the script do the stantard start/stop/restart stuff?
<telexicon> yes
<keesj> I am pretty new to this but what I do is write a very simple job "start on start-myservice , stop on stop-myservice" and put the exec in there
<keesj> let me find a simple sample
<telexicon> it'd be nice if there were a few non-trivial examples on the wiki at least
<telexicon> for making scripts for daemons or something
<keesj> http://paste-it.net/7198/raw/
<keesj> after that I "emit start-myservice"
<keesj> but I agree that there is room for improvement in the docs and specialy examples
<keesj> I would really like a non sysv example.
<telexicon> ah ok
<telexicon> well id like to see converting a standard sysv init script to an equivalent upstart form
<keesj> telexicon: the thing really is that the guts of sysv are in the file called inittab , there are the read progams that get started and stopped at a special runlevel
<keesj> the "rc" scripts are really implemented differently by every distro.
<telexicon> ok
<telexicon> but ubuntu has done away with inittab
<keesj> telexicon: yes ,while ubuntu uses upstart it uses a "sysv" like implmentations that emulates the old system
<keesj> if you have a ubuntu system running you can look in /etc/event.d/ and grep for inittab to see the "hacks"
<keesj> I am implmenting a state machine based system atm(something like the runlevels but with more possible transitions between the levels)
<keesj> in other words i am experimenting :PO
<telexicon> ah
<keesj> I think that what I would like is to have more conventions something like  /etc/upstart/services/[myservice]
<keesj> and that by default I can call emit myservice-start
<keesj> everything is a job in upstart therms. perhaps it is better to wait for somebody with more knowlegde 
<keesj> OK , I have my next interesting problem :p
<keesj> I  have an init script that starts two commands in the background and I want to convert that one to "one or tree" jobs
<keesj> I really wonder how...
<keesj> is that /etc/upstart/services/[myservice]
<keesj> a good idea anyway?
<keesj> or can a jobs have multiple exec's?
<Keybuk> err
<Keybuk> I'm not sure what you mean
<Keybuk> can you be more verbose?
<keesj> I am trying to replace some old init scripts that performed start_a & start_b &  (if stop killall a killall b)
<keesj> I kinda like the idea that a service can consit of multiple processes (like the nfs/portmap hell)
<keesj> \
<Keybuk> shouldn't they be multiple services?
<Keybuk> what benefit would there be for having them as one
<Keybuk> you need portmap for things other than nfs, for example, so it needs a separate lifecycle
<keesj> perhaps , I like the idea of being able to star "something" and don't want to know that that something actualy consist of multiple parts
<Keybuk> right
<Keybuk> but that can be done with events, where each part starts something else?
<Keybuk> e.g. "start dbus" causes all dbus services like NM to start
<keesj> Yes , I think that that would be valid
<keesj> how about the /etc/upstart/services/[myservice] idea
<keesj> or actualy whould/should it be possible to have a "start script and a stop script?
<Keybuk> it is possible
<Keybuk> if you have /etc/event.d/foo
<Keybuk> then you can do "start foo" and "stop foo"
<keesj> "emit start foo"
<keesj> initctl start foo
<Keybuk> the latter, not the former
<Keybuk> emit is for making events
<Keybuk> start/stop are for starting and stopping jobs
<Keybuk> events can, of course, start and stop jobs
<Keybuk> but there's a more direct way
<keesj> the symlink trics also works  (BTW) so creating a symlink start to initctl
<keesj> Keybuk: I am holding my breath
<Keybuk> yes
<Keybuk> make install will do that for you
<keesj> hmm yes, I would love the split the even listener and the services, perhaps just giving them an extention is a good (and compatible) start
<keesj> FYI this is a part of my "change_handler/state_machine" http://paste-it.net/b33db14/raw/
<Keybuk> err, what does that do?
<Keybuk> --
<Keybuk> the way I'd do NFS/portmap would be to have an nfs-server service that starts the actual nfs server
<Keybuk> and in portmap have
<Keybuk>    start on starting nfs-servre
<Keybuk> so if you "start nfs-server" you get portmap
<Keybuk> --
 * Keybuk cannot figure out what the buggering bollocks a D-Bus VTable is
<ion_> Must be somehow related to D-Bus flicking you the Vs.
<Keybuk> it's a pointer which is typedef'd to a struct that appears to be internal to D-Bus
<Keybuk> *sigh*
<Keybuk> my test suite continues its long-standing tradition of finding bugs in other people's software
<Keybuk> dbus has this function that tells you whether data is remaining to be dispatched
<Keybuk> so assumedly you do:
<Keybuk>   while (dbus_connection_get_dispatch_status (conn) == DBUS_DISPATCH_DATA_REMAINS)
<Keybuk>           dbus_connection_dispatch (conn);
<Keybuk> except it turns out that data_remains can be true if there are unparsed bytes in there too
<Keybuk> so you'll be in a loop
<Keybuk> and since dispatch doesn't read(), it'll loop forever
<ion_> Heh
<Keybuk> if you only call dispatch() once, it will only dispatch one message, and will sit at select() for the next incoming message
<Keybuk> actually, I can shorten that still :)
<Keybuk> while (dbus_connection_dispatch (conn) != DBUS_DISPATCH_DATA_REMAINS)
<Keybuk>  ;
<Keybuk> that seems to cure the problem, in fact
<ion_> Nice
<keesj> Keybuk: the upstart code and nih looks very nice indeed.
<keesj> what kind of tests are you talking about (I also saw a post/news about it)
<Keybuk> look under the nih/tests and init/tests directories
<Keybuk> or just run "make check"
<keesj> thanks
<sadmac_> Keybuk: so, what was your final answer wrt the license for the example jobs?
<Keybuk> sadmac_: MIT/X11
<Keybuk> http://upstart.ubuntu.com/download/example-jobs/COPYING
<sadmac_> cool
<Keybuk> 203             if (! dbus_bus_register (conn, &error)) {
<Keybuk> (gdb) n
<Keybuk> 204                     nih_dbus_error_raise (&error);
<Keybuk> (gdb) p error.name
<Keybuk> $2 = 0x2b367a0d0be8 "org.freedesktop.DBus.Error.NoMemory"
<Keybuk> (gdb) p error.message
<Keybuk> $3 = 0x2b367a0d5600 "Not enough memory"
<Keybuk> weird
<Keybuk> oh
<Keybuk> just a silly error
<Keybuk> it seems it always adds watches and timeouts to the main loop
<Keybuk> even if you just want it to block
<Keybuk> (multi-thread safe I guess)
<sadmac_> Keybuk: using the dbus C api I see.
<sadmac_> Keybuk: good. DBus cannot become an excuse for GObject.
<Keybuk> indeed
<sadmac_> *shudder*
<Keybuk> GObject is wrong
<Keybuk> and the dbus bindings to it are actually just as weong
<Keybuk> quest nih% ./test_dbus 
<Keybuk> :1.183
<Keybuk> \m/
<Keybuk> I have achieved ... A CONNECTION!
<sadmac_> Keybuk: my initial attemt at writing a little /etc/rc replacement was previously done by someone else with GObject. It was 1/3 the way to working and probably had more code than upstart.
<Keybuk> :p
<sadmac_> whee
<AlexExtreme> last time I used GObject it made me want to kill every single glib developer
<AlexExtreme> in fact, i often get that feeling just using glib
<sadmac_> AlexExtreme: I often get that feeling just laying awake at night
<AlexExtreme> haha
<Keybuk> *** 
<Keybuk> *** #upstart is now known as #theglibfanclub
<sadmac_> glib (adj): showing little forethought or preparation : offhand
<sadmac_> "lacking depth and substance : superficial <glib solutions to knotty problems>"
<Keybuk> did you know that it's another word for castration?
<Keybuk> I feel the same way about both
<sadmac_> Keybuk: so you would rather become a woman than a GNOME developer?
<Keybuk> one is certainly more likely than the other
<Keybuk> I got told "I don't contribute enough" to be a GNOME developer
<sadmac_> Women tell me that all the time.
<AlexExtreme> I think my most hated thing about glib is the way that it implements libc functions itself and just sticks g_ in front, and typedefs g<type> to <type> for many types
<sadmac_> AlexExtreme: its a performance thing. G is a very fast character, because its right next to your pointer finger. So it makes the front of variables quicker.
<AlexExtreme> haha
<sadmac_> the front is the part in 'high' memory, and glib people believe in doing many things while high
<AlexExtreme> interesting
<AlexExtreme> my iPhone kernel paniced
<ion_> URL?
<ion_> keybuk: Congrats. :-)
<Amaranth> glib has gint and such for portability reasons
<Amaranth> it future proofs the library for new architectures
<Keybuk> *HOW*
<Keybuk> how is gint any more portable than the int type its typedef'd to?!: :)
<Amaranth> make sure int is always the same size
<Keybuk> but it doesn't
<Keybuk> gint is int
<Amaranth> on a new arch they can change gint to typedef to something else
<Keybuk> but they don't
<Amaranth> but they could :)
<Keybuk> and, the best thing is, C *already* has typedefs for this
<Keybuk> int32_t
<Keybuk> uint64_t
<Keybuk> etc.
<Keybuk> if you *care* about the size
<Amaranth> aren't those C99?
<Keybuk> yes, they're from a C standard that is almost 10 years old
<Amaranth> that many compilers still don't get right
<Keybuk> in fact, I think C99 was C96 before, so more than 10 years old
<Keybuk> name one
<Keybuk> name a compiler that doesn't get them right that you can actually compile GNOME on :p
<Amaranth> i think think windows has int16
<Keybuk> MSVC++ is one of the better C99 compilers out there
<Keybuk> it might have other typedefs, but it certainly supports the standard
<Amaranth> but this is the stdlib
<Keybuk> SUNWspro certainly supports them
<Keybuk> gcc does
<sadmac_> Keybuk: gcc doesn't fully support C99, by their own admission. I don't know the discrepancies though. Obviously small.
<Amaranth> i'm pretty sure windows doesn't have all of them
<Amaranth> saw a debian guy bitching about this a couple days ago
<Keybuk> you certainly don't need to protect the size of "int"
<Keybuk> gchar
<Keybuk> (!!)
<Keybuk> whoah!  fat characters!
<sadmac_> Most people I know that are big into C consider C99 to be a failed standard though.
<Amaranth> wasn't the main point of C99 to make C and C++ mix better?
<Keybuk> sadmac_: http://gcc.gnu.org/c99status.html
<Amaranth> also, glib is rather old...
<Amaranth> everything might support that stuff now but did it in 2001?
<Keybuk> glib is just over-engineered
<Amaranth> that too
<sadmac_> Keybuk: cool.
<Keybuk> it's a library written for writing programs in C for people who don't like writing programs in C
<Amaranth> just use vala :)
<Keybuk> everything C-like is hidden so you can pretend you're writing in G
<Keybuk> when, in reality, you probably just wanted C++ in the first place
<Keybuk> or compiled C# or Java
<Amaranth> but C++ is evil
<Keybuk> glib is evil ;)
 * sadmac_ still needs to learn Objective C
<Amaranth> slightly less evil :)
<Keybuk> the difference between C++ and glib in terms of evil is like the difference between Steve Ballmer and Bill Gates
<Keybuk> at least C++ *knows* its evil
<sadmac_> Java is more evil than C++. C# is somewhere between the two.
<Amaranth> C# is pretty nice, really
<Keybuk> it wakes up in the morning, has a good manic laugh, and sets out to see what new evil it can bring to the day
<ion_> :-)
<Keybuk> glib just brings the same evil without trying
<Keybuk> C# does generally seem nice
<Keybuk> it was invented by the guy who did Delphi and ObjectPascal
<Keybuk> and I liked them
<AlexExtreme> it was?
<Amaranth> I'd rather use C# than C++ because if I'm going to have to deal with that bullshit at least I don't have to deal with memory management and pointers :P
<Keybuk> my only issue with it is that its interpreted
<sadmac_> Digital Mars D looks nice, but the implementation just isn't there yet.
<Amaranth> Keybuk: which vala 'fixes' :)
 * sadmac_ looks into vala
<sadmac_> interesting
<Keybuk> yay
<Keybuk> I *think* I have dbus now hooked properly into the nih main loop
<ion_> Yay
<Keybuk> of course, that's the easy bit
<Keybuk> sending messages and handling those you get is the hard bit ;)
<ion_> :-)
<Keybuk>         server = nih_dbus_server ("unix:abstract=/com/ubuntu/upstart/test");
<Keybuk>         if (! server) {
<Keybuk>                 err = nih_error_get ();
<Keybuk>                 printf ("ERROR: %s\n", err->message);
<Keybuk>                 exit (1);
<Keybuk>         }
<Keybuk> ...
<Keybuk> ahh, a nice API at least
<ion_> Great
<Keybuk> ok, that still needs to have something to handle publishing objects
<Keybuk> etc.
<Keybuk> but in theory, all upstart needs to call is nih_dbus_server() to handle direct clients and nih_dbus_system_bus() to handle indirect
<sadmac__> nih_error_get sounds like a 4chan meme
<sadmac__> 250 ERROR GET!
#upstart 2008-03-13
<Keybuk> I think that the right way to approach this is autogenerated code
<Keybuk> have something that turns an xml file into either proxy functions or marshal functions
<ion_> XSLT?
<Keybuk> probably just Python ;)
 * ion_ once made an evil m4âxsltâ{makefile,graphviz} converter thing. :-P
<Keybuk> heh
<Keybuk> I never really understood xslt
<ion_> http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline.m4;hb=HEAD is converted to XML by http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline/to-xml.m4;hb=HEAD which is converted to a makefile by http://gitweb.heh.fi/?p=ion/heroes-scrape.git;f=pipeline/to-mk.xsl;hb=HEAD (and it also spouts this graph, http://heh.fi/heroes/heroes-scrape/pipeline.html). :-P
<Keybuk> ion_: that's intense!
<Keybuk> talking of which
<Keybuk> I was thinking about nih_ref and nih_unref again last night
<Keybuk> there's some thorny bits of code in Upstart that are basically compensating for the lack of it
<ion_> Ok
<Keybuk> so I was thinking
<Keybuk> in general principle, nih_ref and nih_unref should just work
<Keybuk> if you pass NULL as the context, the default 1 reference is yours
<Keybuk> if you pass non-NULL, the reference is not yours
<ion_> Yeah
<Keybuk> the problem is that you have to remember you ref'd and unref in destroy()
<Keybuk> so for the case I'm thinking
<Keybuk> event_new "steals" the env array you pass it
<Keybuk> with the ref/unref model, it would have to ref it, at which point it'd have to unref it again
<Keybuk> losing the niceness of the hierarchical bit
<Keybuk> so it'd certainly work
<Keybuk> but I'm wondering if instead, we don't want each allocation to have multiple parent contexts?
<Keybuk> you pass one when you create it
<Keybuk> and any other parent can adopt it
<Keybuk> when a parent is freed, it orphans its children
<Keybuk> if they have other parents, then they're fine
<Keybuk> if they are truly orphaned, then they're freed
<ion_> Yeah, many-to-many relationships would be nice.
<Keybuk> doing those O(1) might be hard though
<ion_> Would we need anything else than a list of parents for each child and list of children for each parent?
<Keybuk> no
<Keybuk> but for each parent/child relationship, we'd need n pointers
<Keybuk> so the context would grow for each relationship you add
<ion_> Yep
<ion_> How about a hash table with key and value being the pointer?
<ion_> Or is that a stupid idea? :-)
<ion_> (Or a hash-like table with only keys â say, a Hashish table.)
<Keybuk> I was thinking something like that
<Keybuk> instead of putting the context at the beginning of the block, just have a lookup table
<Keybuk> that'd mean nih_alloc could adopt blocks allocated elsewhere
<ion_> A Finnish ISP defines IRC as âInter Relay Chat â Internetâs dating serviceâ. http://sanasto.elisa.fi/showWord.cfm?id=1079&languageId=1
<Keybuk> IRC is Finnish
<ion_> Yes.
#upstart 2008-03-14
<sadmac_> Keybuk: we may have some patches for you soon so that nih can detect rpm tempfiles as well as dpkg files
#upstart 2008-03-15
<age6racer> hey guys/girls, I have a bash script which starts a firefox I want the firefox process to respawn if it dies. I think i need to use upstart for this. What do I need to do?
<ion_> Since this box is unable to boot the Ubuntu live-CD with its 64 MiB of RAM, and as for burning the alternative CD, this drive is unable to read CD-RWs and i don't have empty CD-Rs available, i booted from the live-CD, stopped the boot sequence at an appropriate time, and now i'm doing a manual install a la Gentoo. :-)
<keesj> ion_: mount /mnt/bla  ; mount -t proc none /mnt/bla/proc ... chroot etc etc etc. I love doing it
<keesj> ion_: I have such a device http://www.norhtec.com/ and I installed debian on it using a usb-stick , I am quit happy with it (the ubuntu usb install did not work )
<keesj> that is not fully true, I first installed ubuntu under qemu (with more ram) and copied it over
<ion_> keesj: Yeah, i'm already running the installation.
<keesj> some guy on the maemo mailing list posted about einit http://einit.org . I did no hear of that before
<magnetic> hi
<keesj> Âhello
#upstart 2008-03-16
<ion_> Terminfo doesnât seem to contain the strings to set the window title/status text in e.g. xterm or screen. :-(
<ion_> http://gitweb.heh.fi/?p=ion/dotconfig.git
<ion_> In .config/shellrc, i have a nice kluge that compiles a personal terminfo file with additional info for setting the terminal window title when needed. :-)
#upstart 2009-03-09
<h\h> hi
<Keybuk> hi
<Keybuk> how goes it harald?
<h\h> yes
<h\h> s/yes/fine, thanks/ 
<h\h> :)
<h\h> Hey Keybuk, what is upstart 1.0 doing? :)
<Keybuk> "what is" or "how is" ?
<h\h> "how is"
<Keybuk> mostly pinned down what I want to do
<h\h> sry for my bad english :)
<Keybuk> been doing some ground work and playing around really so far
<Keybuk> not going to start coding in earnest for a few weeks yet
<Keybuk> we're still in pre-beta, and I've still got a pile of boot speed related patches to do, as well as new m-i-t etc.
<h\h> " boot speed related patches"
<h\h> what are you going to do?
<Keybuk> that's a long list ;)
<Keybuk> https://wiki.ubuntu.com/FoundationsTeam/BootPerformance
<h\h>  Investigate why udevadm is taking too long, and improve where possible
<h\h> 	
<h\h> Done 
<h\h> what was it? module loading?
<Keybuk> partially
<Keybuk> other fixes Alan did for udev to use pselect and so on have helped too
<h\h> upstream patches?
<h\h> or can you point me to a patch?
<Keybuk> it's all in 139
<h\h> ah, fine
<h\h> are you starting dbus, hal from upstart now?
<Keybuk> not yet, no
<keesj> http://fosdem.unixheads.org/2009/maintracks/upstart.xvid.avi 
<keesj> (upstart talk at fosdem)
 * Keybuk doesn't remember them asking for permission to video me ;)
<sadmac> win 21
<sadmac> shit, its too early
<Jc2k> :) i do that twice a day  sadmac :( :(
<MarcWeber> The event based model is fine. However does init also provide some notion of state?
<MarcWeber> Example: there is one job setting up network. So many jobs will start on started network.
<MarcWeber> Now the os wants to install a new daemon which should only be started if network has been started as well.
<MarcWeber> So is the way to start this daemon only if initctl status network = running ?
<MarcWeber> Or does upstart start this daemon itself when recognizing there is a new job file depending "on started network"?
<sadmac2> MarcWeber: the next version will have this stuff.
<MarcWeber> Ah thank you for this information.
<MarcWeber> Which is the correct way to shutdown a system?
<MarcWeber> for job in `initctl list`; do stop $job; done then sync and halt -f -p ?
<ion_> Pull the power cord.
<MarcWeber> ion_: Can't, its a vserver :)
<ion_> Pull the power cord of the physical box itâs running on. :-)
 * ion_ watches upstart.xvid.avi
<keesj> is the sound ok?
<ion_> Yeah
<sadmac> Keybuk: your plumbing layer looks like a blue hamburger
<damjan> Where can I fing a detailed reference of what can a job file contain?
<sadmac> Keybuk: also we had upstart in F9 ;)
<damjan> Keybuk: wow, you had some bad luck with git :)
<damjan> Dunno, I don't consider me as even a programmer, but  I find git easier than you experience. And better than darcs (the first DVCS I used), and mercurial (the second)
<damjan> better, because although mercurial and darcs were easy to understand, while git only a bit harder, with git I could more easily get myself out of stupid situations I've put myself in
#upstart 2009-03-10
<damjan> I'm playing with upstart, but I can't login on tty1.. any idea how to make a job that just starts a shell on tty1 ?
<sadmac> damjan: start on runlevel 5 / exec /bin/bash
<sadmac> runlevel 3 rather
<damjan> how about "start on startup"?
<damjan> I'm getting "main processes ended"
<MarcWeber> damjan:  Also add "session leader"
<MarcWeber> ar 10 02:13:52 nixos init: sshd pre-start process (25558)
<damjan> MarcWeber: still no luck "init: rescue main process ended, respawning"
<MarcWeber> seeing this line and ps -p no longer showing any process pid 25558
<damjan> rescues is the name of the job (file) I created
<MarcWeber> Then this means that the kernel doesn't tell upstart the the pr-start process has finished?
<MarcWeber> damjan: Are you sure that upstart has noticed that your file has changed?
<damjan> MarcWeber: I'm installing upstart on a non-Upstart system
<damjan> in a virtual machine, so I reboot it all the time
<MarcWeber> damjan: Which virtual machine?  vserver?
<damjan> KVM
<MarcWeber> Or qemu..
<damjan> I can't even login to the VM with upstart
<MarcWeber> http://rafb.net/p/3MfPOS65.html from line 3 on. This works hree
<damjan> the stupid thing is, obviously /bin/bash fails to start for some reason but where is the error output ?!?
<MarcWeber> Try exec &> /tmp/foo
<damjan> well / is not rw at that point :)
<damjan> .. I suspect
<damjan> .. although I have a script that should do the basic system setup, I don't see it's output so I don't know if it worked ok
<MarcWeber> You have do create /dev/console
<damjan> yeah, I know that .. hmm .. I think it should exist .. but let me confirm
<damjan> .. (just what was the trick to get the real /dev/ beneath udevs tmpfs ?!?)...
<MarcWeber> mkdir and mknod use google or kernel Documentation
<damjan> ok the trick is "mount --bind / /mnt" now I can see the real /dev/ in /mnt/dev/
<damjan> it does have /dev/console null and zero
<MarcWeber> I know that upstart has nice goals. However I think it should try to be at least as good as the old init* programs.
<damjan> I feel like it's hard to beat the old init* programs, they've been baked to perfection with the years
<MarcWeber> It's not that hard. However not beeing able to set oom shouldn't make starting the job fail altogther.
<MarcWeber> Maybe there should be a simple /bin/sh test and if upstart doesn't get to know within 1/20s that it has failed assume that it has to use ps -p to check wether a process has died. I know that sucks. But it would work in 99% of all cases which is much better than 0%
<MarcWeber> Let's hope that my snapshot I'v taken month ago works fine. It alread did..
<MarcWeber> No, didn't help. Maybe I'm just talking nonsense. I'm a little bit disappointed that I still haven't suceeded..
<MarcWeber> Keybuk, sadmac Do you think there is any chance  using an alternative less pretty implementation of getting notified when processes (such a spre-start) exit?
<Keybuk> how do you mean?
<MarcWeber> As I've said. Currently I've the problem on the v-server that the sshd-pre start script gets started..
<MarcWeber> init prints the pid to the log. But then nothing happens. I can no longer show that process using ps -p pid
<MarcWeber> So it has died (it contained a mkdir -p command only. .)
<MarcWeber> init doesn't get notified that the pre-start script has exited so it dosen't start sshd
<Keybuk> why doesn't init get notified that the pre-start script has exited?
<Keybuk> that sounds like your vserver has broken if it's not sending SIGCHLDs to init
<MarcWeber> I can try contacting the support service again and ask wether they can enable it. Don't know yet was is happening. All I now that pre-start doesn't cause the daemon to be started.
<MarcWeber> Can I test the SIGCHLDs without being PID 1 somehow?
<Keybuk> sure, sigchld is pretty fundamental ;)
<Keybuk> did you try init with --debug and capturing the output?
<MarcWeber> only -v
<MarcWeber> I'll retry
<MarcWeber> I've commented out the whole oom_adj part Because I don't have permissions to change them (for whatever reasons).
<MarcWeber> line 165 http://rafb.net/p/gdEQ1132.html
<MarcWeber> sshd should be started on event manual
<MarcWeber> The job and debugging output http://rafb.net/p/sXDAnh65.html
<MarcWeber> Would it make sense to add an upstart-test application which could be run on startup once to verify that all required features are availible?
<MarcWeber> I could also move the code from the pro-start scripts into the main script..
<MarcWeber> Is --debug output sent to the logging daemon as well?
<MarcWeber> Keybuk: So does this anything to you?
<MarcWeber> Keybuk: Would you mind pingingn me if you're availible for some minutes again?
<MarcWeber> Keybuk: You've been right. the strace shows that no SIGCHD is sent. http://rafb.net/p/2VpHyE47.html. I've sent another ticket. Thank you!
<Keybuk> MarcWeber: sorry, been having X server crashes all morning
<Keybuk> lost your log
<MarcWeber> Ah never mind. :-)
<Keybuk> I'll never understand why people use vserver
<Keybuk> from what I can tell, it doesn't implement a POSIX system very well
<MarcWeber> Because they are cheep and except of those troubles they work well..
<Keybuk> so it's pot luck whether anything works
<Keybuk> surely Xen has killed it by now?
<MarcWeber> Keybuk: I can't affort a dedicated server yet :-(
<Keybuk> I don't mean virtualisation in general
<Keybuk> just the particular implementation that is vserver
<MarcWeber> So which kind of hosting service do you recommend ?
<Keybuk> http://www.linode.com/ do lovely cheap Xen instances ;)
<Keybuk> $19,95/mo for basic
<Keybuk> though I don't know how that compares with your vserver host
<MarcWeber> Xen is supposed to work?
<Keybuk> Xen works brilliantly
<MarcWeber> I guess I've found another hosting company which is using xen. So I'll just give up and switch again :)
<Keybuk> heh
<Keybuk> I don't mean to be mean ;)
<Keybuk> but I have been on the receiving end of what feels like dozens of vserver bugs now
<Keybuk> (both for upstart and udev)
<Keybuk> where it just flat-out does things that the book says it can't
<MarcWeber> I can't ping linode < 120ms
<MarcWeber> So maybe I should use a hosting service which is closer to Germany.
<MarcWeber> Keybuk: I think upstart is great. I think it will take off.
<Keybuk> there is one, I can't think what it is
<sadmac> Keybuk: liked the talk
<MarcWeber> Keybuk: I've just added some debugging hints which have helped me: http://upstart.ubuntu.com/wiki/Debugging#preview
<damjan> echo "Debug Message" >> /tmp/upstart will not succeed until / is remounted RW
<MarcWeber> damjan: I've added that note :)
<MarcWeber> Keybuk: May I also quote you telling that Xen systems are known to work much better?
<keesj> also the naming sounds a little weird echo "Debug Message" >> /tmp/upstart looks like it some sort of magic to make upsart be in debug mode
<keesj>  echo "Debug Message" >> /tmp/my_job_debug sounds better to me
<keesj> with 0.5.1 you can do initctl log-priority debug so see what is happening inside upstart
<keesj> I would also say on what version this wiki page applies to
<MarcWeber> I hope that everyone setting up upstart has enough knowledge to know what echo "" >> foo means :-)
<MarcWeber> keesj: I've added the log-priority hint as well
<ion_> Meh, no waitfd in jauntyâs kernel.
<Keybuk> no
<sadmac2> ion_: no waitfd in anybody's kernel I hope.
<sadmac2> the patch isn't upstream
<Keybuk> talking of which
 * Keybuk fires the patch gun at lkml
<sadmac2> Keybuk: you have a patch for it?
<Keybuk> no
<Keybuk> you have :p
<Keybuk> these are different patches
<sadmac2> Keybuk: oic
<sadmac2> Keybuk: thought you got bored and just rewrote it for me :)
<sadmac2> Keybuk: how will upstart process these "when dbus started" lines? is dbus an argument before the name? some other construct?
<ion_> Any news about waitfd? Is it getting into Linusâ tree any time soon?
<sadmac2> ion_: I think it needs another round of fixes, and impressions are mixed. It also needs to be better explained.
<sadmac2> The next patch had better be good. Alan Cox is going to flip his shit when he sees the thing a third time.
<ion_> Heh
#upstart 2009-03-11
<ion_> sudo make me a sandwich
<sadmac> ion_: AVC Denied subj=system_u:system_r:system_t
<ion_> SELinux? Eww. :-P
<sadmac> ion_: wuss
#upstart 2009-03-12
<ion_> ADHOS: Attention-Deficit Hyperac... Ooh, Shiny!
<mbiebl> Keybuk: hi
<Keybuk> hay
<Keybuk> oh hai
<mbiebl> Keybuk: I was contemplating about moving libdbus to /lib on Debian as you already did on Ubuntu 
<mbiebl> I wondered though, why you also moved dbus-daemon itself (and its utils), when its dependencies (like libexpat) are still on /usr
<Keybuk> just a case of a partial move
<Keybuk> expact is on the todo list
<mbiebl> but is dbus-daemon on /bin really necessary?
<mbiebl> Wouldn't libdbus be sufficient
<Keybuk> a reasonable question
<Keybuk> depends how we want to do filesystem mounting
<mbiebl> as in?
<mbiebl> what role would dbus-daemon have to play there?
<Keybuk> notification of the availability of new block devices
<Keybuk> which are then checked, and if their filesystem parents are mounted, mounted themselves
<Keybuk> (otherwise queued)
<ion_> The automount daemon iâve been contemplating would handle that and wouldnât use dbus-daemon.
<Keybuk> how would you be notified?
<ion_> I was thinking of something like SUBSYSTEM=="block", ACTION=="add|remove", RUN+="/sbin/automountc udev", with the client sending a simple message to automountd. It could always use libdbus but talk directly to the daemonâs UNIX socket.
<mbiebl> Keybuk: but that would also require hal or DeviceKit, right?
<Keybuk> ion_: that incurs quite a high cost per device
<ion_> Hmm, okay.
<Keybuk> you'd have to fork/exec the udev child, the match costs, then the cost of fork/execing your automount client
<Keybuk> your automount client could just use udev-dbus-daemon to be notified of the new devices
<Keybuk> (if we have an early dbus daemon)
<ion_> True
<Keybuk> (udev-dbus-daemon being the bit that used to be DeviceKit)
<Keybuk> ie. d-bus access to the udevdb
<mbiebl> oh yeah, davidz likes to move things around quite a bit ;-)
<ion_> A random thought, SUBSYSTEM=="block", ACTION=="add|remove", RUN+="socket:@/.../automount/udev_event" :-P
<Keybuk> ion_: why is that better than just using dbus?
<Keybuk> (and it still costs you the udev child needed to process that)
<ion_> Assuming every relevant distro will be running dbus before fscking /, itâs not better.
<Keybuk> well... since the relevant distros are those using udev, and probably upstart
<Keybuk> those that don't embrace such things are unlikely to embrace a "turn by turn" mount -a replacement <g>
<ion_> True
<ion_> Allright, iâm convinced, dbus is the way. :-)
<damjan> good luck debuging that "mount by dbus" thing when it doesn't magically do what it's supposed to do :)
<Keybuk> damjan: ?
<ion_> I donât see how thatâs different from debugging anything else.
#upstart 2009-03-14
<MarcWeber> Keybuk: I've tried writing a SIGCHD signal test. Could you have a quick glance at it telling me you think it tests what it should?
<MarcWeber> http://rafb.net/p/qkF9US87.html
<MarcWeber> http://rafb.net/p/JlJcDY37.html That's the result.
<MarcWeber> It doesn't matter wether I run this execuctable as pid 1 or not. the result is the same.
<MarcWeber> It gets the SIGCHD signal. So why doesn't upstart receive one? Any idea hwo to track down the failure?
<MarcWeber> I'll try compiling upstart exactly usnig the same compiler now..
<MarcWeber> Wow. I've found the bug. This patch makes upstart run like a charm on this vserver..
<MarcWeber> waitpid eturns pid-1 instead of pid ! Can this be caused by having wrong kernel sources?
#upstart 2010-03-15
<Keybuk> ion: vague zany idea, remove some of the need for stanzas in the job format
<Keybuk> e.g. instead of
<Keybuk>     env FOO="some value"
<Keybuk> just have
<Keybuk>     FOO="some value"
<Keybuk> could introduce some nice features that way
<Keybuk> while apache
<Keybuk> every hour
<Keybuk> exec log-rotate
<Keybuk> restart apache
<Keybuk> -- 
<Keybuk> where "restart" is exactly equivalent to
<Keybuk>   script
<Keybuk>     exec log-rotate
<Keybuk>     restart apache
<Keybuk>   end script
<Keybuk> type things
<Keybuk> except obviously without the exec there :p
<ion> Sounds good
<Keybuk> then I was thinking that things like "on" could bind to whatever follows
<Keybuk>    while apache
<Keybuk>  
<Keybuk>     every hour
<Keybuk>     exec log-rotate
<Keybuk>  
<Keybuk>     every day
<Keybuk>     exec log-rotate --force
<Keybuk>  
<Keybuk>     on omg-the-world-is-over
<Keybuk>     restart apache
<Keybuk> which is kinda cute for sub-jobs without needing a block
 * sadmac considers whether he has to do anything nasty to his parser now
<sadmac> should be ok....
<Keybuk> sadmac: it was reading your parser code that made me think about it
<sadmac> Keybuk: ah, cool
<Keybuk> as can be more flexible
<sadmac> I've been working on nih_parse_tool, which will work like yacc and turn a DSL into a C code parser
<ion> Nice
<sadmac> starting to appreciate how much of a pain actually processing these parse trees can be, but I think the parse tool will make it pretty straightforward
<sadmac> and it'll get rid of the need to specify charsets manually, which normally requires a calculator and causes anneurisms.
<Keybuk> so nobody hates the idea that on would bind like that?
<sadmac> Keybuk: I wouldn't mind playing with it
<ion> As long as how other things such as env, instance etc. are clearly defined.
<sadmac> Keybuk: it may mean that the next job format isn't a strict superset of 0.6, which means more acrobatics to do that backward compatibility thing you promised
<Keybuk> sadmac: 0.6 doesn't support bare "on" - so it should be fine
<sadmac> Keybuk: right, but as of now we can only have one job format and get away with everything. We just neglect to remove start on/stop on and the 0.6 grammar is a subset of the 1.0 grammar.
<sadmac> Keybuk: this way we might need two separate parsers.
<sadmac> Keybuk: oh, I see what you're saying though... yeah could be.
<Keybuk> ie. using "on", "every", "at" type keywords, everything after that is strict 1.0 grammar
<Keybuk> but up until then, you can get away with some older grammar
<sadmac> so it'd be jobfile = stanzas06* stanzas10*
<Keybuk> right
<Keybuk> tbh, we can even get away with "as soon as you put any 1.0 format thing in there, then the entire file must be 1.0 not 0.6"
<Keybuk> since the point of the compatibility is to make sure existing jobs work
<sadmac> jobfile = stanzas06* EOF | stanzas10* EOF
<Keybuk> right
<Keybuk> the only really ambiguous bit is the double stanzas crap
<Keybuk> a file containing just:
<sadmac> ugh. that ends up being kinda slow because we parse as much of the file as we can as 0.6, until we find a 1.0 thing. then we start over
<Keybuk>   exec foo
<Keybuk>   exec bar
<Keybuk> I'd do it the other way - parse as 1.0 until we fail, then go back and see if it parses as 0.6
<sadmac> that works too.
<Keybuk> parse errors can even be tagged "but might work on 0.6"
<Keybuk> e.g.
<Keybuk> the second exec there would be a parse error tagged "but try 0.6"
<sadmac> that's the last thing I'll need to go back and do is the error reporting
<ion> keybuk: Re: âimplementing serialized startup sequenceâ: we talked about Upstart implementing similar priority stuff as what mountall is doing for fscks at the moment. I wonder if that would be useful for them as well?
<Keybuk> entirely possibly
<Keybuk> first I want to figure out what they mean
<Keybuk> I still don't know where the whole M{oblin,aemo,eego} thing is going
<ion> keybuk: An initial idea for the config syntax: âpriority 1; locks sda sdbâ: the job has internal exclusive locks named âsdaâ and âsdbâ while running. Whenever a pending job is considered for getting to start next, consider the highest-priority ones first, the default priority being zero. âpriority -5; contends-io sda sdbâ: no actual locking, but the highest-priority one (falling back to first-come first-served) per âlockâ names gets the IO ...
<ion> ... priority at any given moment. Just like what mountall does, but with an optional priority integer. âcontends-cpu foo bar bazâ: same, but for niceness.
<Keybuk> http://upstart.ubuntu.com/wiki/Resources
<Keybuk> written in 1882 or something <g>
<ion> Ah, i didnât even remember about that one.
<ion> As for what i wrote, the âlocks Xâ, âcontends-io Yâ and âcontends-cpu Zâ tags should all be in their own namespaces, so foo.conf: âlocks blaâ and bar.conf: âcontends-io blaâ would not affect each other.
<ion> So âcontends-io sda sdb; contends-cpu sda sdbâ would do both IO and niceness priorization.
<Keybuk> makes sense
<sadmac> Keybuk: any other thoughts on nih-parse while you were looking at it? I guess its at least clean enough now that you can tell what the code does :)
<Keybuk> the code is still ick
<Keybuk> I don't like giant macros like that
<Keybuk> you're from North Carolina
<Keybuk> we have to assume that, at some point over the next couple of years, you are going to get murderer
<Keybuk> or at least shot
<Keybuk> so it has to be maintainable once you're gone :p
<sadmac> Keybuk: I get murderer and murderer every day.
<sadmac> Keybuk: I more or less agree. I know I can at least remove the per-function structs. After that some of the macros might even be able to become functions.
<Keybuk> that would be yay
<sadmac> Keybuk: I've spent a lot of time trying to figure out how I wrote it as easily as I did in the first place. It ran pretty much the first time.
<NoReflex> hello! I'm having some problems with upstart in karmic server 64bit. It won't start postgresql. I tried http://superuser.com/questions/98702/how-to-make-postgresql-start-at-boot-time-in-ubuntu but it didn't work. can I remove upstart? I'm afraid to test it because the machine is at a remote location and if I mess it up I won't be able to connect to it anymore.
<NoReflex> I can start postgresql using /etc/init.d/postgresql-8.4 manually after login. There are links in /etc/rc*.d to postgresql init script but for some reason it isn't started automatically after reboot
<NoReflex> the channel says Upstart 0.6.5 "Our last, best hope for victory" ... should I try this version? is it dangerous?
<NoReflex> I also searched for a logging possibility because I don't know why it won't start....and it's hard to "debug" a problem when you don't have the error message
<NoReflex> any ideas?
<NoReflex> Can I replace upstart with the old init package?
<NoReflex> anybody?
<mbiebl> NoReflex: I don't think you can.
<mbiebl> Most of the core init scripts (rcS stage) have been converted to upstart-only
<mbiebl> I don't see, why starting sysv init scripts for runlevel 2 should be a problem.
<mbiebl> do you have a bug report maybe?
#upstart 2010-03-16
<edgecase> last hope, oh my!
<Keybuk> heh
<edgecase> ok semantic question, on ubuntu mountall.conf takes care of mounting root fs rw, other fs, etc,
<Keybuk> yes
<edgecase> but, could it be assumed, that by definition, starting /sbin/init, means the rootfs is already mounted, possibly read-only?
<Keybuk> yes
<edgecase> i mean either a monolithic kernel, or an initrd's pivot_root, or say lxc container starting...
<Keybuk>         /* Sanity check, the root filesystem should be already mounted */
<Keybuk>         root = find_mount ("/");
<Keybuk>         if (! root->mounted) {
<Keybuk>                 nih_fatal ("%s", _("root filesystem isn't mounted"));
<Keybuk>                 exit (EXIT_ERROR);
<Keybuk>         }
<Keybuk> even mountall assumes that :p
<edgecase> so "start on startup" implies certain parts of FHS are available, yes?
<Keybuk> edgecase: it implies that the root filesystem is read-only
<Keybuk> we tend to assume that means you have /bin, /sbin, /lib and /etc
<edgecase> but not /usr or /var
<Keybuk> right
<Keybuk> definitely not /usr, /var, /boot, /home, /proc, /sys, /dev, etc.
<Keybuk> although with Upstart, you can assume /proc and /sys are mounted
<edgecase> i'm just pondering the sysctl.conf race problem
<Keybuk> and with recent kernels, /dev should be a devtmpfs
<Keybuk> sysctl.conf race problem?
<edgecase> race of setting things vs network interfaces coming up.  in Karmic for example
<edgecase> there's a couple launchpad bug IDs
<edgecase> i drew out an elaborate map of the issues, but let me try and focus on one aspect
<edgecase> ok, with sysctl parameters, there are some that affect parts of the kernel which is only compiled in (not a module)
<edgecase> but with many, it could be a module or compiled in, so there's no *right* place for sysctl.conf to be loaded
<Keybuk> right
<Keybuk> this is why I keep trying to eradicate that silly directory
<Keybuk> but people keep insisting I put it back :p
<edgecase> i wonder if the whole sysctl paradigm doesn't work so well 
<Keybuk> I tend to think that, since we have the kernel source, changing a sysctl default is best done by changing the default in the kernel
<Keybuk> otherwise you have races like "the sysctl doesn't get set until after ssh is running and there's a security hole for a while"
<edgecase> i'm thinking of network configs here, default isn't enough
<edgecase> the system needs to be configurable
<Keybuk> sure
<Keybuk> but you can do one off-things like that with udev
<edgecase> there's a couple real problems with sysctl tho,
<Keybuk> SUBSYSTEM=="module", KERNEL=="i915", RUN+="echo 4 > /proc/sys/..."
<edgecase> a NIC module could be compiled in, loaded by udev, or by the initrd... hard to put it's settings in one place had have it affect all 3
<Keybuk> you should still get module events for them
<edgecase> will that read sysctl.conf ?
<Keybuk> you only don't get module events for built-ins with no parameters
<Keybuk> no
<edgecase> hence the sticky issue
<Keybuk> and reading sysctl.conf 800 times during boot is out of the question, before you ask ;)
<edgecase> workaround for the parameters i need is to set in /etc/network/interfaces and avoid the issue
<edgecase> but i'm also interested in the bigger picture of upstart
<edgecase> maybe just agree that sysctl isn't good for things not compiled-in
<Keybuk> I don't think there's a picture of sysctl in the upstart painting yet
<Keybuk> it's probably in the big white space off to the right with a doodle of someone's dog in it
<Keybuk> sorry, have to run now
<Keybuk> it's 1am here
<edgecase> yeah, that's ok, i can workaround for the network stuff  i need
<Keybuk> feel free to mail suggestions for how this could work to the ML
<Keybuk> upstart is very much still under development
<Keybuk> so lots of things can be improved
<edgecase> d'oh!
<edgecase> be around tomorrow?
<Keybuk> yes, though earlier!
<Keybuk> nite
<edgecase> ok
<edgecase> thx
<edgecase> hmm hostname.conf, nothing depends on it, 
<NoReflex>  hello! I'm having some problems with upstart in karmic server 64bit. It won't start postgresql. I tried http://superuser.com/questions/98702/how-to-make-postgresql-start-at-boot-time-in-ubuntu but it didn't work. can I remove upstart? I'm afraid to test it because the machine is at a remote location and if I mess it up I won't be able to connect to it anymore
<NoReflex> I can start postgresql using /etc/init.d/postgresql-8.4 manually after login. There are links in /etc/rc*.d to postgresql init script but for some reason it isn't started automatically after reboot
<NoReflex> nothing?
<elpargo> hi. I got a program that I want to "always be running" as it opens a http listener and waits for input "forever" 
<elpargo> I'm not entirely sure if I should be doing an upstart script for it.
<ct529> hi everybody .... I am having serious problems with upstart on ubuntu 910 64 bit .... it would not start CUPS at all ....
<ct529> CUPS is properly configrued in /etc/rcX.d and in /etc/init.d ....
<NoReflex> ct529: I have the same problem with upstart on Karmic 64bit. On my machine it won't start postgresql server. I tried http://superuser.com/questions/98702/how-to-make-postgresql-start-at-boot-time-in-ubuntu without luck
<NoReflex> ct529: as a workaround you can use rc.local ... not perfect but at least it works...
<ct529> NoReflex: how?
<ct529> NoReflex: yes, I have the same problem with mysql and postgresql
<ct529> NoReflex: what do you see when you run the command runlevel?
<NoReflex> ct529: what I did was to remove the links from /etc/rc*.d for postgres (sudo update-rc.d -f  postgresql-8.4 remove) and add the start command to rc.local
<ct529> NoReflex: did you add it manually?
<ct529> NoReflex: could you pleas elet me know what do you see when  you run the command "runlevel"?
<NoReflex> ct529: runlevel gives N 2
<ct529> NoReflex: so it works on your machine
<edgecase> elpargo, are you asking if you should write upstart script instead of sysVinit script?
<kimju> hello.. Is there some documentation on howto debug the bootup sequence? I'm getting bitten by bind9 trying to start (and failing) before the interfaces with ip-addresses that it is configured to listen-on / listen-on-v6 are brought up.
<kimju> (this is happening on ubuntu karmic. someone else has reported it as bug: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/510587 )
<Keybuk> kimju: you should ask on #ubuntu about that
<Keybuk> as far as I'm aware, bind9 in ubuntu is still using a sysvinit script and hasn't been converted to an upstart config file
<kimju> Keybuk, ok, sorry. I just asked before you joined the channel if there is some documentation on how to debug the bootup sequence, as I'm getting bitten by that bug.
<Keybuk> boot with --verbose on the kernel command-line
<edgecase> Keybuk, top o' the morning to ya!
<edgecase>  hmm hostname.conf, nothing depends on it, 
<edgecase> so a race is possible with anything that uses hostname/utsname
<Keybuk> edgecase: hey
<Keybuk> ah yes, it's still St Patrick's Month
<edgecase> i will now continue the barrage!
<Keybuk> edgecase: can you think of anything that cares about the hostname? :p
<edgecase> syslog?
<Keybuk> it doesn't really depend on it
<Keybuk> it queries it for every log
<edgecase> ah ok
<Keybuk> so if the hostname changes, it works just fine
<edgecase> aside, is there anything to graph the dependencies visually?
<edgecase> would make investigation easier
<edgecase> for rsyslog, if you log to remote host, might get unknown hostname for a bit?
<Keybuk> no, but there's no reason it shouldn't be easy to write something that makes dotty output
<edgecase> ok will look at dotty
<Keybuk> for rsyslog, if you log to remote host, you have to wait for the network to come up first :p
<Keybuk> and on the typical laptop system, that won't happen until a user logs in and unlocks the WPA key :p
<edgecase> you noticed my nick is "edgecase" right?
<edgecase> i tend to ignore "typical" cases :P
<Keybuk> :)
<edgecase> anyhow i'll admit hostname is a trivial case
<edgecase> i notice mountall.conf emits many variations of filesystems
<edgecase> is there a formal definition of those, that would allow splitting them up?
<edgecase> "emits filesystem", does that mean root fs is read-write?
<edgecase> appologies if that info is published already
<edgecase> hmm, having /var not a mandatory part of root fs, and yet having /var/run mounted on top, seems problematic
<edgecase> I question the original unix paradigm of "map everything to a file" for daemon .pid files, esp. if they are going to just map back to ram(disk)
<edgecase> just use unix socket or even abstract namespace one
<Keybuk> edgecase: did you do "man 7 filesystem" ?
<Keybuk> problematic> not really
<Keybuk> it requires some juggling
<Keybuk> but it works
<Keybuk> we have /var/run before and after /var is mounted
<Keybuk> in fact, even as /var is mounting, /var/run is still present
<edgecase> ok, juggling is acceptable if you don't drop the ball
<Keybuk> *shrug*
<Keybuk> if the boot sequence drops any ball, you can't boot
<edgecase> badness++
<Keybuk> why?
<Keybuk> just write things to be reliable
<edgecase> i'll just assume "even as /var is mounting, /var/run is still present" is relable, moving on...
<Keybuk> yes
<Keybuk> I could teach a course on Theory of Atomic Operations in Operating Systems 101 :p
<Keybuk> I think about them a lot
<Keybuk> the details:
<edgecase> oh thank god
<Keybuk>   we always have a /var/run directory on the root filesystem, under the /var directory
<Keybuk>   we mount /var/run there on the first pass
<Keybuk>   then when it's time to mount /var, we actually mount it somewhere else (/dev/.var I think :P)
<edgecase> is there a mount --under option or something?
<Keybuk>   we bind mount the current /var/run to /dev/.var/run
<Keybuk> so now it's available at both /var/run and /dev/.var/run
<Keybuk>   we then move the /dev/.var mount to /var
<edgecase> all atomic?
<Keybuk> each of those is atomic yes
<Keybuk> since a mount() operation holds the VFS lock
<edgecase> ooh, snap!
<Keybuk> mountinfo will show /var/run mounted twice
<Keybuk> with different parent mounts
<Keybuk> if you unmount /var, for whatever reason, /var/run is still mounted under it
<edgecase> i find no mountinfo or man 7 filesystem
<Keybuk> edgecase: are you on lucid?
<edgecase> karmic
<edgecase> i guess i need to be bleeding edge to get bleeding edge
<Keybuk> ah, I think I added that manpage in lucid
<edgecase> i'll get lucid on a box shortly
<edgecase> so i can discuss current state of things
<Keybuk> mountinfo => /proc/self/mountinfo
<edgecase> ah /proc/mounts on steroids
<edgecase> ok so, what provides /proc and /sys, upstart, before running any scripts?
<Keybuk> I don't quite understand your question
<Keybuk> you asked me what kind of trees apples, oranges and buses grow on :p
<edgecase> earlier you said assume /proc and /sys when running upstart
<Keybuk> yes
<edgecase> so what mounts them?
<Keybuk> init
<edgecase> before running any "start on startup" jobs?
<Keybuk> yup
<edgecase> ok just getting my bearings
<Keybuk> Upstart uses /proc/self/fd to run shell scripts
<Keybuk> so it needs /proc mounted
<Keybuk> and since it's probably going to need /sys at some point soon, I figured I'd mount that too
<Keybuk> /dev gets mounted by the kernel these days
<edgecase> is there a formal definition of state when "startup" event fires?
<edgecase> ie "you get root /proc and /sys"
<edgecase> and "but don't assume /var and /usr etc"
<Keybuk> no written down one I guess
<edgecase> use the source luke
<Keybuk> the root filesystem is read-only
<Keybuk> you have /proc and /sys
<Keybuk> you probably have /dev
<edgecase> reading source takes time tho
<Keybuk> you have /bin, /sbin, /lib and /etc
<Keybuk> but nothing else filesystem wise
<edgecase> aside, i'm thinking mountall should be broken up, it's a syncronisation point, which defeats some parallelism
<Keybuk> it isn't a synchronisation point
<Keybuk> that's kinda the idea
<edgecase> make a dummy job with the same syncronisation properties for dumb legacy jobs,
<Keybuk> it replaces the shell script nightmares we had before that were
<edgecase> but let smart jobs pick off say just root fs being rw
<Keybuk> they can
<Keybuk>   on mounted MOUNTPOINT=/
<edgecase> mountall emits events?
<edgecase> oh vfs emits mount events i'm guessing
<Keybuk> no, mountall emits them
<edgecase> back to upstart?
<Keybuk> yes
<Keybuk> like filesystem for a start ;)
<edgecase> ok, then back to all the emits in mountall.conf...
<edgecase> any definition what they mean?
<Keybuk> emits virtual-filesystems
<Keybuk> emits local-filesystems
<Keybuk> emits remote-filesystems
<Keybuk> emits all-swaps
<Keybuk> emits filesystem
<Keybuk> emits mounting
<Keybuk> emits mounted
<Keybuk> (from lucid)
<Keybuk> for any of those, "man 7 EVENT-NAME"
<Keybuk> (in lucid)
<edgecase> ok will look there
<Keybuk> I've tried to be reasonable well behaved about writing man pages for events
<edgecase> that's why i say sync point, they all get emitted in parallel
<Keybuk> they don't
<edgecase> but only after *all* of mountall is done
<Keybuk> no they don't
<Keybuk> they get emitted at completely different times
<edgecase> ok so it's a declaration, "may emit..."
<Keybuk> yes
<edgecase> right-o
<Keybuk> did you read "man 5 init" ? :)
<Keybuk>        emits EVENT...
<Keybuk>               All processes on the system are free to emit their own events by
<Keybuk>               using the initctl(8) tool, or by communicating directly with the
<Keybuk>               init(8) daemon.
<Keybuk>               This  stanza  allows  a job to document in its job configuration
<Keybuk>               what events it emits itself, and may be useful for graphing posâ
<edgecase> i see now that i'm way to pessimistic coming into this
<Keybuk>               sible transitions.
<Keybuk> emits is basically there to make writing that graphing tool you were asking about possible ;)
<Keybuk> documentation only
<edgecase> ok things look in order then
<edgecase> i'm thinking then that just the .conf files can be optimized, to depend only on what they *really* need,
<edgecase> to enable some more unusual use-cases than "user logs in then unlocks WLAN key..."
<Keybuk> yes, certainly
<edgecase> like, network booting etc
<Keybuk> the difficulty comes in adapting to users
<Keybuk> like we could write the job to actually depend on /usr rather than filesystem
<edgecase> exactly
<Keybuk> but that wouldn't work if a user decided to put a different filesystem for /usr/bin and for /usr/lib
<edgecase> FHS doesn't allow that does it?
<Keybuk> yes it does
<Keybuk> FHS only says directories you shouldn't put on different filesystems
<edgecase> ok well on that topic,
<Keybuk> things like /usr and /var are free-for-alls
<edgecase> windows has "reparse points"...
<Keybuk> it's pretty common for example to have /var/lib or /var/spool on different drives
<edgecase> true
<edgecase> with unix, a (empty) directory *could* be a mount point, no way to know
<edgecase> you can read fstab, and hope it's in sync with reality
<Keybuk> reparse points => those are basically crazy symlinks iirc?
<edgecase> takes place of fstab entries
<edgecase> you get file dir symlink, and now reparse point fs object
<edgecase> so, it's like an empty dir, because it has a name, 
<Keybuk> actually it might not even be in fstab
<Keybuk> e.g. if you use LABEL to mean mountpoint
<Keybuk> or if it's a removable device under /media
<edgecase> but it's a type explicityly marking it as a mount point
<edgecase> ok then that's an arguement for having reparse points in linux
<edgecase> although 75% of the unix world will issue a death warrant to you
<edgecase> for saying it
<edgecase> the cases that are in fstab could be handled
<edgecase> maybe that's a starting point
<edgecase> but it's not /usr i'm interested in... but rather starting things that need root fs read-only and /var/run available, starting those asap
<edgecase> anyhow i see that upstart is thankfully ahead of my expectations, i need to do some more reading now
<edgecase> thanks for the good work!
<Keybuk> local-filesystems should be ok for those on Ubuntu
<Keybuk> ah
<Keybuk> sorry
<Keybuk> virtual-filesystems
<Keybuk> virtual-filesystems means you have root read-only, and all the things like /var/run and stuff
<Keybuk> we use it to start things like udev, dbus, etc.
<edgecase> k thx
<wasabi> oh hi/bye edgecase
<halfline> sadmac: did you ever look at the display manager selection thing more?
<halfline> i mean http://rstrode.fedorapeople.org/quest_to_find_a_dm.txt
#upstart 2010-03-17
<nokia3510> hello
<nokia3510> I'm having a luks issue and I don't know for sure if it's upstart related or not, maybe you could confirm my hunch
<nokia3510> I'm testing luks in Vbox-Karmic, fstab and crypttab are setup properly, manual mount works just fine
<nokia3510> however, when booting karmic, the boot process stops for a moment asking for luks password, yet it continues before I finish typing the pass and pressing enter, leaving the luks hdd unmounted
<nokia3510> i've done similar tests in mandriva, opensuse and fedora - for learning purposes - discovered a few distro specific quirks but finally all's setup properly
<nokia3510> in karmic however, I dunno now where's the problem really, since it reaches the pass entering state but automatically continues after a few seconds regardless of my input
<sadmac2> nokia3510: that's an ubuntu question not an upstart question. even if upstart is involved the problem is specific to their configuration of upstart.
<nokia3510> thanks sadmac2 for clarifying it for me
<sadmac2> nokia3510: I'd try #ubuntu if you can, or the appropriate bug tracker
<nokia3510>  the #ubuntu is full of "halp...my win7 has an ubuntu issue"
<nokia3510> I use fedora on daily basis but never had much to do with upstart
<nokia3510> also I'm more at leisure with fedora's cli, not debian
<nokia3510> but thanks anyway, I'll find some way to digg more info about upstart configs in karmic
<tauren> it seems that there is no value for $USER when processes in a user crontab file run. is that correct?
<tauren> oops, wrong window. sorry.
<edgecase1> Keybuk, hey what about upstart knowing state of system before it's started... ie netbooting leaves NIC configured when starting /sbin/init?
<Keybuk> what about it? :)
<edgecase1> does it do that now, or any plans to...
<edgecase1> i see 2 options... pass the info to upstart, or probe the system to figure it out
<edgecase1> i think one of the blueprints is talking about that
<Keybuk> Upstart doesn't know anything about NICs ...
<Keybuk> so why would it need to know about their state
<edgecase1> that's just one use-case for the functionality of knowing system state
<Keybuk> what other kind of system state?
<Keybuk> all Upstart knows about is pids
<edgecase1> the ifup/ifdown scripts know about NIC state
<edgecase1> well vaguely i thought that nic state might be equal to started/starting state of the network.conf or similar jobs
<edgecase1> ok I think i'll assume probing method, until i'm thinking clearly about it
<Keybuk> it's definitely something to think about
<Keybuk> transfer of state from initramfs
<Keybuk> we have a sneaky hacky patch in ubuntu
<Keybuk> for each file /dev/.initramfs/*.pid, if there is an equivalent /etc/init/*.conf then Upstart marks the job as running with the pid in the pid file
<wasabi> hi edgecase1
<wasabi> Keybuk, you have an infrastructure for inplace upgrades of upstart, right? :)
<wasabi> Sounds dangerous, but use that to exchange state.
<Keybuk> no
<Keybuk> but that's one of the ideas
<wasabi> Hmm. Thought there was a way to dump the state out of it and have it exec a new version of itself.
<wasabi> Or something.
<Keybuk> hasn't been for ages
<Keybuk> it's hard to maintain it while redeveloping upstart
<wasabi> I haven't paid attention for ages. =(
<sadmac> Keybuk: wrt dumping object state, I had thoughts to implement an nih-json on top of nih-parse when it was done, and then produce a complimentary nih-serialize
<Keybuk> json was my idea too
<Keybuk> it's a nice format
<Keybuk> you can read it quickly
<Keybuk> you can debug it
<Keybuk> etc.
<sadmac> indeed
<sadmac> nih-serialize is still a very rough idea I'm having. not sure what I would want it to be.
<Keybuk> I'd vaguely thought as well that root should be able to get a dump of all init state this way
<Keybuk> e.g. why a job hasn't started => get the json of the state to see
<sadmac> Keybuk: I'd hope that'd be a last-resort measure. There should be more straightforward presentations of that information for hyoomans
<sadmac> or at least most of them
<Keybuk> a client could interpret that
<Keybuk> ie. initctl
<sadmac> I'd see a json state dump as being one step before a core dump in your debugging tool box
<Keybuk> it just seemed like a nice way to transfer data
<sadmac> ah
<Keybuk> right
<sadmac> yeah I could see that
<sadmac> Keybuk: my only worry would be app writers would forego the much saner dbus ways of getting (some of) that information and start trying to do everything that way.
<Keybuk> yeah that's true
<sadmac> python programers lurve them some json
<Keybuk> which is ironic really
<sadmac> I'm a ruby programmer, so I lurve me some YAML. But its context-sensitive, so there's no fucking way I'm writing a parser for it.
<edgecase1> wasabiiiiiiiiiII!
<sadmac> Keybuk: a blog commenter suggested we use augeas to do config parsing
<sadmac> just thought I'd mention it
<Keybuk> what's that?
<edgecase1> how many MB of unaudited code would that add :P
<sadmac> Keybuk: its a general-purpose config file parser/editor tool. Its designed to give you a safe api to do things like update grub.conf. He's suggesting we use it to parse our own config files, with the added benefit that other tools can introspect our config files via the same grammar definition.
<sadmac> Keybuk: its intriguing. edgecase1 has a big point though. Its kinda big afaict
<notting> is the commenter dlutter himself?
<sadmac> notting: I think it was. I remember he said "shameless plug" at the start
<sadmac> notting: yep. it was.
<Keybuk> sadmac: ask him what his test suite code coverage is :p
<sadmac> Keybuk: done.
<edgecase1> what's librt used for?
<edgecase1> just async io?
<Keybuk> sadmac: also, obviously, what his approach to NULL returns from malloc and realloc are :p
<sadmac> Keybuk: if we seriously think its a good idea we could audit his code.
<sadmac> Keybuk: the lenses themselves appear to have a builtin testing framework
<Keybuk> without looking, I can't tell
<edgecase1> what about an external utility to parse, that just connects like initctl cmd does, to feed in the objects
<edgecase1> keep /sbin/init small
<edgecase1> it links libc, librt, libdbus, libpthread now
<edgecase1> is librt needed?
<sadmac> why is it linking libpthread?
<sadmac> librt might come with glibc in some cases
<Keybuk> cause librt does
<Keybuk> and I think libdbus does
<sadmac> Keybuk: augeas.net
<sadmac> if you want to look into that more
 * sadmac can't really be the one to decide that he just wrote a parser for no good reason
<ion> Erlang has an incredibly good facility for runtime upgrades of everything. It sort of depends on all the state being on the stack, though.
<Keybuk> sadmac: will look in a bit
<edgecase1> the trick is changing the in-core format on upgrade
<Keybuk> currently debugging a plymouth issue that causes our beta installer to crash X :)
<edgecase1> is anyone working on updating bridge and vlan networking to use upstart?
<sadmac> edgecase1: in which distro? :)
<edgecase1> ubuntu... but if any distro is, that'd be useful
<sadmac> edgecase1: from fedora's side I'm pretty sure init is going to get out of that business altogether and let network manager take it over
<edgecase1> for servers too?
<sadmac> edgecase1: yep
<sadmac> edgecase1: network manager is growing a command line in F13
<edgecase1> ic
 * sadmac needs to play with nmcli a little
<edgecase1> i wonder what the target audience is... i suspect it will have a smaller scope than "anything linux networking can do"
<edgecase1> nmcli might end up as clone of cisco, or quagga
<sadmac> edgecase1: maybe at the moment. The idea is that it should replace everything you ever loved though.
<edgecase1> maybe the networking "power-users" will just use bash scripts and be forced to rip out network-manager
<edgecase1> running a BGP router makes me skeptical of things, i'll admit to bias
<edgecase1> is network manager sending events to upstart already?
<sadmac> edgecase1: no. that will come too. mostly to replace the old "dispatcher" stuff
<edgecase1> i wonder if the economics are what keeps the advanced networking out of "nice" tools like network-manager... there are too few BGP routers vs webservers vs laptops to get developer interest
<edgecase1> might be worth some thought about how quagga could leverage what NM does well
<sadmac> edgecase1: the laptops needed it most. they got their features first./
<sadmac> edgecase1: but its all coming
<edgecase1> exactly
<edgecase1> BGP routers are like Waiting for Gaudot though
<sadmac> edgecase1: that's why fedora does things like rip out all the old bash scripts (not that we're doing that yet). sure its a pain in the ass and people will flame and things will break. But that's what will make it work :)
<edgecase1> reasonable compromise might be to fine some mutual agreement so NM doesn't trample quagga and vice-versa
<edgecase1> netlink is pretty good for sharing network stuff
<edgecase1> only conflict is if 2 daemons want to set the IP addrs of the same interface
<edgecase1> there is no arbiter saying NM or quagga or bash scripts "own" a certain interface
<edgecase1> i immagine there's #network-manager for that discussion?
<sadmac> edgecase1: I'm guessing
<sadmac> edgecase1: You should talk to Dan Williams about this stuff
<edgecase1> he at ubuntu or redhat or ?
<sadmac> edgecase1: red hat
<sadmac> edgecase1: he's upstream for network manager though
<edgecase1> how can i reach him?
<edgecase1> upstream, what's the significance of that?
<edgecase1> distro agnostic?
<Keybuk> ostensibly
<Keybuk> when RH people say "upstream", they're either
<Keybuk>  - complaining that Ubuntu didn't use RH's code
<sadmac> edgecase1: dcbw
<Keybuk>  - pretending that Fedora's packages maintained by RH developers aren't "authorative" :p
<Keybuk>  - avoiding "patches welcome"
<Keybuk> <g>
<sadmac> edgecase1: dcbw on freenode
<sadmac> edgecase1: but dunno if he's on
<edgecase1> i'll check out #nm
<sadmac> Keybuk: just because you guys are trying to make a proprietary linux by making nobody /want/ your patches....
<Keybuk> sadmac: says the guys writing GNOME Shell ;-)
<notting> dcbw works on the networking stack. makes 100% IRC availability tricky
<edgecase1> physician heal thyself!
<sadmac> Keybuk: that's going to be part of gnome 3.
<Keybuk> sadmac: uh-huh :p
<Keybuk> which is released when? :p
<Keybuk> wasn't that supposed to be last week? :p
<notting> no, that was upstart 1.0! (we all can play this game... ;) )
<Keybuk> edgecase1: this is just inter-distro banter ;p  we like each other really
<Keybuk> we all agree to hate Mandriva
<sadmac> Keybuk: this is why I love that we /use/ upstart. Its the giant logical fallacy in your argument. Or maybe the fact that you take our patches is the giant logical fallacy in our argument. The point I'm trying to make is I have a giant logical phallus.
<edgecase1> heh
<Keybuk> sadmac: :D
<Keybuk> if it wasn't for Fedora, we'd have to actually write our own code :-/
<sadmac> and now its waaay past lunch time and I haven't found anyone to eat with. To the lonely food!
<Keybuk> talking of which
 * Keybuk goes back to debugging broken Fedora code
<Keybuk> yay plymouth! :D
<Keybuk> oh arse
<Keybuk> see, I go and sarcastically accuse plymouth of being crap
<Keybuk> but it turns out that the bug is actually in upstart!
<notting> sadmac: did you ever make progress on the display manager starting weirdness?
<sadmac> notting: which weirdness?
<notting> where we were trying to have both generic and specific events, and have the specific one  1) start when the generic one is called with an argument 2) call 'stop <generic>' in its post-start
<notting> it wasn't working 
<sadmac> notting: oh yeah. the way I said to do it should have worked I believe. Keybuk suggested the bug may have already been filed.
<Keybuk> I liked what halfline said
<Keybuk> have a display manager task
<Keybuk> gdm, kdm, etc. start on starting display-manager
<Keybuk> check if they want to run, and if they do, stop display-manager so that fallback doesn't
<notting> yeah. didn't work.
<sadmac> Keybuk: right, that's what we were doing. We did the latter "if they do" part by putting stop display-manager in the post-start of gdm/kdm/etc
<Keybuk> it didn't work?
<sadmac> Keybuk: iirc display-manager remained running and the service killed itself
<Keybuk> that's odd
<Keybuk> it should work
<Keybuk> we do tricks likat
<Keybuk> like that
<Keybuk> that's how our installer works, for example
<sadmac> Keybuk: I mentioned it to you I think, and you said there was a filed bug from ubuntu, though I don't know if we were totally clear on what was happening.
<notting> Keybuk: mail bounced.
<sadmac> and I get all the launchpad mail, so I would have seen it I'd think
<Keybuk> oh
<Keybuk> bar.conf shouldn't be "task" no?
<Keybuk> shouldn't make much difference tho
<sadmac> notting: was it?
<notting> i don't think that made a difference... it was just that way as it made testing it much simpler if it didn't respawn all the time
<notting> but i can dig up a test rig and try again
<halfline> for reference, previous discussion about this is here: http://rstrode.fedorapeople.org/quest_to_find_a_dm.txt
<Keybuk> http://pastebin.ubuntu.com/396866/
<notting> this also, for all i know, could have been fixed somewhere between 0.6.3 and 0.6.5
<Keybuk> Mar 17 18:53:47 quest init: bar post-start process (30448) terminated with status 1
<Keybuk> NO SUCH INSTANCE innit
<sadmac> oh. that could explain it.
<sadmac> why isn't it finding er then?
<Keybuk> I think
<Keybuk> hmm
<notting> foo hasn't started enough yet for there to be something to stop?
<Keybuk> shouldn't be, goal should still be same
<sadmac> no it should still find the instance...
<Keybuk> quest scott% cat /tmp/bar-ps.30475
<Keybuk> initctl: invalid option: --no-wait
<Keybuk> Try `initctl --help' for more information.
<notting> ok, *that's* a 0.6.3 vs 0.6.5 difference :)
<Keybuk> Mar 17 18:57:29 quest init: Connection from private client
<Keybuk> Mar 17 18:57:30 quest init: foo goal changed from start to stop
<Keybuk> no
<Keybuk> --no-wait has to come after stop
<Keybuk> initctl stop --no-wait foo
<Keybuk> that's your bug
<sadmac> wow. that was silly
<notting> seriously? it's positional?
<Keybuk> it follows the same convention as svn, git, etc.
<Keybuk> initctl <global options> command <command or global options> ...
<halfline> can't you just run "stop" instead of "initctl stop" ?
<Keybuk> halfline: yes ;)
<notting> i always wondered whether some other package shoved a start/stop command in $PATH, though. meh.
<notting> can always pass the full path
<Keybuk> plus Upstart always runs in sane PATH anyway
<Keybuk> admittedly, /sbin is near the end
<sadmac> notting: I wanted to recommend a patch also to unset UPSTART_JOB at the top of /etc/rc . If its set anything in the init scripts that runs "start" or "stop" without arguments will derail the whole runlevel transition. The oVirt guys managed to do this with a typo just the other day. Probably safer to make it go away.
 * Keybuk goes back to fixing the upstart-takes-a-chainsaw-to-plymouth's-vt bug that's blocking Ubuntu Î²1 ;-)
<Keybuk> surprised you guys haven't noticed that one yet <g>
<Keybuk> maybe you have
<Keybuk> maybe *that's* why plymouth sets the console to unbuffered mode before every write ;-)
<sadmac> Keybuk: I've got one now where using the serial console makes us kernel panic. plautrba has an upstart patch that fixes it, but nhorman came back and said "wait, I don't know if upstart is where we should fix that one..."
<Keybuk> what's the patch?
<halfline> yea plymouth puts it back in unbuffered more for every write because for i did that there were cases where it'd get thrown back into cooked mode
<halfline> i don't remember the details, that change went in a long time ago
<Keybuk> halfline: like when you're starting X
<sadmac> Keybuk: https://bugzilla.redhat.com/attachment.cgi?id=399621
<Keybuk> and doing a transition
<sadmac> doesn't look right to me
<Keybuk> and it's very interesting
<sadmac> oh, I don't know if you can even see that
<halfline> Keybuk: nah, remember we quit plymouth before X starts right now
<Keybuk> what happens when X has its VT changed back into raw mode
<Keybuk> Enter looks a bit like C-\ <char>
<Keybuk> it's amazing what C-\ does to X ;-)
<Keybuk> halfline: :D
<Keybuk> sadmac: You are not authorized to access bug #568418.
<halfline> really? that's bizarre
<sadmac> Keybuk: that makes sense. lemme pastebin that...
<Keybuk> halfline: we took out the set_unbuffered a while back
<Keybuk> but just had another occurance of a similar bug
<Keybuk> plymouth sets console to uncooked
<Keybuk> upstart resets it cooked
<Keybuk> X resets it to uncooked
<sadmac> notting: also why does plautrba have upstart in a git repo? I hate bzr too, but... come on.
<Keybuk> plymouth resets it to cooked on its way out
<notting> sadmac: i dunno
<Keybuk> X dies when you press Enter ;-)
<sadmac> Keybuk: http://pastebin.com/zu4n14gG
<halfline> dies with SIGQUIT ?
<sadmac> Keybuk: looks like he fixed it the way debian fixed those SSL warnings awhile back :)
<Keybuk> halfline: yup
<Keybuk> sadmac: no idea why that would avoid a panic
<halfline> i wonder if plymouth's "put back in cooked mode" code is wrong...
<Keybuk> sadmac: that's removing the code that guards against SysRq-K from killing upstart
<Keybuk> halfline: no, it isn't - it's just inconveniently timed
<halfline> it's hard for me to bridge "in cooked mode" to "enter sends sigquit"
<Keybuk> well sorry
<Keybuk> there is a small plymouth bug
<Keybuk> but yeah, apparently enter and sigquit look very similar to X
<halfline> hmm looking at the tcsetattr man page
<halfline> it appears  picked my terminal settngs
<halfline> by taking the cfmakeraw settings and invertng them
<halfline> this was probably not the wisest move
<Keybuk> heh
<halfline> time to switch it to use the values from stty 's sane mode
 * Keybuk is trying to remember why upstart sets terminal settings in the first place
<sadmac> Keybuk: I remember a bug when we first used upstart where I think the gettys were set uncooked, and you couldn't actually hit enter to punch in your username
<sadmac> forget what made that go away
<sadmac> notting: do you have a quick reproduction environment for 568418?
 * Keybuk afk for about an hour, will read scrollback
<sadmac> notting: if not any tips on testing serial+kvm?
<notting> sadmac: haven't seen it, but haven't tried to reproduce
<notting> serial + kvm is a PITA
<notting> dig up the magic qemu flags and start it by hand
<halfline> virt-manager has a serial console display... isn't addng console=ttyS0 enough?
<halfline> on kernel cmdline i mean
<notting> halfline: i'm told due to perms it doesn't actually work in virt-manager yet
<halfline> ah
<halfline> i had some fun with virt manager permissions the other day.  i had to vim /usr/lib*/python*/site-packages/something-or-other and add a fchmod call to get to create a vm
<sadmac> halfline: my option to switch to serial console is greyed out in the menu. guess that's the solution
<notting> cole said it theoretically works if you run virt-manager as root. 
<sadmac> hmm. might try that
#upstart 2010-03-18
<bottiger> I've tried to manage my upstart services with both "rcconf" and "bum" to make some services start (or not start) automatically. However, it simply does not work. If I disable "mysql" it shows up as disables in both rcconf and bum, but it still starts up when I boot
<bottiger> any idea what the problem could be
<sadmac2> bottiger: that's more of a debian/ubuntu question
<donEduardo> hi there.
<donEduardo> is this the correct group for upstart in ubuntu?
<donEduardo> or is this group rather general?
<Keybuk> this is the general group for the different distribution maintainers developing upstart
<Keybuk> if you're having ubuntu problems, you should ask in #ubuntu
<donEduardo> if got an upstart problem in ubuntu 10.04 alpha... ok, i'll try at #ubuntu
<donEduardo> s/if/i've
<Ng> so process supervision :)
<Ng> is there any way for upstart to indicate that something has been respawned other than its syslog entries?
<Ng> (I'm thinking that as a sysadmin I'd want realtime alerts that $IMPORTANTDAEMON has died and been restarted, ideally not by having to do realtime syslog analysis)
<sadmac> Ng: you could detect the starting event from another job and have that fire off whatever
<Ng> oh interesting
<Ng> oh the starting event, not a specific respawning event?
<Ng> actually what I'd care about is the *dying* of a process, but that's implied by it having been restarted ;)
<sadmac> Ng: I think you get a stopping event too
<sadmac> there's no respawning event though
<sadmac> you definitely don't get a stopped event when respawning. it doesn't make it all the way down.
<Ng> it might be a little annoying if booting a machine triggered a bunch of alerts ;)
<wasabi> `script` stanza could use an extension:
<wasabi> script /bin/bash
<wasabi> \tfoo
<wasabi> end script
<Keybuk> but then we don't know whether what you give supports /proc/self/fd
<Keybuk> and we don't know whether it supports "-e"
<wasabi> True.
<Keybuk> we don't know whether it supports being able to give single commands with "-c"
<wasabi> I'd probably just say: yeah. if it support -e, you have to add it
<Keybuk> I like the fact that script -es by default
<Keybuk> script sh
<Keybuk>  ...
<Keybuk> end script
<Keybuk> would bypass that
<Keybuk> and be remarkably inconsistent
<wasabi> that is true. 
<wasabi> well, you see where I'm going.
<wasabi> script python
<wasabi> blah
<wasabi> I'd probably just say adopt the same semantics any +x file has
<sadmac> Keybuk: what if we allowed you to pipe part of the job definition to the exec stanza's argument?
<sadmac> exec python <<<END
<sadmac> import foo
<sadmac> main()
<sadmac> END
<wasabi> That looks weird.
<wasabi> It might be an argument for not using 'script', but instead extending 'exec' into a block stanza./
<wasabi> with script being locked to sh -e
<wasabi> s
<sadmac> wasabi: it does, but it skirts most of Keybuk's arguments semantically. I'm in the habit of doing this. Eventually it results in Really Cool Things.
<wasabi> exec python
<wasabi>   import foo
<wasabi>   main()
<wasabi> end exec
<wasabi> Since exec is already defined as not passing any arguments.
<wasabi> I think it might be more appropiate too
<sadmac> that makes the grammar ambiguous if you keep the one-liner exec
<wasabi> as 'script' might not always even be the right name for it.
<Keybuk> sadmac: I'm just wondering to myself what that exec line would do now ;-)
<Keybuk> since technically exec is just a shortcut for
<Keybuk> script
<Keybuk>   exec ...
<Keybuk> end script
<Keybuk> ;-)
<wasabi> Heh
<wasabi> what about a utility that reads from stdin to process commands... that you want executed every now and then
<wasabi> but it's clearly not a scripting language
<sadmac> Keybuk: it would do the same as always, but make stdin a pipe first, then it'd write the python script into it
<wasabi> shit, nc
<wasabi> exec nc host
<wasabi> \tstuff
<wasabi> end exec
<Keybuk> right
<Keybuk> there's three different types of program
<Keybuk> 1) those that take commands on command-line, e.g. sh -c "foo;bar;baz"
<sadmac> wasabi: I spent a week in my security class trying to find ways to trick users into doing that. Making it easier to do voluntarily seems wrong
<Keybuk> 2) those that take a script filename on command-line, e.g. sh /foo/bar.sh
<wasabi> heh
<wasabi> sendmail then. :)
<Keybuk> 3) those that take commands on standard input
<wasabi> exec sendmail admin@isillc.com
<wasabi>   shit's busted
<wasabi> end exec
<sadmac> Keybuk: shock moment, what if we just supported shebang lines
<sadmac> script
<sadmac> #! /bin/python
<sadmac> etc
<sadmac> end script
<wasabi> heh.
<Keybuk> sadmac: no way to execute that ;-)
<Keybuk> chmod +x /proc/self/fd/4
<Keybuk> doesn't quite work
<wasabi> What about symbols in front of the cmd name to specify how the body is passed to it?
<Keybuk> symbols would be ick
<sadmac> what does the command have to do to supprt /proc/self/fd?
<Keybuk> but I like the idea that you should be able to run things with stdin
<wasabi> maybe. but there's um
<wasabi> what's the word for it
<Keybuk> I already want to be able to run things and capture stdout after all
<wasabi> crap. brain dead.
<Keybuk> sadmac: to do #! you need a filename
<wasabi> exec - sendmail jhaltom@isillc.com
<wasabi>  foo
<wasabi> end exec
<wasabi> that gets passed to stdin
<wasabi> (making stuff up)
<Keybuk> why not perlish?
<wasabi> because i don't know perl.
<Keybuk> exec |sendmail jhaltom@isillc.com
<wasabi> heh
<wasabi> That's sort ofe stablished elsewhere too
<wasabi> /etc/aliases
<sadmac> Keybuk: same reason we couldn't do
<sadmac> script /bin/python
<sadmac> end script
<sadmac> then
<Keybuk> one sec, changing machines
<sadmac> ah, wing-commander. I missed that box
<wasabi> exec >sendmail jhaltom@isillc.com
<wasabi> or | I guess
<wasabi> Got me
<Keybuk> sadmac: lol, "missed it" ?
<wasabi> I don't like symbols like that.
<sadmac> Keybuk: there's a lot you don't know that happened between me and your computer.
<sadmac> Keybuk: don't judge us. we were young. we did what felt right.
<Keybuk> should I dunk my laptop in bleach?
<sadmac> Keybuk: yes. and you might want to get a new refridgerator.
<Keybuk> syntax aside for a moment
<Keybuk> what magic input/output/commandline things should we support here?
<sadmac> stdin makes sense
<sadmac> whatever the most standard syntax is, it should work by the same mechanism as #!, that is if an interpreter works in a #! line it should work in a job definition with minimal effort
<Keybuk> right #! is "append filename to the #! line"
<Keybuk> which should mean we can append /proc/self/fd/N
<sadmac> really. thought it was pipe-through
<Keybuk> no, cause you can do
<Keybuk> echo "#!/usr/bin/sendmail" > casey.dahlin@redhat.com
<Keybuk> chmod +x !$
<sadmac> yeah, you're right
<Keybuk> ./casey.dahlin@redhat.com
<Keybuk> Subject: foo
<Keybuk> etc.
<wasabi> stdin and last argument make sense to me.
<wasabi> anything else can be done by hand
<wasabi> exec /proc/fd/0
<wasabi> exec foo --name=/proc/fd/0 anyways
<Keybuk> I also want to support capture-standard-output
<wasabi> same.
<Keybuk> for programs that write FOO=bar as standard output
<wasabi> Where would you send it, though? :)
<Keybuk> it'd be part of the job's environment
<sadmac> Keybuk: that's always felt a bit special to me
<wasabi> Hmm.
<Keybuk> sadmac: it's used by just about everything "agent-esque"
<Keybuk> dbus downards
<wasabi> Yeah. That would be much nicer.
<wasabi> Simply scrape the env exported by dbus when launching a dbus service
<wasabi> no work done.
<wasabi> except to export it in dbus
<wasabi> and make sure your job somehow fires with that env.
<Keybuk> right, dbus-daemon writes its session address and stuff to stdout
<sadmac> Keybuk: I like a more general solution
<Keybuk> so any job with "while dbus-daemon" would have that in its environment
<wasabi> Yeah. That's rad. 
<sadmac> exec dbus-session-bus | xargs upstart-set
<Keybuk> xargs? :)
<Keybuk> I guess
<Keybuk> then I have to care about process groups
<sadmac> yeah, the forking is a bit funny around that
<Keybuk> we do need some kind of initctl to set environment though
<wasabi> I'm fine with parsing name=value pairs.
<wasabi> that's super standard.
<wasabi> It would be better in some way if you could have dbus communicate in another way that didn't involve any parsing
<Keybuk> lots of people seem to try and parse things in pre-start then punt to exec
<Keybuk> but I think that's partly because exec sucks and you can't use cat if you're using fork-following
<sadmac> Keybuk: look at augeas any? speaking of parsing.
<Keybuk> sadmac: no, not yet
<Keybuk> but I have now sent all my patches to halfline, so I suck less, so can look at that in a bit
<sadmac> cool
<Keybuk> the good news is we found a major bug with pre-stop in upstart ;)
<Keybuk> (as a result of plymouth issues)
<sadmac> I'm figuring this JSON stuff we've been discussing will need a parser anyway, so I'm going to complete nih-parse either way
<Keybuk> not crasher - as in "clearly this approach is insane"
<sadmac> ah, cool
<Keybuk> and pre-stop was the only thing stopping me from getting rid of all four scripts
<Keybuk> so now I can get rid of all four scripts and be happy
<sadmac> Keybuk: so we have just one job now?
<wasabi> JSON stuff
<wasabi> So, JSON parsing will be in upstart.
<wasabi> So it's hardly surprising that name=value parsing is
<sadmac> wasabi: yeah, talking about using it for cross-upgrade stuff
<Keybuk> just one process per job
<Keybuk> so job and process become the same thing
<sadmac> name=value is hardly even parsing. Its regular for chrissake.
<wasabi> Yeah
<Keybuk> but multiple jobs/processes defined in one conf file
<Keybuk> given what we talked about the other day:
<Keybuk>   on foo
<Keybuk>   exec ...
<Keybuk> it doesn't seem unreasonable to have a kinda "on self"
<Keybuk>   on self starting
<Keybuk>   exec ...
<Keybuk> that's a task as we chatted about
<Keybuk> so that's basically identical to the current pre-start script
<sadmac> Keybuk: where do names come from then?
<Keybuk> sadmac: names?
<sadmac> Keybuk: yes, names for jobs
<Keybuk> right, so then i got thinking well
<sadmac> Keybuk: they come from file names now
<Keybuk>   pre-start exec ...
<Keybuk> that's a named process called "pre-start"
<Keybuk>   reload exec ...
<wasabi> Oh. Odd.
<Keybuk> those would fire automatically
<Keybuk> it's not "there" yet
<Keybuk> (syntaxwise)
<Keybuk> but I think it works process-wise
<sadmac> so with the hierarchy thing we get all of it
<sadmac> foo exec whatever in a file called stuff.conf creates a stuff foo job
<sadmac> which is a silly name, but real world examples would make sense
<Keybuk> right exactly
<sadmac> we can parse it, to be sure.
 * sadmac needs to finish up the parse tool
<sadmac> my code quality has been wildly inconsistent. I'm going to throw away what I'm writing, but then maybe I'll copy paste some of it. I can't decide if I give a shit whether it leaks memory or not.
<sadmac> the joys of writing a program who's first and only task is to rewrite itself :)
<Keybuk> ll
<Keybuk> lol
<Keybuk> memory's cheap these days
<Keybuk> they can buy more
<sadmac> the good news is it won't need many tests. It tests itself just by being compiled :)
<sadmac> Keybuk: that's not funny. Java people still say that with a straight face
<sadmac> no wonder 2/3 the core dumps I get in during $dayjob report more memory than my hard disk.
<Keybuk> heh
<wasabi> trying to do this: which is failing. not sure why.
<wasabi> script
<wasabi> \t /bin/bash << EOF
<wasabi> bunch of crap. blah blah.
<wasabi> EOF
<wasabi> end script
<wasabi> Seems to break when I add my first complicated line of script: l=( backup users profiles )
<wasabi> Can't imagine why any of it would need to be escaped for any reason
<Keybuk> two shells?
<Keybuk> you need to escape it from the first shell for the sceond to see it
<Keybuk> script
<wasabi> sh is reading from a file in proc, right?
<Keybuk>   FOO=bar
<Keybuk>   /bin/bash << EOF
<Keybuk>   FOO=baz
<Keybuk>   echo $FOO
<Keybuk>   EOF
<Keybuk> end script
<Keybuk> will echo bar not baz
<Keybuk> wasabi: yes
<wasabi> I see.
<Keybuk> the outer shell applies full expansion to everything
<Keybuk> even the bits between << EOF and EOF
<wasabi> still no worky though
<wasabi> /bin/bash << EOF
<wasabi> FOO=bar
<wasabi> EOF
<wasabi> fails. returns 2
<wasabi> << isn't like, not sh compatible, is it?
<Keybuk> it is afaik
<wasabi> Ahh.
<wasabi> Comments in the script body
<wasabi> even unindented ones
<wasabi> not sure why they're breaking it, but they are.
<wasabi> oh.
<Keybuk> can't have comments in strings maybe?
<wasabi> they're probably being expanded when they shouldn't?
<Keybuk> right
<wasabi> would have thought upstart would have removed them
<wasabi> guess not
<Keybuk> why?
<Keybuk> upstart passes everything between script and end script
<wasabi> including leading indents? k
<Keybuk> actually
<Keybuk> no ;)
<wasabi> heh.
<wasabi> see.
<Keybuk> it kinda de-dents everything
<wasabi> i knew it didn't do that
<wasabi> so I assumed it realized that a non-indented line was an upstart command
<Keybuk> but that's actually good for you
<Keybuk> cause
<Keybuk> exec sendmail
<Keybuk>   blah
<Keybuk>   blah
<wasabi> and upstart would fail if it wasn't # or end script
<sadmac> Keybuk: could be a slight problem if we allow different interpreters, including python
<Keybuk> end exec
<Keybuk> gets de-dented
<Keybuk> and
<Keybuk> exec python
<Keybuk>   blah
<Keybuk>     blah
<Keybuk>   blah
<Keybuk> end exec
<Keybuk> gets de-dented too
<Keybuk> sadmac: it only removes the initial whitespace common to *all* lines
<Keybuk> so that comes out as
<wasabi> I'd adopt python rules. Each line must be indeneted with the same amount and type of whitespace. :)
<Keybuk> blah
<Keybuk>   blah
<Keybuk> blah
<wasabi> And that is auto removed by one level.
<Keybuk> wasabi: that's what it does
<wasabi> So why is # being passed to the script
<sadmac> context sensitive lexical languages make me cry
<Keybuk> wasabi: because it doesn't remove comments
<wasabi> But the comment is not indented.
<wasabi> So it should be invalid.
<wasabi> And refuse to run the task
<Keybuk> why?
<wasabi> OR it should remove it. :)
<Keybuk> neither
<wasabi> <wasabi> I'd adopt python rules. Each line must be indeneted with the same amount and type of whitespace. :)
<wasabi> <Keybuk> wasabi: that's what it does
<Keybuk> the comment means your block is simply not de-dented
<wasabi> oh.
<wasabi> hah.
<Keybuk> it doesn't throw out your entire script because you used a space instead of a tab
<Keybuk> that's just un-necessarily pedantic
<Keybuk> it just doesn't de-dent
<Keybuk> it finds the common prefix from each line that consists entirely of whitespace characters
<Keybuk> and removes that
<Keybuk> if all lines begin \t\t then that is removed
<Keybuk> if all lines begin " \t    " then that is removed
<Keybuk> if, as you've done there, one line isn't indented - then nothing is removed
<Keybuk> it probably doesn't need to screw with it at all ;-)
<wasabi> gotcha
<Keybuk> but it does
<Keybuk> it makes debugging perttier
<wasabi> Trying to remember what i have to escape in this script to script then
<sadmac> is that french?
<wasabi> $ becomes $$...
<Keybuk> no that's something else
<Keybuk> $ becomes \$ in shell ;-)
<Keybuk> $ -> $$ is make
<wasabi> ahh
<wasabi> duh
 * sadmac remembers windows programming
<sadmac> C:\\Windows\\System....
<sadmac> or \\\\Shared\\Folder
<wasabi> windows programming is all I do
<wasabi> @"C:\Windows\System"
<sadmac> wasabi: I'm sorry :)
<wasabi> Fine with me.
<sadmac> anyway, time to go eat.\
<wasabi> I enjoy getting things done. :0
<Keybuk> wasabi: didn't you end up at Google?
<sadmac> wasabi: I don't have time to flame you. please pick this fight again later that we might finish it :)
<wasabi> No. Didn't take it.
<Keybuk> ahh
<wasabi> They keep asking though.
<Keybuk> they do that
<Keybuk> Mountain View seems like such a long time ago!
<wasabi> yeah, it does.
<wasabi> I think about how much fun I had talking with people who knew what the hell I was talking about
<wasabi> often
<Keybuk> heh
<Keybuk> UDS again in not-so-long
<wasabi> I'm not remotely involved enough to get travel paid for, work is super busy (and has been for 2 years).
<wasabi> I'd love to go though.
<wasabi> Can't afford the out of the states trips though.
<Keybuk> yeah
<Keybuk> this one's in the middle of NOWHERE
<wasabi> I didn't make it to the Dallas one.
<wasabi> Because of work.
<wasabi> I LIVE IN DALLAS
<Keybuk> heh, fail
<wasabi> Total.
<wasabi> I saw desrt though. Made him come out and drink.
<wasabi> Which he did little of.
<wasabi> And then left early.
<wasabi> Oh well.
<wasabi> double escaping this is becoming hard to think about
<Keybuk> was he at Dallas?
<wasabi> Yeah
<Keybuk> UDS has got so big now
<wasabi> Dallas can be a great city too. I wanted to come and be the local guy showing everybody where to party.
<Keybuk> I don't think I went into the desktop room once
<wasabi> Because it's completely non-obvious where to go.
<wasabi> \${n//-/--}
<wasabi> Hmmm
<wasabi> Hah. Got it.
<wasabi> \${n//\\-/\\-\\-}
#upstart 2010-03-19
<maro> hi, I have a problem starting dcron 4.4 from upstart - it's a pretty simple job (exec /usr/sbin/dcron -f) and it works from the command line, but it hits the respawn limit if started with upstart
<maro> seems setpgid fails
<maro> what could be the reason this fails in init's environment but not in my shell?
<donEduardo> hi everybody!
<donEduardo> is /etc/default/locale the correct way to go if one needs the system locale during an upstart script?
<Md> donEduardo: there is no such think as "the system locale", /etc/default/locale is the default locale
<donEduardo> Md: hm.... ok.... i got to think about this
<Md> probably you are trying to solve the wrong problem
<donEduardo> I don't know.... I'm fighting with a problem in mythbackend
<donEduardo> if you start this daemon with POSIX-locale, it wont find any media file with non-ascii chars...
<donEduardo> as soon as you use a utf8-locale, everything works perfect
<donEduardo> so what are you suppesed to do in such a situation?
<ion> http://blog.dovecot.org/2010/03/time-to-switch-to-clang.html
<Keybuk> if only it would compile Upstart
#upstart 2010-03-20
<Tack> Given a job foo and another job bar which starts "on started foo", is there an event that will trigger after foo starts but will block bar until completion?  Something, in fact, like post-start, only an event.
#upstart 2011-03-14
<dcorbin_wrk> is there a way to configure an init script to control how the job is stopped?
#upstart 2011-03-15
<IProteus> does upstart store the pid for the process it starts somewhere?
<IProteus> my process does not create a pid file - but I do need the value and wonder if there is an easy way to get it from upstart instead of managing it in the process.
<dcorbin_wrk> will standard init.d scripts fire updstart events?
<plautrba> IProteus: initctl status <job> or initctl list  show also pid if exists
<IProteus> thanks 
<IProteus> I have a special program to stop the process, which I call in pre-stop and I need to pass the pid to this. so that means I should parse the output of those commands to get the pid and pass that in - or is there a way in upstart - some sort of pid variable that I could use in the conf file?
<ion> PID=; eval "$(LC_ALL=C status | sed -nre 's/^.*, process ([0-9]+)$/PID=\1;/p')"; [ -n "$PID" ]
<ion> The LC_ALL=C probably isnât necessary.
<IProteus> sweet, thank you very much.
<SpamapS> dcorbin_wrk: no they won't without explicitly calling 'initctl emit' in their code
<Keybuk> sometimes I think things would be easier if I just built udev into Upstart :-)
#upstart 2011-03-16
<twb> I wrote an upstart job for nsd3, and it works.
<twb> ...except when nsd3 needs to regenerate its database, in which case it seems to fork even when I tell it not to
<twb> I don't really want to "expect fork"; it's such a hack
<twb> http://paste.debian.net/110841/
<twb> What am I supposed to do about that?
<twb> OK, now I understand
<twb> Apparently when you -HUP (reload) nsd, it gets a whole new PID, and it writes the PID to its designated pidfile, but upstart doesn't know this.
<twb> So I think I just have to give up and define "pre start exec nsdc start" and "pre stop exec nsdc stop" instead of "exec nsd -d"
<twb> Fixed: http://paste.debian.net/110845/
<JanC> I guess for such situations it would be useful to be able to point upstart to a "pidfile"...
<soren> JanC: I think for such situations, it would be useful to stab someone in the face for fork()ing on SIGHUP.
<soren> JanC: That's just madness.
<SpamapS> soren: sshd and squid use this "madness"
<SpamapS> soren: not sure we should ignore their success as highly stable daemons ;)
<soren> SpamapS: I don't believe that's true.
<SpamapS> soren: look at the recent bug fixes to the upstart confs for squid and sshd
<SpamapS> both to move them to running in the foreground because they fork on HUP
<soren> SpamapS: I'm looking at sshd.c right now. sighup_restart execve's. I does not fork().
<ion> janc: Insanity lies on that path.
<SpamapS> execve's.. which subsequently, forks
<soren> SpamapS: Oh.
<SpamapS> yeah.. its t3h suck
<SpamapS> breaks the assumptions that expect fork makes unfortunately
 * soren facepalms
<SpamapS> Which, btw, are not well documented. :-P
<SpamapS> The postfix developers have expressed interest in supporting upstart, but have also stated they won't do so until the interface for expect fork/reload/etc. is published
<dsc> I have an upstart job.  I'd like to stop it gracefully.  Is there someway to specify a script to stop it?
<ralfgro> is there someting like "X-Start-Before:" from insserv in upstart?
<dsc> I have an upstart job.  I'd like to stop it gracefully.  Is there someway to specify a script to stop it?
<dsc> damn. I swear I looked for where I'd posted that question and couldn't find it (until I pressed ENTER).
<SpamapS> ralfgro: start on starting
<SpamapS> dsc: what do you mean gracefully?
<SpamapS> dsc: stop job_name tells upstart to send SIGTERM, then after kill timeout (default 5 seconds) SIGKILL
<dsc> SpamapS: by graceful, what I mean is I want to run a script to stop it because I don't have any reason to suspect SIGTERM will be handled gracefully.
<Keybuk> pre-stop script
<Keybuk>   ...
<Keybuk> end script
<Keybuk> ;-)
<dsc> Keybuk: great.  Thanks.
<Keybuk> one of the main uses for a pre-stop is to perform a graceful shut down
<dsc> I didn't see pre-stop documented anywhere, only post-stop
<Keybuk> dsc: it's documented in "man 5 init"
<Keybuk>        pre-stop exec|script...
<Keybuk>               This process is run if the job is stopped by an event listed  in
<Keybuk>               its  stop  on  stanza or by the stop(8) command.  It will be run
<Keybuk>               before the job's stopping(7) event is  emitted  and  before  the
<Keybuk>               main process is killed.  It is typically used to send any necesâ
<Keybuk>               sary shutdown commands to the main process, and it may also call
<Keybuk>               the start(8) command without arguments to cancel the stop.
<SpamapS> Keybuk: if ever there was a time to create an upstart shirt.. now that 1.0 is out.. I think it should just read 'man 5 init' on the front.
<Keybuk> "Upstart isn't documented! ... Except for all the man pages"
<dsc> none of the top google hits mention it.  I'm probably on an older version, which might explain my man pages.
<Keybuk> dsc: you would have to be on a very, very old version
<dsc> I guess I didn't fin it because I was doing "man init" and getting "man 8 init"
<Keybuk> which has, on the very first screenful
<Keybuk>        Processes managed by init are known as jobs and are defined by files in
<Keybuk>        the  /etc/init  directory.  See init(5) for more details on configuring
<Keybuk>        Upstart.
<Keybuk> ...
<Keybuk> just sayin' ;-)
<dsc> yes it does.  I plead guilty to a breadth-first scan of man. :)
<Keybuk> yeah, I seem to like lots of smaller manpages
<Keybuk> rather than one big one
<dsc> I noticed one google hit that mentioned "service" in a job.  I don't find that in init(5).  Is that newer?
<Keybuk> dcorbin_work: no, in fact "service" in a job predates any significant shipped version of Upstart
<Keybuk> all versions you're ever likely to encounter use "task" instead for the opposite (the default has been service since 0.5.0)
<dcorbin_work> Keybuk: should I see it in init(5)?
<Keybuk> dcorbin_work: not anymore
<Keybuk> the term is used still, but there is no config keyword
<dcorbin_work> Got it. Thanks
<dcorbin_work> Is there a log made of all upstart events?
<dcorbin_work> (or a setting to have it log such)
<JanC> dcorbin_work: read about "log-priority" in "man initctl"
<JanC> and about "--verbose" in init(5)
<JanC> in init(8) I mean
<Keybuk> ion: I'm still trying to work out *why* shells are behaving like that (re: 619269)
<ion> Perhaps for the very reason that the script closing a file descriptor doesnât break the shellâs reading of the input file.
<Keybuk> the shell doesn't really know
<Keybuk> so far it seems to be a side-effect of another behaviour
<Keybuk> oh, I see
<Keybuk> the input file descriptor is "saved"
<Keybuk> which means moving it to be >= 10 as permitted by POSIX
<Keybuk> I think I'm being a numpty here anyway
<Keybuk> yes, I am
<Keybuk> if only this was p9
<ion> What does plan9 do?
<Keybuk> in p9, we could just create a pipe
<Keybuk> and pass the path of that pipe as a filename ;)
<ion> Am i wrong in assuming that Upstart could simply use a fd <10 for the shellâs half of the pipe and insert the prefix 'exec n<&-;' to scripts?
<Keybuk> see my most recent comment
<ion> ah :-)
<Keybuk> keybuk@keybuk:~$ ls -l /proc/self/fd
<Keybuk> total 0
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:37 0 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:37 1 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:37 2 -> /dev/pts/2
<Keybuk> lr-x------ 1 keybuk eng 64 Mar 16 14:37 3 -> /proc/20482/fd
<Keybuk> ...
<Keybuk> where is that #3 coming from?! :p
<ion> Itâs the dir opened by ls to do its thing :-)
<Keybuk> keybuk@keybuk:~$ ls -l /proc/$$/fd
<Keybuk> total 0
<Keybuk> lr-x------ 1 keybuk eng 64 Mar 16 14:09 0 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:09 1 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:09 2 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:38 255 -> /dev/pts/2
<Keybuk> ...
<Keybuk> even funnier, 255 ?!
<ion> Yeah, bash did: dup2(3, 255)                            = 255
<Keybuk> why did bash do that?
<Keybuk> what was that 3 originally?
<ion> the input file parameter opened
<Keybuk> that was just "exec bash"
<Keybuk> it must be a bash-y thing I guess
<Keybuk> keybuk scripts% ls -l /proc/20541/fd
<Keybuk> total 0
<Keybuk> lr-x------ 1 keybuk eng 64 Mar 16 14:39 0 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:39 1 -> /dev/pts/2
<Keybuk> lr-x------ 1 keybuk eng 64 Mar 16 14:39 10 -> /dev/tty
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:39 2 -> /dev/pts/2
<Keybuk> keybuk scripts% ls -l /proc/20603/fd
<Keybuk> total 0
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:40 0 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:40 1 -> /dev/pts/2
<Keybuk> lrwx------ 1 keybuk eng 64 Mar 16 14:40 2 -> /dev/pts/2
<Keybuk> dash keeps a tty open at #10 ;-)
<Keybuk> but most importantly doesn't leak it
<ion> Yeah, none of them seem to.
<Keybuk> keybuk init# ps w -p 31158
<Keybuk>   PID TTY      STAT   TIME COMMAND
<Keybuk> 31158 ?        Ss     0:00 /bin/sh -e /proc/self/fd/12
<Keybuk> keybuk init# ls -l /proc/31158/fd
<Keybuk> total 0
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 0 -> /dev/null
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 1 -> /dev/null
<Keybuk> lr-x------ 1 root root 64 Mar 16 14:44 12 -> pipe:[4648423]
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 2 -> /dev/null
<Keybuk> lr-x------ 1 root root 64 Mar 16 14:44 255 -> pipe:[4648423]
<Keybuk> keybuk init# ls -l /proc/31159/fd
<Keybuk> total 0
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 0 -> /dev/null
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 1 -> /dev/null
<Keybuk> lr-x------ 1 root root 64 Mar 16 14:44 12 -> pipe:[4648423]
<Keybuk> lrwx------ 1 root root 64 Mar 16 14:44 2 -> /dev/null
<Keybuk> ...
<Keybuk> whereas 12 is definitely leaked there
<Keybuk> the shell actually has the file opened as #255 too
<ion> yeah
<Keybuk> so close(12) wouldn't actually close the file
<Keybuk> of course
<Keybuk> this is all another reason we can't support "perl script" ;-)
<Keybuk> I'm such an evil cunt
<Keybuk> since a year has now passed since the MOST ANNOYING BUG EVAH was filed
<Keybuk> I only now fix it
<Keybuk> because it was too much fun leaving it open for the screaming idiots
<Keybuk> (522197)
<ion> hah
<Keybuk> sigh, it appears that Lennart is posting to upstart-devel with An Opinion ;-)
<ion> The message from ~30 minutes ago or something that hasnât made it into my mailbox yet?
#upstart 2011-03-17
<Keybuk> no idea there
<Keybuk> I can look
<Keybuk> ion: what are you subscribed as?
<Keybuk> oh, wait, wrong ML
<Keybuk> I can't look :p
* Keybuk changed the topic of #upstart to: Upstart 1.1 "It's probably 'cause you think you're cooler than me" | http://upstart.at/
<telive> hello everyone . i have just installed  apache2 in ubuntu and found that there is no apache2.conf file in /etc/init dir . so apache do not stat at the boot time .
<Keybuk> telive: it may have a shell script in /etc/init.d
<telive> Keybuk, yes 
<Keybuk> there you go then
<telive> Keybuk, but the apache2 didn't start either . 
<Keybuk> that I can't answer, you would need to talk to Ubuntu people
<telive> Keybuk, i have checked the status of apache2 in sysv-rc-conf , it is on 
<Keybuk> I'd suggest #ubuntu-server would be a good start, should such a channel exist
<telive> can anyone send me your apache2.conf file in /etc/init  ?
<telive> Keybuk, thanks 
<JanC> telive: did you check logs for any error message or such?
<JanC> nevermind, I see you're in -server already  âº
<telive> JanC, hehe 
<telive> JanC, as i know , upstart have take place of sysv in ubuntu . and there is no apache2.conf file in /etc/init , so the apache server didn't startup 
<JanC> upstart in Ubuntu has sysv emulation, so the sysv init scripts in /etc/init.d/ should work
<wraiden> hello, fetching http://upstart.at/download/1.x/upstart-1.1.tar.gz gives a 403 Forbidden response...
<Hobart> is there a way to ask upstart to prompt you for each step it's going to take (a-la the old "interactive startup") to troubleshoot while booting?
<marrusl> Hobart, I don't think so.  but take a look here: http://upstart.ubuntu.com/wiki/Debugging
<marrusl> Hobart, the main takeaway being adding --verbose to the kernel command line.  there's also --debug which goes further.
<JanC> during the first steps there probably would be no way yet to prompt?
<marrusl> and then looking at daemon.log to see what happened.
<marrusl> JanC, because you have multiple paths going at once, i'm not sure an interactive boot even makes sense.
<JanC> well, it would remove a lot of the parallelism
<JanC> and hide most of the possible race conditions
<marrusl> JanC, indeed.  and then you wouldn't be troubleshooting your actual scenario.
<marrusl> yup exactly.
<Hobart> marrusl -> thank you for the information!
<Hobart> unfortunately at a certain step in bootup, the system was cold-booting
<Hobart> which is why I was hoping for a [Y/n]? prompted option
<Hobart> might open up a wish request item for it
<marrusl> I've locked up a boot before daemon.log even gets started, thankfully I was able to reverse the change.  but yeah,  that sounds tricky then.  
<marrusl> Hobart, does it cold boot when you try to boot to single user?
<Hobart> marrusl -> it wasn't, but I've already made a few changes since then (I'm 95% sure I have unstable RAM and am awaiting ECC replacement modules) 
<Hobart> I -think- the issue was that I'd said for the onboard radeon 3100 integrated motherboard gfx adapter to grab 1GB instead of 'Auto' (256MB) which appears to be outside the stable test cases for both the Windows and Linux drivers :-(    (flashplayer can BSoD the Windows side in that setting, and X was coldbooting / hardlocking, no alt-sysrq-R sanity recovery)
<Hobart> which leads me to believe that the stupid was centered in the DRM module or other kernel level thing, since just X chokng usually lets me switch out virtual consoles or deal with X's recovery
<marrusl> Hobart, aha.  Just thinking you could start up services manually from runlevel 1 or even see if going to runlevel 2 manually makes a difference.  
<marrusl> Hobart, ah, but if it hardware, then may as well wait for the parts and see.  good luck!
<Hobart> thanks :)   I still think 'boot everything serially' will make a good wishlist item for troubleshooting :
<Hobart> :)
<JanC> Hobart: the way upstart works makes it *very* difficult to determine what a serial boot should do  ;)
<Hobart> JanC -> Imagine that I launch upstart under gdb with a breakpoint set on the call to execve() ...  
<JanC> but the order could still be different every time, and it would both hide bugs & create new problems if you do that...
<JanC> not to mention that it's very well possible that at some point there is no way to tell upstart to continue and you'd get stuck...
<Hobart> Putting a fire axe on the wall of an apartment building isn't assurance that you'll get out alive.
<Hobart> It's still nice to have there. :)
#upstart 2011-03-18
<KB1JWQ> There a handy guide as far as "So you've got a service that isn't upstart compatible, here's how you shoehorn support in?"  Seeing issues with upstart and puppet on Lucid, figure it's time to get my hands dirty.
<JanC> KB1JWQ: there was a PDF posted on the mailing list some time ago, but most people just look at existing upstart job configurations
<JanC> sorry, even better, not a PDF, but a regular mail: https://lists.ubuntu.com/archives/upstart-devel/2011-January/001383.html
<KB1JWQ> JanC: Thanks.  While I'm on the topic, is there an Upstart equivalent to "chkconfig --list" that shows you what services start on boot?
<JanC> KB1JWQ: upstart services are started based on 'events', so there is no exact way to make such a list I suppose
#upstart 2012-03-12
<dupondje> Hi somebody around for a question? :)
<dupondje> i'm rewriting upstart script for cryptsetup. Now what signal can be used to remove the crypted mappings? This should be done after umount happend.
<JanC> dupondje: you want to automatically remove the crypted mapping after the filesystem on it gets unmounted?
<JanC> that might get complicated in case there is a partition table (or whatever else that is not a filesystem) on the encrypted block device...
<dupondje> JanC: well it should be stopped before lvm or so is stopped, and after umount ofc
<JanC> dupondje: doesn't that depend on whether lvm is below or on top of dm-crypt?  ;)
<dupondje> hmmmm :P
<JanC> (and can't/doesn't the kernel handle this?)
<dupondje> there is a do_stop at least for debian
<dupondje> then i'll should just add post-stop script in the upstart to stop all (unmounted) crypt mappings when running service cryptsetup stop right
<dupondje> Cause now there are 2 init scripts and 2 upstart scripts, the init scripts taking care of the stop, the upstart for the start
<dupondje> thats like not clean ;)
<JanC> you might want to discuss with some of the people who know more about those parts of boot/shutdown...
<dupondje> tought this would be the place ;)
<JanC> dupondje: if this is Ubuntu-specific, #ubuntu-devel or such might be more useful
#upstart 2012-03-13
<glenn__> morning
<glenn__> how can i get an upstart script in the puppet package? should i create an issue in launchpad for that?
<glenn__> the upstart script is ready
<glenn__> so its just a matter of adding it.
<dupondje> glenn__: bugreport indeed with the script attached
<glenn__> right, i got dc'd
<glenn__> did someone perhaps answered my question?
<dupondje> glenn__: bugreport indeed with the script attached
<dupondje> :)-
<glenn__> dupondje: thank you very much. should i file it at the puppet package, or in the upstart section/package?
<dupondje> puppet package
<dupondje> as the upstart scripts are in the (or should be in) the puppet package :)
<glenn__> should be indeed :)
<glenn__> maybe we can get in before beta2 
<glenn__> that would be great
<glenn__> ill issue a bug for it, thanks again dupondje
<dupondje> doubt it will be in precise. Its already Feature Freeze
<glenn__> really :(
<dupondje> yep :P
<glenn__> what is i get someone a beer? :)
<glenn__> oops, what if i get someone a beer
<glenn__> would that help? ;)
<glenn__> or whisky
<SpamapS> glenn__: you want to add an upstart script to the puppet package?
<glenn__> spamaps yez plz
<glenn__> this took a month or so to get it straight with puppetlabs
<glenn__> but their developer says it was the right way to fly
<SpamapS> glenn__: NICE
<SpamapS> glenn__: so, https://launchpad.net/ubuntu/+source/puppet/+filebug
<glenn__> spamaps; it is for the client though
<SpamapS> glenn__: then bzr branch lp:ubuntu/puppet .. add the file as debian/puppet.puppet.upstart , and document using 'dch -i'
<glenn__> let me try that
<SpamapS> glenn__: what package would you want it in?
<SpamapS> glenn__: as its a new feature, its unlikely to make it into 12.04
<glenn__> this is puppet
<SpamapS> glenn__: without a reasonable feature freeze exception .. reason ;)
<glenn__> spamaps: im gonna role out puppet in our environment so id prefer working with upstart
<glenn__> that way id be sure id would be running :)
<SpamapS> glenn__: seems like puppet is one of those things you'd want to have starting at a very precise point (no pun intended)_in the boot
<SpamapS> glenn__: upstart isn't exactly the right thing to use to "be sure its running" .. it will give up respawning eventually. :)
<glenn__> spamaps: well, for just 1 respawn its ok, else id have to setup monit or something as well
<glenn__> spamaps: also, restart puppet is nicer then /etc/init.d/puppet restart
<SpamapS> glenn__: eh.. I don't recommend people call restart directly
<SpamapS> glenn__: service puppet restart
<SpamapS> glenn__: restart is a bit broken
<glenn__> spamaps: should i put my name in the upstart script in case people want assitance? or should i make it anonymous
<SpamapS> https://bugs.launchpad.net/upstart/+bug/703800
<SpamapS> bug #703800
<SpamapS> darn it, no bug bot
<SpamapS> glenn__: author "you" seems like a good idea. :)
<glenn__> well, the puppet upstart script is really simple
<glenn__> no pre post whatever
<glenn__> but good habbit to use service
<glenn__> how would one get an ubuntu email add?
<glenn__> :}
<glenn__> it that only for ubuntu devs?
<glenn__> ill just put my work email there 
<glenn__> nm
<SpamapS> glenn__: Apply for Ubuntu membership
<SpamapS> glenn__: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cts=1331654831422&ved=0CCoQFjAA&url=https%3A%2F%2Fwiki.ubuntu.com%2FMembership&ei=rHBfT_aiA4idiALP6OypBA&usg=AFQjCNFd329PeCtgIz_GbQTFEAYncdA_aQ
<SpamapS> damnit
 * SpamapS curses the google juice
<SpamapS> glenn__: https://wiki.ubuntu.com/Membership
<glenn__> spamaps: im using dch -i now, but its saying: puppet (2.7.11-1ubuntu1) oneiric; urgency=low
<glenn__> glenn: is that because my workstation is oneric?
<kklimonda> glenn__: pretty much, you have to pass -D <suite> by hand if you want to change it
<SpamapS> glenn__: yes, just change it to precise. :)
<glenn__> spamaps: everyone is using unstable: like puppet (2.7.11-1) unstable; urgency=high
<glenn__> ill go with that
<glenn__> im noticing btw, that this weeks bugfixes are not in this release yet
<glenn__> spamaps: bzr is new to me, how should i push this ? or is dch -i enough?
<glenn__> or should i put a diff in the bug at launchpad ? :)
<glenn__> like this one: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/950183
<SpamapS> glenn__: unstable is debian.
<SpamapS> glenn__: debcommit
<SpamapS> glenn__: also make sure you mention the bug # as  LP: #XXXXXX
<SpamapS> glenn__: then debcommit will pick that up and attach the bug # to the bzr commit
<axisys_> would be nice if bash completion worked with upstart.. kind of offtopic for this channel
<axisys_> /etc/init.d/ss<tab> works perfect 
<axisys_> start ss<tab> does not
<axisys_> i started for few jobs .. same behavior
<SpamapS> axisys_: great idea :)
<SpamapS> axisys_: 'service x[tab]' should also work
<glenn__> spamaps: ok so i should use the precise branch in my case and not the debian one
<SpamapS> glenn__: yes unless you want to try and get your change into debian first (which is a good idea actually.. since the debian maintainers are pretty quick to pickup changes)
<glenn__> spamaps: im familiar with using git and github... bzr is new for me..
<SpamapS> glenn__: bzr is more like svn
<glenn__> spamaps: ive added the upstart start and did the comment in the changelog: http://paste.ubuntu.com/882132/
<glenn__> spamaps: what would be the best next step? debcommit?
<glenn__> spamaps: shouldnt i have pulled source from debian instead of ubuntu?
<SpamapS> glenn__: unstable means debian.. so if you're going to do this in debian, make it 2.7.11-2 .. if you're going to do ubuntu, do 2.7.11-1ubuntu1 and 'precise'
<glenn__> bzr looks like git though, with commit, add and push
<SpamapS> glenn__: right, bzr is like a simpler git
<SpamapS> slower too ;)
<glenn__> but, for my understandig if i get the source from lp:ubuntu/puppet i can still push to debian?
<glenn__> its changed to puppet (2.7.11-2) unstable; urgency=low 
<glenn__> hm i just did debcommit, it did something
<glenn__> so would i push this now?
<glenn__> and to where? :)
<glenn__> this packaging stuff with changelogs is a lot different then what im used to :)
<glenn__> http://paste.ubuntu.com/882153/
<glenn__> do i push this to my own repo or to the debian repo of puppet?
<glenn__> http://paste.ubuntu.com/882159/
<glenn__> i came this far
<glenn__> but thats not good enough 
<glenn__> ill get source from debian and try that i guess
<glenn__> why are all those lp sources read_only
<glenn__> same goes for debian branch :)
<SpamapS> glenn__: for Debian, you probably just want to use debdiff
<SpamapS> glenn__: or just do 'bzr diff -c -1' and then save that to a file, and attach it to your debian bug report
<glenn__> spamaps: im only active in launchpad, is that a problem?
<SpamapS> glenn__: since you are going through debian, you'll want to report the bug to Debian...
<SpamapS> glenn__: if you want to report it in Ubuntu, and just attach your debdiff to the launchpad bug, I can forward it to Debian for you.
<SpamapS> glenn__: IIRC, the debian maintainers watch bugs for the Ubuntu packages, so it will get back to them no matter what
<glenn__> spamaps: the other bug i gave, has a debdiff in the ubuntu issue
<glenn__> spamaps: no wonder that one isnt applied yet :)
<glenn__> spamaps: i think ill just create and ubuntu issue, add the debdiff :)
<glenn__> im an ubuntu user :)
<SpamapS> glenn__: awesome!
<glenn__> sspamaps: sorry for the many question though :)
<glenn__> to you its easy but for me its not ;)
<SpamapS> glenn__: np, packaging / os dev is not simple. :-P
<glenn__> spamaps: i had an ubuntu rep contact me asking how my experience was
<glenn__> spamaps: and this part is kind of hard, documentation is not straightforward as wel
<glenn__> there is the bzr manual etc.. but the workflow etc
<glenn__> workflow is hard to understand, who can do what, who does which package.. how it should be submitted
<glenn__> 'what' should be submitted
<glenn__> ill perhaps contact that sir from ubunt
<glenn__> give him some proper feedback
<glenn__> i think i got the right diff now, could you please check if this is ok? http://paste.ubuntu.com/882194/
<glenn__> then ill file the issue so you can forward it :)
<glenn__> i dont think its the right diff
<SpamapS> glenn__: https://wiki.ubuntu.com/DistributedDevelopment btw
<SpamapS> glenn__: feedback on the diff.. make it 2.7.11-1ubuntu1 .. 
<SpamapS> glenn__: also have you tested 'reload puppet' ?does it work? I recall something weird about the way it handles SIGHUP
<glenn__> but that ubuntu1 is already out is that np?
<glenn__> reload puppet goes ok
<SpamapS>     puppet |   2.7.11-1 |       precise | source, all
<SpamapS> glenn__: no, there's no 2.7.11-1ubuntu1
<glenn__> indeed, excuse me :)
<glenn__> but someone else did a debdiff though
<glenn__> https://launchpadlibrarian.net/96071463/puppet_2.7.11-1ubuntu2.debdiff
<glenn__> he is at ubuntu 2 already
<glenn__> should i make it 3 ?
<glenn__> yeah i should, it actually does it for me :)
<glenn__> i do think the diff is ok
<glenn__> perhaps i should just file it
<glenn__> see what happens :)
<glenn__> https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/954368
<glenn__> im off to home
<glenn__> spamaps: thanks a lot for your assistance
<glenn__> appreciate that
<glenn__> bye
<glenn__> :)
#upstart 2012-03-15
<glenn___> ellow
<glenn___> small question: when im setting the -v daemon option in the defaultfile the upstart script is honering that. but the -v logging from the daemon goes into the upstart logfile. is that expected behaviour?
<glenn___> yes please? :)
<glenn___> http://paste.ubuntu.com/885301/
#upstart 2012-03-16
<MrBusiness> I would like to convert a Ubuntu desktop machine into a server that does not boot into X, but with upstart it appears that this is not something I could accomplish by booting into a lower runlevel, since a standard upstart system seems to have fewer overall runlevels than many other Linuxes. Am I misunderstanding the matter, or is there another way I could go about converting my machine to avoid booting into X by default?
<onikk> hi, I'm trying to get a small C program to run via upstart, but it starts only once and after that start and stop hang or show start/killed or stop/killed... how to debug/proceed? 
<glenn___> hello
<glenn___> anyone here ? :)
<glenn___> i have a question regarding the upstart script for puppetmaster 
<glenn___> the sysv style script uses a while loop in the init script to start several puppetmasters, and until now i cant get this to work with upstart. 
<glenn___> is this even possible?
<glenn___> i dont think this is possible
<glenn___> anybody experience with this? starting multiple daemons with 1 upstart script?
<glenn___> guys ?
<glenn___> i think i should use instance
<SpamapS> glenn___: several puppetmasters ?!
<SpamapS> glenn___: you may want to use two upstart jobs and the 'instance' keyword
<SpamapS> glenn___: or its possible you could make a master/slave single recursive upstart job w/ instance. :)
<glenn___> spamaps: well, its the mongrel type of puppetmaster, and it just start multiple master based on masterport
<glenn___> personally i dont use any standalone puppetmaster, im using passenger
<SpamapS> glenn___: shouldn't you be using passenger?
<SpamapS> glenn___: mongrel is basically abandonware at this point isn't it?
<glenn___> spamaps: yes, but that is puppetmaster-passenger... right now im talking about puppetmaster
<glenn___> spamaps: yes, but jamespage asked me to create init script for all the daemons from the puppet package instead of just the agent
<glenn___> spamaps: noone wants to use puppetmaster with mongrel i guess
<SpamapS> glenn___: its being dropped from debian
<glenn___> spamaps: in what ubuntu version would mongrel be gone?
<SpamapS> glenn___: 12.10 probably
<SpamapS> glenn___: its still in 12.04 .. but the debian ruby team is already prepping to drop it from "wheezy"
<jefimenko> hi
<jefimenko> how do i read from /dev/console?
<jefimenko> i'm trying to see the errors a daemon throws during startup by adding the "console output" stanza
<jefimenko> which sounds like it would be great if only i knew how to read from /dev/console
#upstart 2012-03-17
<Tom_> does the mailing list have an overview of issues?
#upstart 2013-03-11
<francis`> testing to see if I can speak w/unregistered username
#upstart 2013-03-12
<tartar> I wonder, though, if writing to console in upstart scripts in Lucid could block?
<tartar> I hear plymouth owns the console and bug 785242 implies that writing to it may cause a dead lock.
<SpamapS> tartar: you should only have one 'console owner' active at one time
<SpamapS> tartar: you can have some other console owner after plymouth exits
<cwillu_at_work> I want to set up a job that will ignore its start-on stanza based on a test, but can still be started manually via "start foo-job"
<cwillu_at_work> is there an environment variable or something I can check to distinguish?
<SpamapS> cwillu_at_work: pre-start is for that
<SpamapS> cwillu_at_work: in pre-start, you can just run 'stop' and the job's start will be cancelled
<cwillu_at_work> sure
<cwillu_at_work> but that would also trigger if I ran "start foo", wouldn't it?
<SpamapS> cwillu_at_work: the env variable to check is '$UPSTART_EVENTS'
<cwillu_at_work> ah, thanks
<SpamapS> cwillu_at_work: it will be empty with a manual start/stop
<cwillu_at_work> perfect
<tartar> thanks, SpamapS 
<tartar> I guess this prevents from easily debugging upstart scripts by echo-ing messages
<tartar> Although the hardest cases that need debugging may lose that tmpfs file on reboot.
<SpamapS> tartar: you can have console output as many times as you want
<SpamapS> tartar: only console owner is dangerous
<SpamapS> tartar: and newer upstarts log everything to /var/log/upstart now
<tartar> But I thought plymouth could block these writes to the console when it makes itself busy.  The console output lockup bug made me think that "owning" the console meant plymouth injecting itself into the data flow between /dev/console and the screen.  I guess I mis-interpreted the bug.  (I disliked the newer upstart logging into separate files from each conf file.  This makes observing the timeline difficult).
<SpamapS> tartar: yes plymouth can block, but its job is to not block, and multiplex things properly.
<SpamapS> tartar: cat /var/log/upstart/* | sort works
<SpamapS> tartar: the date/time stamps are ISO and sort perfectly
<tartar> By "blocking" I mean stopping the upstart scripts where they try to write to stdout.
<tartar> Thanks for the sort trick.  I did not see timestamps in some Ubuntu 12 setup.
<SpamapS> tartar: some things don't have timestamps actually
<SpamapS> tartar: so you're right about that ;)
<SpamapS> perhaps upstart should have that as an option
<SpamapS> tartar: I'm on crack. I spot checked 2 things, and they had timestamps, but those two things were both openstack components which log with a nice structured logger
<SpamapS> tartar: its just raw "whatever the programs printed"
<SpamapS> slangasek: ^^ possible upstart feature idea.. add timestamps to logs
<slangasek> SpamapS: yes, I've been thinking we ought to do that.  Could you file a bug report so we don't lose it?
<slangasek> (and/or provide a patch? :)
<SpamapS> looking at both right now
<SpamapS> https://bugs.launchpad.net/upstart/+bug/1154207
<xnox> if my crazy idea works, it will be wonderful.
<SpamapS> xnox: in the US we say it like this: "Hey, watch this!"
<SpamapS> [boom]
#upstart 2013-03-15
<sgfault> Hello
<sgfault> I need some help with setting up my job on centos 6.2 64 bit. Here's the problem, when I reboot the system and do initctl list, I don't see my custom job in the list, but I have to do initctl reload-configuration and then initctl list shows the job.
<sgfault> When I reboot, the configuration gone again and I have to manually do initctl reload-configuration again.
<sgfault> The startup condition I have in my file  is : start on startup
<sgfault> And I am on Upstart 0.6.5 that is shipped with centos 6.2
<sgfault> Any help/pointers is appreciated.
<sgfault> anyone?
<sgfault> anyone?
<xnox> jodh: file bridge - i pulled the updates /foo.txt now works, but creating a subdir and touching a file in it doesn't.
<jodh> xnox: ? certainly should do. One sec...
<xnox> also I disagree on emitting events for existing files, for example opening and closing a .conf file causes the job to be reloaded and the bridge re-emits created events, when imho it shouldn't.
<jodh> xnox: I'm testing the latest code now using your example and it wfm.
<xnox> can we not emit events, and instead ask people to do 'start on runlevel[2345] or file FPATH="/foo" FEVENT=create', but it will be their job to check if /foo exists in pre-start and abort starting for example.
<xnox> jodh: let me clear stale objects and do a clean compile.
<jodh> xnox: the problem is, if we don't emit the event for existing files, this will be highly non-intuitive since a job that specifies 'start on file FPATH=/something' will never start even if /something *does* exist.
<jodh> xnox: ok.
<jodh> xnox: but rewriting a job file is not going to be a normal operation, unless you happen to be writing a new job and then you would want the event emitted again surely?
<xnox> but then this event will be emitted: every time we do any reexec, every time that jobfile is edited (multiple events emitted)
<xnox> jodh: dpkg upgrade writes new files.
<xnox> (include job files)
<xnox> jodh: my understanding that in practice "start on file FPATH=/something" will all be tasks & not long running daemons with expect/respawn.
<xnox> and thus the point is that we do not want to automatically start them, only when something happens.
<jodh> xnox: maybe, but we can't enforce that.
<xnox> true. I guess we can wait for people to use it and complain to us if stale files are a problem.
<xnox> and if stale files are a problem we should point them to use XDG_RUNTIME_DIR instead, to avoid having stale file problem ;-)
<jodh> xnox: maybe an alternative is to support 'FEVENT=exists' so we'd only emit the event in that scenario. If FEVENT is not specified, we would only emit on (an actual)create, modify, or delete.
<xnox> jodh: feature creep, that is a sound approach we can take, if requested to differentiate.
<jodh> xnox: indeed :)
<jodh> xnox: the re-exec case is indeed problematic. I think for now we'll need to rely on the job in question to detect that it's already processed "file". Thankfully, services like whoopsie will DTRT I believe.
<xnox> all works fine \o/ merging.
 * xnox had a syntax error in one of the conf files.
<SpamapS> btw
<SpamapS> the file bridge
<jodh> xnox: thanks! :)
<SpamapS> *love it*
<xnox> SpamapS: ;-) you had me on the edge with the first two lines ;-) but all is good after last one.
<jodh> SpamapS: hope it's useful. There are certainly enhancements we can make. I wonder if the ability for a job to specify 'single-shot' mode would be useful as currently (as the man page states), it's very much 'multi-shot'.
<SpamapS> well..
<SpamapS> I like the idea of the system abstracting away the details of inotify (which is, I assume, what it is intended to do).
<SpamapS> also, what I'd really love would be 'reload on' :)
<jodh> SpamapS: yes - I didn't call it upstart-inotify-bridge for that reason too in case we decide to change the implementation (and I would like to! :-)
<jodh> SpamapS: is there a bug for 'reload on'?
<SpamapS> jodh: no, but let me file that
<jodh> SpamapS: thanks!!
<SpamapS> btw if you're looking for a bug to work on.. https://bugs.launchpad.net/upstart/+bug/406397
<SpamapS> ... 58 affected...
<jodh> SpamapS: yeah - we haven't forgotten about that one - honest! :)
<SpamapS> jodh: its about every 10 days we get a new "I have a pid stuck..." person in here.
<jodh> SpamapS: I appreciate this isn't ideal, but maybe they could use a container to develop the jobs in? Or if the jobs don't need to run as root, use the Upstart 1.7 Session Init as logout/login is quicker than reboot ;)
<xnox> we also have a lot of "It doesn't restart" and the pids in ps and status do not match.
<SpamapS> jodh: thats a lot more complicated than 'initctl forget job-foo'
<SpamapS> jodh: or, following exit's instead of forks (my preference.. ;)
#upstart 2014-03-11
<delkin__> Hello everyone. Is it possible to make sure that service `B` only runs when service `A` finishes? How do I do that?
<delkin__> service B should not run while A is still running
<taharqa> Hi delkin__ , here what I have for docker where docker daemon have to be running before container can start
<taharqa> docker daemon write into /var/run/docker.sock
<taharqa> then we check that the file exists before starting the container
<taharqa> here is the script block
<taharqa> script
<taharqa>   # Wait for docker to finish starting up first.
<taharqa>   FILE=/var/run/docker.sock
<taharqa>   while [ ! -e $FILE ] ; do
<taharqa>     inotifywait -t 2 -e create $(dirname $FILE)
<taharqa>   done
<taharqa>   # irc is the name of the container to start
<taharqa>   /usr/bin/docker start -a irc2
<taharqa> end script
<taharqa>  
<taharqa> the file creation can be replace by anything
* jodh changed the topic of #upstart to: Upstart 1.12.1 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
<cdwSymfony> Okay, I need an easy way to add an upstart script.
<cdwSymfony> I just want to add a script.
<joelteon> how can I get the output of a failed script from upstart?
#upstart 2014-03-12
<h2> I'm looking for a foolproof way to identify that upstart was the init system , like something in /run for example
<h2> for inxi, the sys info program
#upstart 2014-03-13
<cdwSymfony> Anyone around?
#upstart 2014-03-14
<TimoMeijer> I was wondering if Upstart development will stop, or continue, now Ubuntu is moving to systemd?
#upstart 2015-03-09
<blotchy> would it be horrible forum to make a minimal upstart script that just calls the old sysV script (after it's been moved)?
<blotchy> form, not forum
#upstart 2015-03-10
<audy> I need to run a daemon on port 25 as non-root. What am I looking for? setcap?
#upstart 2015-03-11
<gchristensen> Hi, is there a way, using the stop command, to override the `kill timeout` parameter at stop time? 
#upstart 2017-03-14
<jcotton11235> It seems that upstart will automatically start a service when the services init conf is installed. Is there anyway to prevent this?
#upstart 2018-03-12
<bn_work> do you guys have any Upstart usage stats?  I am trying to get a vendor to add support for Upstart but they are calling it an "obscure daemon manager" :/
<bn_work> I mean is Upstart basically dead now?  I've seen no site updates since 2014... 
<xnox> bn_work, it is stable and maintained; meaning we provide stable series maintainance and security support only.
<xnox> bn_work, modern releases of Debian and Ubuntu have stopped using it, nor providing it.
<xnox> bn_work, e.g. 16.04 LTS and onwards only support systemd as the system pid 1.
<xnox> bn_work, the only remaining users of upstart in production that I know of, are older Ubuntu releases e.g. 12.04 LTS ESM, 14.04 LTS, Chrome OS, Amazon Kindle, Some LG TV, and possibly some fridges.
<xnox> bn_work, i would recommend providing a systemd unit to anyone shipping daemons, that are capable of being run on linux kernel.
<bn_work> xnox:  thanks for the comment, then I guess systemd has truly won.  Seems odd Canonical would not even offer it as an unsupported "option", in the spirit of being open.   
<bn_work> If maintenance patches are still provided why are there no announcements about it on upstart.ubuntu.com?  (BTW, the revision history link on the dev page http://upstart.ubuntu.com/development.html seems broken, FYI:    http://bazaar.launchpad.net/~scott/upstart/trunk)
<xnox> bn_work, Ubuntu Project (community) has always been focused on providing great user experience, and thus good, sane and obvious default choices. Therefore, we have only ever supported one system init system at the time, and e.g. dropped sysv-init support a very long time ago; when we moved to upstart. Later the project switched to systemd. Canonical, supports even a smaller subset of Ubuntu flavours.
<xnox> bn_work, for example, Lubuntu is community supported; and Canonical does not provide support that (it supports the common core/base system bit that Lubuntu is built on top)
<xnox> * support for that
<xnox> Canonical is focused on supporting Public/Private Cloud, Server, Core, Desktop (used to be Unity, now Gnome), IoT.
<xnox> bn_work, it is out of scope for the Ubuntu Project to support multiple choices of common/core things. hence Ubuntu project doesn't support multiple kernels, multiple init systems, multiple libc, etc. unlike e.g. Debian.
<xnox> bn_work, "If maintenance patches are still provided" -> well, they are provided, in a sense that we are expecting an escalation of a L3 issue, and/or a security bug found =) but there haven't been any for a few years now. Hence, upstart is stable =)
<xnox> bn_work, if there will be one, we will update something, but most likely it will be just an Ubuntu Security Notice or Ubuntu SRU, and a patch on the mailing list, and matching VCS commits =)
<xnox> i have not been summoned to fix upstart, in years now, and I hope it will stay like that =)
<xnox> note upstart is part of the extended security maintainance of Ubuntu.
<xnox> so i'm still on stand-by for that in 2019+
<xnox> Thu, 19 May 2016 12:04:29 +0100 -> sounds about right, for the last time upstart had an update.
<bn_work> xnox: ok, thanks
#upstart 2018-03-15
<datajerkB8DMZY> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
<datajerkB8DMZY> mmeyer bn_work JanC mniip marrusl PaulePanter AnrDaemon DzAirmaX m1dnight_ hallyn Trevinho broder xnox balkamos inara` kaylindris puhuri Necrosan dgw cschneid_ xMopx blazeme8 ubuntulog
