#upstart 2007-02-05
<dns_server> could someone help me write some scripts?
<Keybuk> what type of scripts?
<dns_server> i'd like to get smbfs mounted when a network comes up 
<dns_server> do you know where i can find some good examples of scripts etc?
<Keybuk> what type of scripts?
<dns_server> just anything
<Keybuk> I'm sorry, but I still don't understand your question; could you be more specific
<dns_server> what i want is to mount smbfs (fuse mount that shows all computers) automatically when a network interface comes up.
<dns_server> i'm not shure what networking events get started and there are not too many examples to look at
<Keybuk> what distribution are you using?
<dns_server> ubuntu feisty and it would be good if it also worked on edgy if that is possible
<dns_server> where do i find what network events are sent? so my script can respond to them
<dns_server> ie what events can my script respond to?
<dns_server> there is not a huge ammount of documentation from what i can see
<crimeboy> can i put upstart in the dapper?
<Keybuk> wasabi: hey, how goes it?
<wasabi> pretty good
<wasabi> trying to learn enough C to fix this vmware module he
<Keybuk> heh
<Keybuk> I've discovered that management is both more fun, more challenging and more time consuming then I previously imagined
<wasabi> Uh huh. You usually end up not being able to work on what you like.
<wasabi> Unless you like management. ;0
<wasabi> That's been my experience anyways.
<Keybuk> I've certainly had to let go of a lot of stuff, yeah
<Keybuk> including all the bug triage, handling, fixing, etc.
<Keybuk> can't say I'm sorry to see that go :p
<wasabi> At least it pays better? :)
<Keybuk> well, yes
#upstart 2007-02-06
* Keybuk taps his fingers
* ..[topic/#upstart:Keybuk] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://www.netsplit.com/blog/articles/2006/12/14/upstart-0-3 | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://lca2007.linux.org.au/talk/102
<AlexExtreme> wahey
<AlexExtreme> 0.3.2
<Keybuk> I've actually been sitting on that one for a day or two
<Keybuk> there was a length discussion about whether it needed a CVE or not
<AlexExtreme> there was a security flaw?
<Keybuk> ish
<Keybuk> sudo ls -l /proc/*/fd/6
<AlexExtreme> hmm, can't try that right now. I'm without a linux install :/
<Keybuk> it leaked its inotify instance descriptor to other processes
<AlexExtreme> ah
<Keybuk> not serious; the worst you can do is remove the watch on the config directory
<AlexExtreme> yeah
<AlexExtreme> so, I'll soon be able to start writing new job files for frugalware?
<Keybuk> yup
<AlexExtreme> great
<Keybuk> am merging in and programming the specs now
#upstart 2007-02-07
<Keybuk> so, the one thing I do hate about gcov ...
<Keybuk> "Merge mismatch for summaries"
<mbiebl> Keybuk: hi
<mbiebl> tested the latest 0.3.2 version
<Keybuk> did it work?
<mbiebl> What I noticed is, that if I renamed a file in /etc/event.d/, initctl list still showed the old (and the new) job name.
<mbiebl> yeah, without problems.
<Keybuk> right, rename and delete still aren't fully implemented
<mbiebl> But besides from that, it's running fine.
<mbiebl> I'll prepare a new Debian release soon.
<mbiebl> I think your rigid test-case based developing pays off.
<mbiebl> I used initng for a while and it often crashed and left an unbootable system.
<mbiebl> Never had that with upstart.
<mbiebl> So, thumbs up ;-)
<mbiebl> btw, how was lca?
<mbiebl> So your talk via video stream
<mbiebl> s/so/saw/
<Keybuk> it seems to have been pretty useful, yeah
<Keybuk> I'm finding it really handy at the moment, as I'm modifying large amounts of code
<Keybuk> yet can be sure that I'm not unexpectedly changing behaviours I wasn't aware of
<Keybuk> just unexpectedly changing behaviours I hadn't tested <g>
<Keybuk> LCA was pretty cool actually
<Keybuk> is by far my favourite geek conference
<mbiebl> Yeah, the programme sounded really interesting, many very interesting people and projects.
<Keybuk> it usually is
<Keybuk> already thinking up my paper for Melbourne next year
<mbiebl> what topic?
<Keybuk> dunno yet
<mbiebl> btw. have you ever been on linuxtag (germany)?
<_ion> Congrats for the new release. :-)
<Keybuk> I've never made it to LinuxTag, no
<Keybuk> nor FOSDEM
<mbiebl> What a pity. I'm sure you'd have liked it too. Many geeks all over the place ;-)
<_ion> Obviously the best possible place to have such conferences in would be Tampere, Finland.
<Keybuk> yeah, it's one of the ones I keep missing
<Keybuk> too many conferences in a year ;p
<mbiebl> _ion: sounds cold ;-)
<Keybuk> Helsinki was nice
<_ion> About 30C currently. :-)
<mbiebl> argh...
<mbiebl> winter is currently running crazy here in Germany (+10C)
<mbiebl> I blame it on the global warming effect ;-)
<Keybuk> it's colder here (-7C)
<mbiebl> Keybuk: have you already started work on converting sysv style init scripts to upstart jobs?
<Keybuk> yes, most of the initscripts package
<mbiebl> Have you started with the core system (rcS) or with the multisession part (e.g. hal, dbus etc)?
<Keybuk> core system and dbus
<Keybuk> mostly because dbus is special and benefits from it
<mbiebl> So, will the packages itself directly ship the upstart job files or do you keep them inside the the upstart package?
<Keybuk> pretty much the same style as sysvinit
<Keybuk> upstart ships system-services and startup-tasks packages
<Keybuk> the former is basically what sysvinit ships in inittab
<Keybuk> and the latter is basically the old initscripts package
<Keybuk> other packages then ship upstart jobs
<Keybuk> e.g. dbus ships its own
<mbiebl> Let's take postfix as an example.
<mbiebl> Have you replaced the sysv init script with a upstart job, or do you ship both files?
<Keybuk> postfix I haven't touched
<Keybuk> if I were, I'd ship just the upstart job
<Keybuk> shipping both is bad, since upstart has the sysv compat stuff :)
<mbiebl> The reason, why I ask, is that for Debian I'll probably have to go for the second option.
<mbiebl> So people can switch between sysvinit and upstart.
<mbiebl> And I thought about diverting update-rc.d/invoke-rc.d for that reason.
<Keybuk> shipping both gives you the problem that you couldn't ship upstart-compat-sysv
<Keybuk> otherwise upstart would start postfix both natively *and* via sysv-rc
<mbiebl> Yeah, that's why I thought about diverting update-rc.d
<Keybuk> right
<Keybuk> that'd work
<Keybuk> you'd have to have a magic update-rc.d that "decided" whether the package also shipped an upstart config file
<mbiebl> Yeah, exactly.
<mbiebl> In Ubuntu it will be a bit more easy.
<Keybuk> yeah :)
<mbiebl> But for Debian I figured this would be the only way to provide a smooth conversion path.
<_ion> Make a sysvrc compatibility layer for upstart jobs!
<_ion> ;-)
<Keybuk> _ion: that's called "upstart"
<_ion> Hehe, yeah.
<mbiebl> Anyways, I'm off to bed now.
<Keybuk> g'nite
<mbiebl> As soon as I have a clearer view how to implement this for Debian, I'll probably pester you again, Keybuk
<Keybuk> sure
<mbiebl> n8 and cu
<Keybuk> oh, heh, some debugging code ended up in 0.3.2 by accident
<Keybuk> init: main: attach gdb to 1 now
<Keybuk> init: main: too late
<Keybuk> sweeeeeet
<Keybuk> test-stop: test failed main
<Keybuk> (stop)
<Keybuk> EXIT_STATUS = 1
<Keybuk> (from the following job:
<Keybuk>     start on stop test
<Keybuk>     script
<Keybuk>         echo "$UPSTART_JOB: $@"
<Keybuk>         echo "($UPSTART_EVENT)"
<Keybuk>         echo "EXIT_STATUS = $EXIT_STATUS"
<Keybuk>     end script
<_ion> Some more or less bad ideas for the 'FOO' in 'FOO frodo until bilbo', 'FOO with networking' etc: act, react, work, operate, reflect, respond, go, do, serve, comply, subscribe, yield, pursue, follow, obey
<Keybuk> tricky one, innit
<geo1> anyone home?
<Keybuk> mmm, refactoring
<Keybuk> today I'm trying to get the event-completion stuff finished
<_ion> "f*** with networking"
<Keybuk> hmm? :p
<_ion> Perhaps an expletive would be an appropriate 'FOO' ;-)
<Keybuk> rofl
* Keybuk just got that
* Keybuk takes a decision on state serialisation
<_ion> A decision?
<Keybuk> yes
<Keybuk> it's kinda broken in the face of event-completion and job-serialisation
<Keybuk> and has needed a rewrite for a while anyway
<Keybuk> (it uses a pipe and a text dump of the linked lists)
<Keybuk> since we have a stable IPC protocol, I don't want to close the control socket on restart anymore
<Keybuk> which means we can use that to serialise the state
<Keybuk> (much better tested code, much more efficient)
<Keybuk> and with the rewrite, I can fix the inherent problems with it (dumping linked lists isn't the right way)
<Keybuk> this won't be compatible with the code from older versions
<Keybuk> however, since those aren't tracking anything except the pid of getty ...
<Keybuk> ... I've decided to ignore that
<_ion> All right.
<Keybuk> the apparent bug will be that after updating upstart from current versions to 0.3.5, the state of any registered jobs won't be known
<Keybuk> they'll all appear to be stopped
<AlexExtreme> that wouldn't be that much of a problem, would it? the only problem it would cause on an upgrade from edgy to feisty (when it's released) would be that gettys wouldn't be stopped when you restart, no?
<Keybuk> righ
<Keybuk> t
<Keybuk> that's what I'm thinking
<Keybuk> the problem is minor, and can be knowledged-based with "restart your computer"
<AlexExtreme> yes
<AlexExtreme> and since on a edgy to feisty upgrade, you'll be prompted to reboot anyway for the kernel being upgraded, most people would hardly notice it
<Keybuk> right
<Keybuk> initially for feisty, upgrades won't restart upstart
<Keybuk> but that's ok, because the IPC protocol is stablish now
<Keybuk> and by the time feisty releases, I'll have replaced the restart code
<AlexExtreme> ok
<Keybuk> icky
<Keybuk> job->goal_event->event.name
<_ion> Heh.
<Keybuk> (where job->goal_event is the EventEmission structure referencing the event currently being handled that caused the job's goal to change ...
<Keybuk> ... I can't think of a better variable name)
<wasabi> As an aside, perhaps the ability for an upstart job to reassociate with an already running pid might be interesting?
<wasabi> Actually, shouldn't it?
<wasabi> Why would it not know the existing pids?
<Keybuk> why would it know them?
<Keybuk> exec() has a way of killing all the memory
<wasabi> well, thought that stuff would have been serialized to disk on a restart.
<Keybuk> serialised somewhere, certainly
<Keybuk> I Hate Valgrind
<Keybuk> it blatantly ignores its "don't follow children" option
<baze> hi
<Keybuk> baze: hi
<Keybuk> welcome
<baze> is upstart already usable for distros other than ubuntu? or will it ever, and is there a rough ETA?
<baze> i'm using arch here, which uses bsd init scripts... not sure if upstart can handle those
<Keybuk> upstart shipped with Ubuntu 6.10, with a set of jobs that emulate the behaviour of sysvinit
<Keybuk> this should be quite portable to other distributions
<Keybuk> as all you need do is modify the same set of jobs to match /etc/inittab on that distribution
<Keybuk> we've had people do it for Fedora, Gentoo, Frugalware, etc. already
<baze> so it should be possible already to use it in other distros?
<Keybuk> that gets you up and running pretty fast
<Keybuk> yes, absolutely
<baze> cool :)
<baze> i should give it a try
<Keybuk> the current release is suitable for deployment maintaining compatibility with the existing init scripts
<Keybuk> the next major release of upstart is suitable for deployment *replacing* the existing init scripts
<baze> but emulating the sysvinit stuff is not really the goal of course ;)
<Keybuk> right
<baze> so if i get it running, i should get all the fancy new stuff from upstart too, right?
<Keybuk> but it was a fantastic way to test the daemon
<Keybuk> shake all the bugs out
<Keybuk> and figure out what we needed
<baze> right
<Keybuk> yup, you get the new stuff as well
<baze> neat
<AlexExtreme> hmm
<AlexExtreme> let's try 0.3.2
<baze> hm, arch doesn't use /etc/rcn.d/ and that stuff but only /etc/rc.d with no use of different setups for different runlevels..
<Keybuk> baze: upstart doesn't try and implement that
<Keybuk> we cheat, and just run the /etc/init.d/rc shellscript that comes with sysvinit
<Keybuk> arch should have an equivalent shell script that iterates /etc/rc.d
<Keybuk> so just run that :)
<AlexExtreme> arch doesn't
<Keybuk> you'd probably not need runlevel, telinit, etc.
<Keybuk> and could get away with a simple single job
<baze> AlexExtreme is right, there is no such file in /etc/rc.d
<AlexExtreme> heh
<baze> do you use arch too or why did you know that?
<AlexExtreme> no
<AlexExtreme> I use Frugalware
<baze> others tried upstart with arch?
<baze> ah
<baze> is there a frugalware package for upstart?
<baze> couldn't find one with the package search
<AlexExtreme> no, there isn't. I'm maintaining it in a seperate repo for the moment, but by 0.7 it will be the default init system
<AlexExtreme> brb, just gonna test 0.3.2
<baze> fw uses the same init system as arch does, right?
<AlexExtreme> baze, no
<AlexExtreme> the only thing we (did) share was pacman
<baze> ok
<baze> i don't really know anything about fw besides the pacman stuff, as you see ;)
<AlexExtreme> and since now we forked pacman because we got sick of the way that pacman was being developed (i.e. remove as many features that aren't completely necessary as possible, and telling us that our patches "aren't valid" without saying why), we share absolutely nothing :)
<AlexExtreme> </rant>
<AlexExtreme> and 0.3.2 seems to work great
<AlexExtreme> Keybuk, would you mind adding Frugalware to the packages section on the upstart website?
<baze> so fw uses init.d and rc2.d and so on?
<AlexExtreme> not init.d
<AlexExtreme> /etc/rc.d/rc(whatever).d
<AlexExtreme> the init scripts are in /etc/rc.d
<baze> ok
<AlexExtreme> with names like rc.dbus, rc.hald, and so on
<baze> i see
<baze> well, that's pretty much like arch then
<baze> except the naming is different, if i understand it just a little bit correct ;)
<AlexExtreme> I wouldn't have thought so
<AlexExtreme> arch simply sticks the scripts in a dir and you configure the ones you want in rc.conf
<baze> yep
<baze> well anyway, could i have a look at your PKGBUILD? maybe that helps me a bit
<AlexExtreme> *FrugalBuild :)
<baze> gna ;p
<baze> idc :p
<baze> frugalbuild then
<AlexExtreme> http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/upstart/FrugalBuild
<baze> thanks
<AlexExtreme> it depends on sysvutils which is here: http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/sysvutils/FrugalBuild
<AlexExtreme> that's only for the sysv compat stuff though
<AlexExtreme> once the system is upstart-ized sysvutils won't be needed
<AlexExtreme> gotta go
<AlexExtreme> bye
<baze> bye
<Keybuk> AlexExtreme: wouldn't mind at all, give me a link :)
#upstart 2007-02-08
<Keybuk> X really doesn't like ioctl()s on its file descriptor
<Keybuk> wing-commander scott# cat /etc/event.d/test
<Keybuk> on wibble
<Keybuk> script
<Keybuk>         exit 1
<Keybuk> end script
<Keybuk> wing-commander scott# initctl emit wibble
<Keybuk> wibble
<Keybuk> test (start) waiting
<Keybuk> test (start) starting
<Keybuk> test (start) running, process 8155
<Keybuk> initctl: wibble event failed
<Keybuk> zsh: exit 1     initctl emit wibble
<Keybuk> -- 
<Keybuk> sweeeet
<Keybuk> wow, my laptop booted this morning *impressed*
<_ion> Ooh
<Keybuk> I'm finishing up merging the new state machine today
<_ion> Cool
<Keybuk> of course, I need to fix shutdown first
<Keybuk> yay, fixed that
<Keybuk> Committed revision 500
<Keybuk> woo
<_ion> \o/
<Keybuk> wing-commander scott# cat /etc/event.d/test
<Keybuk> start on wibble
<Keybuk> script
<Keybuk>         sleep 5
<Keybuk>         exit 1
<Keybuk> end script
<Keybuk> wing-commander scott# initctl emit wibble
<Keybuk> wibble
<Keybuk> test (start) waiting
<Keybuk> test (start) starting
<Keybuk> test (start) running, process 2941
<Keybuk> test (stop) running
<Keybuk> test (stop) stopping
<Keybuk> initctl: wibble event failed
<Keybuk> zsh: exit 1     initctl emit wibble
<Keybuk> yay
<_ion> Whee
<AlexExtreme> Keybuk, great job with the new features :) you asked for the link to the frugalware upstart repository, it's at http://ftp.frugalware.org/pub/other/people/alex/upstart
<AlexExtreme> also if you want an icon for it like debian and ubuntu have there, just use the favicon here: http://frugalware.org/
<Keybuk> ok, cool; thanks
<Keybuk> AlexExtreme: ok, linked
<AlexExtreme> thanks :)
<_ion> keybuk: Today's proposition for 'FOO': 'goal', as in 'goal frodo until bilbo', 'goal with multiuser', 'goal network-up until network-down and fhs-mounted until fhs-unmounted'
<Keybuk> heh
<Keybuk> well
<Keybuk> there goes the first of the old state machine ...
<Keybuk> 505 changed the enums
<mbiebl> Keybuk: do you have a BNF of the job file format (or a detailed spec)?
<mbiebl> I wanted to write a syntax file for vim over the weekend.
<mbiebl> So you get nice syntax highlighting on editing upstart job files ;-)
<Keybuk> I actually don't
<Keybuk> feel free to write one based on the config code
<Keybuk> let me quickly define it for you
<Keybuk> it's a line-based format; newlines end a stanza
<Keybuk> Comments begin with '#' and run up to the next newline
<Keybuk> whitespace chars are space, tab, \r and \n if inside quotes
<Keybuk> newlines inside single or double quotes are ignored
<Keybuk> s/ignored/treated as whitespace/ sorry
<Keybuk> a slash may be used to cause a single or double quote to be treated as a plain character
<Keybuk> and a slash may also be used to treat a newline as a whitespace character
<Keybuk> so that's the basic format
<Keybuk> an argument is a token of characters up until the first comment, whitespace or newline character that's not quoted
<Keybuk> examples
<Keybuk>   foo
<Keybuk>   bar
<Keybuk>   "foo bar"
<Keybuk>   foo\ bar
<Keybuk>   foo\
<Keybuk>   bar
<Keybuk> (last two lines is one arg)
<Keybuk>   "foo
<Keybuk>    bar"
<Keybuk> (likewise)
<Keybuk>   foo#foo bar
<Keybuk> (the token there is foo)
<Keybuk> a command is a token of characters up until the first comment or newline
<Keybuk> whitespace is part of the command
<Keybuk> commands are parsed according to shell rules (i.e. by running "sh -c $COMMAND" )
<Keybuk> the only other special thing is a block
<Keybuk> that begins on the line after the stanza, and is ended up the phrase "WS? end WS BLOCKTYPE WS? COMMENT? NL"
<Keybuk> see init/cfgfile.c for the list of stanzas, and how each one parses what follows
<Keybuk> next_arg eats one argument
<Keybuk> skip_comment eats a comment and the following newline
<Keybuk> parse_args eats all arguments to the end of the line
<Keybuk> parse_command eats the following command
<Keybuk> some stanzas are more complex than others, expecting second-level words
<mbiebl> Ok, thanks for the pointers.
<mbiebl> It will be a bit hard to detect a upstart job file, because it doesn't have a special file extension or shebang.
<Keybuk> they live in /etc/event.d :p
<Keybuk> easy
<mbiebl> Yeah, this is the metric I use already ;-)
<Keybuk> I don't like "extensions"
<Keybuk> you end up with something silly like ".job"
<Keybuk> or
<Keybuk> /etc/udev/rules.d/foo.rules
<Keybuk> (or, worse)
<Keybuk> /etc/udev/rules.d/foo-udev.rules
<Md> Keybuk: did you add a regexp to ignore dot files, rpm/dpkg/emacs/vi backup files, etc?
#upstart 2007-02-09
<Keybuk> yeah, it has that
<mbiebl> Keybuk: I've been toying around a bit with r502
<mbiebl> And with minor updates to the job files it works fine.
<mbiebl> I was just wondering, why the job files have all these "stop on shutdown|runlevel-x" stanzas
<mbiebl> For scripts, stop is never really called, right?
<Keybuk> well
<Keybuk> because they're rc scripts
<Keybuk> and sysv was never designed with running the rc6 (reboot) script while starting into rc2
<Keybuk> I have that so if you press Ctrl-Alt-Del while booting, it stops booting, and switches into reboot
<Keybuk> which is roughly compatible
<Keybuk> oh
<Keybuk> you'll want the new job files
<Keybuk> heh
<mbiebl> well, i used the old ones compat job files and adapted them.
<Keybuk> http://upstart.ubuntu.com/new-example-jobs/
<Keybuk> the main differences are
<Keybuk> 1) "runlevel" is now a single event, with an argument specifying the new runlevel
<Keybuk> 2) "shutdown" is no more
<Keybuk> so things now just "stop on runlevel" (ie. kill the running rc script if the runlevel changes)
<mbiebl> Cool, I'll try these ones.
<Keybuk> they work for me
<Keybuk> which isn't to say much
<Keybuk> I found a pretty nasty error with logd in the process though
<Keybuk> which is why they're console output for now
<_ion> pe011840 < Keybuk> I don't like "extensions"
<_ion> Amen to that.
<Keybuk> ok
<Keybuk> well
<Keybuk> that's job_change_state () rewritten
<Keybuk> which could be happily described as the most core function
<Keybuk> it actually got a *lot* simpler
<Keybuk> which I think is encouraging
<_ion> Nice.
<Keybuk> of course, none of it *compiles* yet :p
<_ion> Naaah, having it compile isn't as important as they say. :-)
<Keybuk> it's annoying that the tests don't compile either
<Keybuk> so I'm not sure if the changes I'm making to them are right :p
<Keybuk> lots of things had assumptions about the state model
<_ion> Have you already implemented it as a lookup table (i think you mentioned something like that earlier), or are the state decisions still plain code?
<Keybuk> plain code
<Keybuk> much more efficient
<int0x0c> What is the status of Upstart on Gentoo?
<int0x0c> Has there been any effort to write a backend for it?
<Keybuk> it shouldn't need a "backend" ?
<_ion> He probably means a compatibility layer.
<int0x0c> _ion, yep, thanks
<int0x0c> wrong terminology
<Keybuk> there's been a few efforts to write jobs that emulate the existing Gentoo init system
<Keybuk> I haven't actually seen any completed ones yet though
<int0x0c> hmm
<int0x0c> alright
<Keybuk> _ion: do you remember who was doing them?
<_ion> Sorry, nope.
<_ion> 2006-12-15 19:52:46 < steev64> as much as people are going to hate me for it (not necessarily *in here*), I am trying to get up
<_ion> start working on Gentoo
<Keybuk> Sep 13 22:28:06 <rubengonc>     i am trying it on gentoo
<Keybuk> Oct 04 17:12:15 <smlgb1>        Hi there. Did anybody of you try to install upstart on gentoo yet?
<Keybuk> we should get these people together :p
<_ion> 2006-10-27 23:31:21 < phsdv> hi all, I just managed to get my gentoo system booted using upstart.
* ..[topic/#upstart:Keybuk] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
<Keybuk> http://upstart.ubuntu.com/wiki/UpstartOnGentoo
<Keybuk> :p
<_ion> :-)
<int0x0c> I might try my hand this weekend at getting upstart going
* Keybuk embarks on updating the job_change_state() test suite ... ouch
<Keybuk> http://upstart.ubuntu.com/wiki/JobStates?action=AttachFile&do=get&target=states.png
<Keybuk> I am *so* glad I did that ^
<_ion> :-)
<Keybuk> though I've added to it since then
<Keybuk> mbiebl: re
<mbiebl> Keybuk: yes?
<Keybuk> just hi
<mbiebl> ah, thanks ;-)
<mbiebl> About Md's question:
<mbiebl> Seems as if in r502, dpkg-(old|new) files are not ignored.
<Keybuk> uh, maybe I didn't push that yet
<Keybuk> does nih/file.c have a nih_file_is_packaging ?
<mbiebl> nope
<Keybuk> ah
<Keybuk> woo, she compiles again!
<Keybuk> whee
<Keybuk> I wasn't hallucinating last night; the test cases *do* pass
<phsdv> congrats!
<Keybuk> am trying to decide whether to continue to allow "respawn COMMAND" as a shortcut for both "exec COMMAND" and "respawn"
<Md> yes. syntactical sugar is nice :-)
<Keybuk> well, moment of truth
* Keybuk starts it
<Keybuk> http://rafb.net/p/s2LD5c17.html
<Keybuk> sweeeeeeet; ^ new job life cycle
<Keybuk> note that the "test" job doesn't get to start until "test2" finishes, because test2 is marked "start on starting test"
<Keybuk> http://rafb.net/p/HtgNXP55.html
<Keybuk> ^ example of a job that needs another running
<Keybuk> note how hal is started once dbus is running, but that when dbus is stopped, hal actually gets stopped first and dbus isn't stopped until hal is
<Keybuk> http://rafb.net/p/eGZbr976.html
<Keybuk> ^ and there's a counter-example of the opposite behaviour
<Keybuk> tomcat is able to indicate that "apache needs it", so when you try and start apache, you get tomcat started *first*
<giuseppe_> hi, i'm building a smal linux distro for learning purpose, and i was searching for something dealing with dependencies between daemons. I see upstart has removed this feature (https://launchpad.net/upstart/+spec/remove-depends). Does anyone has suggestions? are there init implementations dealing with dependencies? 
<Keybuk> for what reason do you want dependencies?
<Keybuk> there are (currently) four basic classes of init daemon, which all handle the problem differently:
<Keybuk> 1) those that run scripts in order, so the order expresses "what must come first"
<Keybuk>    e.g. sysvinit
<giuseppe_> Keybuk: because i don't want to hardcode init scripts. I'm listening btw
<Keybuk> 2) those that run everything at once, and expect the jobs to sort themselves out
<Keybuk>    e.g. launchd
<Keybuk> 3) those that use a package-manager style dependency chain, when you start a daemon anything it "depends" on is started first (and likewise, when you stop a daemon, it's dependencies aren't stopped until afterwards)
<Keybuk>    e.g. Solaris SMF, init-NG
<Keybuk> 4) those that use events; when you start or stop a daemon, it issues events; other daemons can be started or stopped by those events; and block the other
<Keybuk>    e.g. upstart
<Keybuk> I assume that #1 is what you're already familar with, and #2 isn't useful
<giuseppe_> ok so basically you're telling me to read the upstart doc better :)
<Keybuk> the upstart docs aren't that good :p
<Keybuk> (yet)
<Keybuk> my two usual examples are dbus/hal and apache/tomcat
<Keybuk> hal needs dbus to be running while it is, if dbus is stopped, hal must be too
<Keybuk> tomcat is needed by apache if installed, so apache is started, tomcat must be started first (and tomcat must not be stopped until apache is)
<giuseppe_> ok this is not possible with simple dependencies then.. you have to use events
<giuseppe_> from what i understand
<Keybuk> in a dependency-based system you might try something like
<Keybuk>   hal depends dbus
<Keybuk>   and hal is a goal
<Keybuk> so when you start hal, dbus is started first
<Keybuk> the second one is more tricky in a dependency-based system because you don't want to edit the apache job description just because tomcat is installed
<Keybuk> so you actually need something like
<Keybuk>   tomcat is-dependency-of apache
<Keybuk>   and apache is a goal
<Keybuk> (the first being in the tomcat description)
<giuseppe_> ok very clear
<giuseppe_> thanks Keybuk 
<Keybuk> don't know whether initNG supports that
<Keybuk> I know SMF doesn't
<Keybuk> in a event-based system, like upstart, you instead hook the events generated by hal, dbus, apache, tomcat, etc.
<Keybuk> so you might use something like
<Keybuk>   hal: start on starting dbus
<Keybuk> err
<Keybuk> sorry
<Keybuk>   hal: start on started dbus
<Keybuk>   hal: stop on stopping dbus
<Keybuk> and for the tomcat case, it's easy
<Keybuk>   tomcat: start on starting apache
<Keybuk>   tomcat: stop on stopped apache
<Keybuk> http://rafb.net/p/HtgNXP55.html
<Keybuk> http://rafb.net/p/eGZbr976.html
<Keybuk> (those two URLs given an example of both of those)
<giuseppe_> Keybuk: thank you very much i'm going to read
<Keybuk> in theory, the event-based system requires less manual or semi-automatic configuration
<Keybuk> you can ship job definitions that do the right thing
<Keybuk> and you don't need to modify other jobs or goals when you install a new daemon
* Keybuk makes yet another tweak to the state diagram
<giuseppe_> hi, i'm having troubles compiling upstart with gcc 3.3.5, is it a known issue?
<giuseppe_> child.c: In function `nih_child_poll':
<giuseppe_> child.c:141: error: `WEXITED' undeclared (first use in this function)
<AlexExtreme> yes
<AlexExtreme> upstart only compiles with 4.x afai
<AlexExtreme> *afaik
<giuseppe_> :|
<Keybuk> that's more likely an out of date libc
<AlexExtreme> ah
<Keybuk> upstart needs both kernel and libc support for the waitid() system call
<AlexExtreme> yeah
<giuseppe_> i'm using debian's 2.3.2.ds1-22
<giuseppe_> is there a particular libc version waitid() is available from?
<Keybuk> 2.4 seems fine
<Keybuk> there's a Debian package already
<Keybuk> http://packages.debian.org/experimental/admin/upstart
<giuseppe_> yep even 2.3.6 is ok
<Keybuk> though it's a little out of date; if you have those build-deps, you should be fine
<int0x0c> Have the upstart service files for the base ubuntu installation been developed yet (i.e. not the initrd wrapper)
<Keybuk> int0x0c: they'll be available by monday
<int0x0c> heh, wow, I picked quite a time to ask
<AlexExtreme> woohoo :)
<int0x0c> Are they in bzr at the moment?
<giuseppe_> Keybuk: yes the problem is i'm trying to maintain a cross toolchain.. :|
<AlexExtreme> Keybuk, let me know when/where I can get them when they are released, I can't wait to try it :)
<Keybuk> no; I have a bunch of them on my laptop, but they're a bit broken because I'm busy rewriting upstart :p
<Keybuk> and keep changing things
<giuseppe_> Keybuk: i'm using this libc config: http://rafb.net/p/Kv1hho71.html, do you see problems with it? it is relative to glibc 2.3.6
<int0x0c> What is the bzr branch?
<Keybuk> int0x0c: for?
<int0x0c> the service files
<Keybuk> giuseppe_: I don't really know libc compiles; I would imagine it's fine
<Keybuk> int0x0c: there isn't one just yet
<Keybuk> I'll get them published this weekend :)
<int0x0c> bah, alright
<int0x0c> thanks a ton
<Keybuk> (I could publish them now, but they wouldn't work for you :p)
<Keybuk> http://upstart.ubuntu.com/states.png
<Keybuk> ^ now, isn't *that* neater
<AlexExtreme> nice
<AlexExtreme> don't you just love dot ;)
<int0x0c> Keybuk, I'm running gentoo
<int0x0c> Keybuk, and looking into writing a set of services
<int0x0c> Keybuk, I just need something for reference
<int0x0c> If you had a sec, I would love a tarball
<int0x0c> but don't worry about it if not
<AlexExtreme> as he said, they won't work right now :)
<Keybuk> I understand that :)  these just literally aren't ready right now
<Keybuk> they're not even useful for reference
<int0x0c> ahh, alright
<int0x0c> fair enough
<Keybuk> interesting; excluding tests, upstart 0.2.7 was 9,204 lines of code
<Keybuk> since then (also excluding tests)
<Keybuk>  36 files changed, 6899 insertions(+), 4654 deletions(-)
<Keybuk> so I've changed roughly 50% of the code
<Keybuk> that's kinda cool
<AlexExtreme> yeah
<Keybuk> test suites rock for this kind of mass-scale refactoring
<Keybuk> a more odd stat ...
<Keybuk> 0.3.5 has 11,360 lines of code ... but only 2,835 semi-colons
<AlexExtreme> hah
<AlexExtreme> I wish I could code as fast as this ><
<Keybuk> the usual metric is 2.5 logical lines to a semi-colon
<AlexExtreme> so for feisty do you reckon only the base services will be converted to upstart jobs for feisty's final release, seeing as feature freeze has started (it has, hasn't it?) ?
<Keybuk> which makes upstart about 35% comments
<AlexExtreme> hmm, just realised I said "for feisty" twice. ignore that :p
<Keybuk> that's the plan
<Keybuk> always has been, actually
<AlexExtreme> mmm, k
<Keybuk> most daemons will retain sysv init scripts for feisty
<Keybuk> except the interesting ones
<AlexExtreme> like dbus?
<Keybuk> right
<Keybuk> ok, that's config file deletion support pushed
* Keybuk looks at his TODO list for what's next
<Keybuk> I guess I should run valgrind over the new core :p
<AlexExtreme> :P
<Keybuk> shouldn't be any problems, since I didn't much around with memory stuff
<Keybuk> all good
<_ion> So you made "deleted" a state. That's good.
<Keybuk> yeah, it made the most sense
<Keybuk> it's the most trivial way of handling all the cases
<Keybuk> - means it can't be started again, since it's not in the waiting state
<Keybuk> - means that all deleted jobs can be quickly found and freed
<Keybuk> - means that clients know that it's being deleted
<Keybuk> etc.
<_ion> Indeed.
<Keybuk> it even means the clients can detect when they tried to start a deleted job :p
<Keybuk> start "foo"
<Keybuk> foo (stop) deleted
<Keybuk> bloody ISP
#upstart 2007-02-10
<_ion> 27C outside. \o/
<Keybuk> Feb 10 13:49:23 wing-commander init: /etc/event.d/4913: unable to read: Invalid argument
<Keybuk> grr @ vim
<_ion> :-\
<Keybuk> it really does write a file called 4913 into the current directory when you modify something
<Keybuk> go figure
<_ion> Perhaps the directory watching code should do something like "wait one second after things have stopped changing"
<_ion> and then react
<_ion> That should take care of any evil things editors might do with temporary files.
<_ion> The very same feature would be useful in the future when "file/directory changing" can be used as triggers for upstart jobs.
<_ion> I.e. "watch directory /foo, do this when things have changed and there have been no more changes for 15 seconds"
<Keybuk> yeah, will have to think how to smooth that kind of thing out
<Keybuk> 15s is a long time though
<_ion> That was just an example of an arbitrary number a user might choose.
<_ion> Not something we'd want for watching /etc :-)
<_ion> /etc/event.d even
<Keybuk> it's vaguely useful in many cases
<_ion> A use case: i define a job that watches www-dir/apt-repo-incoming, and when one *minute* has passed from changes, it copies things to www-dir/apt-repo and runs falcon. I might want this because i manually copy things to it, and want to have up to a minute of time between copying individual files until the thing is actually triggered.
<Keybuk> some editors just modify the file directly
<Keybuk> some copy the file to a backup and modify the file itself
<_ion> Yeah.
<Keybuk> some write a temporary file, and move it over the previous file
<Keybuk> at some point, I need to rethink the way process ids are stored in the Job
<Keybuk> right now there's just job->pid and job->aux_pid
<Keybuk> I'm temped to move the pid to underneath the process definition
<Keybuk> job->process->pid, job->pre_start->pid, job->post_start->pid, etc.
<Keybuk> and then I could enum those
<Keybuk> job->process[PROCESS_PRE_START] ->pid
<Keybuk> and then we can add arbitrary actions
<Keybuk> id = job_action_id (job, "reload");
<Keybuk> job->process[id] ->pid
<Keybuk> actually, I just found another reason to do that
<Keybuk> then job->failed_state could actually be the *process* that failed :p
<Keybuk> http://rafb.net/p/fOPZlY98.html
<Keybuk> ^ \o/
<Keybuk> so, here's a poser
<Keybuk> when you change a job's configuration file, should it
<Keybuk> a) modify the configuration of the running job
<Keybuk> b) mark the running job to be deleted when it stops, and use the new configuration for any new instances started later
<Md> is implementing a actually possible?
<Keybuk> a is what is currently implemented
<Keybuk> but I'm increasingly thinking it's wrong
<Keybuk> it works for debugging, "a quick edit to fix the job"
<Keybuk> but I think in practice b is better, because changes to the job file are likely to be upgrades
<Keybuk> and you might end up with a post-stop script that wasn't intended for the running process, since it doesn't match what pre-start did at the time
<Keybuk> silly things, like what if the upgrade changed the pid file location?
<Keybuk> or the run directory location
<Keybuk> that's an issue we have todya
<Keybuk> would be nice to fix it
<_ion> b sounds good.
<theCore> a) seems scary to me.
<theCore> it seems to beg for race-conditions
<Keybuk> yeah, like a pre-start script being run; the config file getting read; and a different process all together getting run afterwards
<Md> Keybuk: yes, I agree that b would be better
<AlexExtreme> Keybuk, just found an upstart bug - if you hit ctrl+alt+del multiple times, it will try to shut down multiple times
<Keybuk> right, yes?
<AlexExtreme> well, that shouldn't really happen, should it?
<Keybuk> dunno
<Keybuk> change "stop on runlevel" to "stop on runlevel [^6] "
<Keybuk> :p
<AlexExtreme> :p
<mbiebl> Keybuk: I got a small problem with current svn
<mbiebl> Seems as if kill -s TERM 1 in postinst
<mbiebl> causes upstart to run sulogin (which kills my keyboard on X)
<Keybuk> yes
<Keybuk> it does that
<Keybuk> normally it kills the entire X server
<Keybuk>         * WARNING: if you have any job declared "console owner" which is
<Keybuk>           run by the "stalled" event, comment out the "start on" stanza
<Keybuk>           before sending the TERM signal -- otherwise the newly started
<Keybuk>           process will start that job, which will kill your running X
<Keybuk>           server.
<mbiebl> Hm, it didn't do that with <=0.3.2
<mbiebl> Is that a recent change?
<Keybuk> yes
<Keybuk> it's a "lack of a feature"
<Keybuk> I disabled the stuff that serialised the state between upstart instances, because it was a mess and hard to maintain
<Keybuk> I plan to put it back sometime in the couple of releases
<mbiebl> ok
<wasabi_> hey, quicky casper question since I know ya'll know a lot about it. ;)
<wasabi_> Trying to copy the feisty boot CD to a USB drive, to install on a system without a CD.
<wasabi_> filesystem.squashfs is what casper needs to mount... the vmlinuz and initrd.gz are obvious. What option tells casper how to find filesystem.squashfs?
<Keybuk> it hunts for it
<Keybuk> it's in the casper-local initramfs script
* wasabi_ installs casper!
<wasabi_> would ideally just be an option to mount a certain efs2 partition with a static path. ...  *hopes*
<Keybuk> it might be
<wasabi_> hopefully the initramfs does usb mass storage by default. =/
<Keybuk> it should
<Keybuk> ./usr/share/initramfs-tools/scripts/casper
<wasabi_> hmm LIVEMEDIA maybe
<Keybuk> it might be fixed as /casper/*.squashfs
<wasabi_> That'll be fine. I just have to be able to point it to /dev/sdb3
<wasabi_> And it has to wait for it to appear.
<wasabi_> Or... /dev/sd something.
<wasabi_> Actually I won't know.
<Keybuk> it should just fine it
<Keybuk> uh, find it
<wasabi_> # or do the scan of block devices
<Keybuk> it checks all block devices
<wasabi_> bah. grub doesn't like this. prints GRUB and dies.
<wasabi_> wonder how I fix that one.
<wasabi_> ... how does grub find it's stage2 anyways?
<wasabi_> well this is obnoxious.
* ..[topic/#upstart:Keybuk] : Upstart 0.3.5 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo
<wasabi_> Odd. So I've got it booted into the initrd... casper breaks... probably can't find the livefs.
<wasabi_> Guess I can just mount it manually.
<wasabi_> nope. blah.
<wasabi_> i've got it at an initramfs prompt though. that's good enough. i'm going on a road trip and at least needed it that far. ;)
<wasabi_> I can do the rest by hand in the car.
#upstart 2007-02-11
<_ion> Does anyone know which tool Keybuk uses for keeping the ChangeLog file updated in bzr?
<_ion> Phew. Today was one of the few days of a year when i actually manage to get some code done despite my health issues. I wrote http://soijabanaani.net/tmp/nih_watch_delayed.diff
<_ion> Writing that took like ten times the time it would have taken if i could concentrate normally.
<_ion> Here's also a small parenthesis fix, http://soijabanaani.net/tmp/nih_hash_foreach_parenthesis.diff
<phsdv> int0x0c, are you trying to get upstart going on gentoo?
<phsdv> I just uploaded an ebuild for 0.3.5 into gentoo bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=150190) 
<Keybuk> so, I came up with a neat idea ...
<Keybuk> you know how we have emits ?
<Keybuk> that'd be a really nice way of defining special events
<Keybuk> job lists the event names with the emits stanza
<Keybuk> and when started, sends a message to upstart saying that it wants active notification of registrations
<Keybuk> upstart sees it's from a pid of a known job, that has listed emits stanzas
<Keybuk> so sends the job back as a reply every use of "on THAT-EVENT"
<Keybuk> and whenever new jobs are registered, or jobs are deleted, keeps that process up to date
<Keybuk> e.g.
<Keybuk> a job called "inetd"
<Keybuk> emits tcp udp
<Keybuk> connects to upstart
<Keybuk> and receives information that there are jobs with
<Keybuk> on tcp 80
<Keybuk> on udp 53
<Keybuk> etc.
<Keybuk> so it knows to listen on those ports, and knows to emit events with those arguments
<AlexExtreme> sounds good
<AlexExtreme> so, there's most of the work for replacing inetd done? :P
<Keybuk> it means you can take exotic events out of the core
<Keybuk> don't want inetd support?  don't run upstart-ientd
<AlexExtreme> yes
<Keybuk> useful for the dbus proxy too
<Keybuk> on dbus com/redhat/dhcp/eth0 com.redhat.dhcp.down
<Keybuk> so it'd know to listen to that signal, and emit that evnet
<_ion> keybuk: Ooo, really nice idea.
<_ion> keybuk: Any comments about the watch_delayed thing?
<Keybuk> I looked at the code, and it looked pretty good
<Keybuk> haven't had a chance to test it yet; want to get complex-event done today since we want that asap
<_ion> All right.
<Keybuk> will look at it properly this week : )
<_ion> You might want to include nih_hash_foreach_parenthesis.diff immediately though, it fixes a bug. :-)
<Keybuk> yeah, I saw that
<Keybuk> thanks!
<Keybuk> can you paste me a changelog for that one
<_ion>         * nih/hash.c (NIH_HASH_FOREACH, NIH_HASH_FOREACH_SAFE): Added missing parenthesis.
<_ion> Is that enough? :-)
<_ion> Duh, nih/hash.h, not .c
<_ion> What tool do you use to maintain the changelog and have it integrated with bzr commits, btw?
<_ion> A bzr plugin?
<Keybuk> a shell script
<_ion> Is it available for downloading? :-)
<Keybuk> http://people.ubuntu.com/~scott/software/bzr-commit
<_ion> Thanks
<Keybuk> I maintain the ChangeLog first using emacs (C-x 4 a)
<Keybuk> and then just use that to do the commits, with the changelog diff
<Keybuk> actually -- can you commit your watch delayed stuffa
<Keybuk> and push it to a branch of your own?
<Keybuk> something like
<_ion> Actually i did commit it to a branch of my own in the first place, but decided just to send a diff because i hadn't written changelog entries or commit messages using the format you use in your repository. I'll do that now, using that script. :-)
<Keybuk> bzr push sftp://ion@bazaar.launchpad.net/~ion/libnih/watch-delayed
<Keybuk> I think is the format
<Keybuk> that should automatically register it on https://code.launchpad.net/libnih
<_ion> keybuk: https://code.launchpad.net/~ion/+branch/libnih/watch-delayed
<Keybuk> excellent
<Keybuk> wing-commander scott% ./parse "foo bar baz until frodo bilbo and eep"
<Keybuk> Operator (AND)
<Keybuk>     Event ("eep")
<Keybuk>     Operator (UNTIL)
<Keybuk>         Event ("frodo", "bilbo")
<Keybuk>         Event ("foo", "bar", "baz")
<Keybuk> \o/
<Keybuk> now to figure out whether I've got the precedence right :p
<_ion> \o/
<Keybuk> wing-commander scott% ./parse "foo until bar and frodo until bilbo"
<Keybuk> Operator (AND)
<Keybuk>     Operator (UNTIL)
<Keybuk>         Event ("bilbo")
<Keybuk>         Event ("frodo")
<Keybuk>     Operator (UNTIL)
<Keybuk>         Event ("bar")
<Keybuk>         Event ("foo")
<_ion> keybuk: You should be able to pull the nih/hash.h fix and nothing else by running bzr merge --pull -r 386 http://bazaar.launchpad.net/~ion/libnih/watch-delayed, i think.
<_ion> The actual delayed watch code is in revno 387.
<Keybuk> wing-commander scott% ./parse "set timer until (boom or kaboom)" 
<Keybuk> Operator (UNTIL)
<Keybuk>     Event ("set", "timer")
<Keybuk>     Operator (OR)
<Keybuk>         Event ("boom")
<Keybuk>         Event ("kaboom")
<Keybuk> \o/
<_ion> \/
<AlexExtreme> :)
<_ion> keybuk: Have you decided a name for the complex-event-spec stanza yet? :-)
<Keybuk> wing-commander scott% ./parse "fhs-filesystem-mounted until fhs-filesystem-down and network-up until network-down"
<Keybuk> Operator (AND)
<Keybuk>     Operator (UNTIL)
<Keybuk>         Event ("fhs-filesystem-mounted")
<Keybuk>         Event ("fhs-filesystem-down")
<Keybuk>     Operator (UNTIL)
<Keybuk>         Event ("network-up")
<Keybuk>         Event ("network-down")
<Keybuk> _ion: nope
<Keybuk> wing-commander scott% ./parse "with apache or with thttpd"
<Keybuk> Operator (OR)
<Keybuk>     Operator (WITH)
<Keybuk>         Event ("apache")
<Keybuk>     Operator (WITH)
<Keybuk>         Event ("thttpd")
<Keybuk> yay
<Keybuk> even unary works
<_ion> Whee
<_ion> D'oh, i wrote "patch change events" to the changelog entry. :-)
<Keybuk> oops
<Keybuk> ok, I think the parser works
<Keybuk> got to make config respect parens as newline escapers, then try and recodify my ugly quick C into a stanza parser
<Keybuk> interesting question
<Keybuk> should this:
<Keybuk>   FOO blah and (blah until blah       # some comment
<Keybuk>                 or blah until blah)
<Keybuk> be valid
<Keybuk> (ie. comment inside parens
<_ion> I don't see why not. Someone might want to do something like this, while testing something:
<Keybuk> it's kinda unique in the format, since nothing else uses parens
<_ion> FOO something something (something # comment out the rest of the line, something something
<_ion>                          # comment out also this part, something something)
<_ion>                          new stuff)
<Keybuk> and I do think not being required to escape newlines inside parens is useful
<AStorm> Hello.
<Keybuk> hey AStorm
<Keybuk> _ion: merged 386
<AStorm> I've ran upstart on Gentoo, basic compatibility right now
<AStorm> (running large /sbin/rc, and requires a small modification of one script)
<Keybuk> sweet, do you have the details of what needs to be done?
<AStorm> I'm developing a fully event-based init system for it.
<Keybuk> planning to ship some example jobs in the upstart tarball directly with the next version, would be cool to have a gentoo subdir in there
<AStorm> And I've some questions, esp. regarding mounting
<Keybuk> sure
<AStorm> Is there something like stop for these?
<AStorm> Like the default plain exec is start
<AStorm> then stop would be ran on stopping.
<Keybuk> sorry, not sure I understand
<AStorm> Or do I have to use post-stop?
<AStorm> You know, I don't want to split the event in two.
<Keybuk> oh, I see what you mean
<Keybuk> upstart's jobs aren't quite analogous to init scripts
<AStorm> (could do this with unmount-dev script for "on stopped mount-dev")
<AStorm> I'd rather have it called directly in one script.
<Keybuk> you can do it one of two ways
<AStorm> Can do this in post-stop right now...
<Keybuk> have two jobs, mount and unmount
<AStorm> (or in pre-stop)
<Keybuk> one that mounts things, one that unmounts them
<AStorm> But it feels unclean.
<Keybuk> and have them otherwise unrelated
<Keybuk> or
<Keybuk> you can have them in one job
<AStorm> related related
<Keybuk> if you have them in one job, put the mount stuff in pre-start
<Keybuk> and the unmount stuff in post-stop
<AStorm> By the unmount one would dep "on stopped mount-dev"
<Keybuk> and don't have an exec or a script
<Keybuk> the job would appear to be "running" all the time the disk is mounted
<AStorm> Exactly.
<Keybuk> (note that there's a sliiight bug there atm)
<AStorm> Bug? What kind of?
<Keybuk> it won't ever actually stop
<AStorm> hmm.
<Keybuk> it slipped in at the last minute yesterday before I released 0.3.5
<AStorm> Right, because it's no daemon and there's no SIGCHLD, right?
<Keybuk> I didn't have a good enough test case for it
<AStorm> Funny bug. So, for now, I'll split the script.
<Keybuk> right; because when the stop event comes in, it will only change the goal to stop -- and won't force a state change
<AStorm> Funny.
<Keybuk> this worked a few days ago
<AStorm> Not a problem with me, but with the users...
<AStorm> Now to unmount the device, they'd have to "start" the unmount
<AStorm> not stop the mount :-) A bit illogical.
<Keybuk> would you have one job per mounted disk, or one job for all of fstab ?
<AStorm> Rather the first one
<Keybuk> right 
<AStorm> But the job would work using an argument.
<Keybuk> for the first one, you'd do something like:
<Keybuk>    instance
<Keybuk>    start on block-device-added
<Keybuk>    stop on block-device-removed
<Keybuk> or something
<AStorm> Yes, something like that probably.
<Keybuk> the instance bit is important, it tells upstart that multiple copies can be running
<AStorm> But right now, it's /dev mounting, which is doubly funny
<Keybuk> (temporary fix
<Keybuk> rather than splitting into two jobs, just have a dummy script
<AStorm> Aha, nice, undocumented.
<Keybuk> pre-start script
<Keybuk>    # mount stuff
<Keybuk> end script
<AStorm> Fine, very fine.
<Keybuk> post-stop script
<Keybuk>    # unmount stuff
<Keybuk> end script
<AStorm> I know. the bug is just when I exec something, right?
<AStorm> (in full start)
<Keybuk> script
<Keybuk>    while true; do sleep 1000; done
<Keybuk> end script
<_ion> sleep inf
<Keybuk> the script...end script will mean that there's a process running while the disk is mounted
<Keybuk> _ion: does that work? :p  neat
<Keybuk> exec sleep inf
<Keybuk> :p
<_ion> It works with GNU sleep, but not with e.g. the BSD one.
<AStorm> Keybuk, uh, a bit evil hack, but temporarily I'll do that.
<Keybuk> then this week, when I fix that bug, you can drop the sleep :p
<AStorm> _ion, not a problem here, it's Gentoo and it's temporary.
<AStorm> Good, very good.
<Keybuk> the bug is that it won't force a state change out of running if there's no pid; because the child reaper calls job_change_goal and doesn't want a state change as a side-effect
<AStorm> The major thing will be forcing udev to generate events
<AStorm> the default rules don't do that
<Keybuk> this turns out to be wrong, simply because the child reaper actually does want to force a state change as a side-effect :p
<Keybuk> so all I need to is fix the child reaper, and remove the bogus check from job_change_goal
<Keybuk> need to write some test cases for it first though
<AStorm> Just check the state
<AStorm> after running some echo in pre-start
<AStorm> and something else in post-stop
<AStorm> (e.g. some file write), then check if the file was written
<AStorm> Without any exec inside.
<AStorm> I wonder if initctl stop thatservice would hang
<Keybuk> sorry?
<AStorm> The state would change properly to stopping?
<AStorm> Is it just that the task doesn't enter "waiting" state?
<AStorm> or something else totally?
<AStorm> Or just that it finishes too early?
<Keybuk> post-stop gets run in stopping
<Keybuk> and then it should go to waiting
<Keybuk> initctl hangs is probably the bug
<AStorm> Hmm, the test would be quite hard.
<AStorm> Because of the hang, you'd have to use shell job control with some timeout.
<AStorm> damned halting problem, eh? :P
<phsdv> AStorm, I have made an ebuild for 0.3.5 (in bugzilla). If you needs some help with your new scripts on gentoo, pls let me know
<AStorm> Well, the help would be wrt making udev send upstart events
<AlexExtreme> that's easy
<AStorm> I've overwritten my init with upstart currently, have the stupid way of compatibility (running full gentoo init) working
<AStorm> AlexExtreme, so then, describe it to me, I'd be grateful.
<Keybuk> AStorm: RUN+="initctl emit some-event"
<phsdv> ACTION=="add",    SUBSYSTEM=="block", KERNEL=="*[!0-9] ", RUN="/usr/sbin/initctl emit block-device-added %k"
<AStorm> I'm not a master of init rules...
<AlexExtreme> damn
<AlexExtreme> beat me to it :)
<AStorm> phsdv, ok, so simple :-)
<AStorm> So I'll have to also do a package of udev rules - expected that.
<phsdv> I had them ready... wrote them a while ago
<Keybuk> phsdv: add "-eDEVNAME" to that
<phsdv> -eDEVNAME?
<AStorm> phsdv, could you mail them to me then? (or put somewhere I can get them)
<AStorm> The parameter, you know
<AStorm> or environment variable DEVNAME
<Keybuk> phsdv: put the DEVNAME environment variable in the environment of any job run by the block-device-added event
<_ion> -eBAR without =quux grabs the value from the current environment? Nice.
<AStorm> Great. It's so bad the upstart is so undocumented yet :-)
<phsdv> ACTION=="remove", SUBSYSTEM=="block", KERNEL=="*[!0-9] ", RUN="/usr/sbin/initctl emit block-device-removed %k"
<phsdv> ^ same for remove 
<AStorm> phsdv, I know, I know.
<Keybuk> AStorm: heh, I do have "document it" high on the TODO list
<Keybuk> though remember, a lot of the features you're using today were only written in the last week <g>
<AStorm> Keybuk, hehe, I'll do something like that
<AStorm> when I finish full gentoo init script compat
<AStorm> which will consist of modified depscan.sh and runscript.sh
<AStorm> (to store the dependencies in upstart scripts)
<AStorm> Maybe also some mapping, like: net="network-device-eth0:network-device-eth1"
<AStorm> The hardest part will be deps of type "use"
<AStorm> The script would have to check the list of added services (simple, right :P )
<AStorm> Keybuk, is it possible to parametrise the dependencies, so I don't have to generate scripts?
<AStorm> As in the dependency would be a parameter, some environment value?
<_ion> Well, you could do as Ubuntu does: keep the old compatibility layer there and gradually rewrite things from the old system to upstart.
<AStorm> I'm just thinking about that.
<AStorm> Just moving the most basic layer to upstart now
<AStorm> and write the compat script
<AStorm> Keybuk, so, is that possible? To base "dependencies" (events I want get started on) on the environment variable or a parameter?
<mbiebl> AStorm: What about documenting your work on the wiki?
<mbiebl> http://upstart.ubuntu.com/wiki/UpstartOnGentoo
<AStorm> I'll do that :-)
<AStorm> When I have something working, I'll do an ebuild and document it.
<mbiebl> Great, seems as many gentooers are already playing with upstart and there is much duplicated effort.
<AStorm> Not a lot, though.
<AStorm> Upstart is so nice, the amount of "work" required is low.
<AStorm> (except that possible conversion script - that requires a tiny bit of bash-fu)
<Keybuk> AStorm: I'm not sure I understand what you mean?
<AStorm> Keybuk, like that:
<AStorm> There is an event send, let's call it run-me
<AStorm> It is emitted with an unknown number of parameters: abc def ghi
<AStorm> And I want to have them converted to: on abc and on def and on ghi
<AStorm> Maybe a tiny extension of the syntax - explicit and?
<AStorm> and support for environment vars in calculation of the events/
<Keybuk> so you have
<AStorm> E.g. I could do: initctl run-it DEPS="abc def ghi"
<Keybuk>   "run-me abc def ghi"
<AStorm> and do: on $DEPS
<Keybuk> ?
<AStorm> I don't have that yet :-)
<Keybuk> I'm still trying to understand what you're trying to do, I'm afraid
<AStorm> s/initctl/initctl emit/
* Keybuk has never seen the Gentoo init system
<AlexExtreme> it's *very* complicated :)
<AStorm> Keybuk, it's a simple "need" based system
<AStorm> AlexExtreme, not really
<AStorm> With some "after and before"
<Keybuk> so when a job starts, it causes the jobs it needs to also be started?
<AlexExtreme> it seemed that way to me :P
<AStorm> Keybuk, exactly.
<Keybuk> or is it the kind where a job is not started until everything it needs has been started by something else?
<AStorm> Like that old "depend" trick
<AStorm> Which was obsoleted some time ago
<AStorm> Keybuk, the second one rather
<Keybuk> in upstart, if "FOO" needs "BAR" then in FOO's job file, you would write:
<Keybuk>     start on started FOO
<Keybuk>     stop on stopping FOO
<AStorm> Exactly.
<Keybuk> err
<Keybuk> s/FOO/BAR/ in that :p
<AStorm> And I'd add in the main one: start on gentoo
<AStorm> and stop on gentoo
<AStorm> that one would emit proper events to run things
<Keybuk> in the main one?
<AStorm> Something like that, right.
<Keybuk> main what?
<AStorm> A conversion of Gentoo init to rcS, so it seems.
<AStorm> It's just that the script "gentoo" would call the wrapper for gentoo-style init multiple times
<Keybuk> maybe I need to rewind here
<Keybuk> are you wanting to know how to rewrite current init scripts into upstart native jobs ...
<AStorm> and this wrapper would get the deps right (precalculated by script)
<Keybuk> ... or are you trying to find out how to write a generic job that can start any gentoo init script ?
<AStorm> Keybuk, the last one
<Keybuk> aha!
<Keybuk> right, basis of my confusion here then :p;
<AStorm> This would simulate gentoo runlevels.
<AStorm> and the smaller script would just launch things
<Keybuk> well, at the most basic level, you need a job that handles the simple case of starting, running and stopping one job
<AStorm> Exactly, but with parametrised deps
<Keybuk> ideally, that would need to spawn the job in the pre-start script, and then kill it again in the post-start script
<AStorm> But then, I'd need a wildcard
<Keybuk> and somehow wedge in the running state while the job is actually running
<AStorm> Yes.
<Keybuk> first you need to write the job, without any deps
<Keybuk> you could do it all in "script" in fact
<Keybuk> script
<Keybuk>    /etc/init.d/$JOB start
<AStorm> Exactly
<AStorm> That's what I want...
<Keybuk>    while [ -f /var/run/$JOB.pid ] ; do sleep 1; done
<AStorm> but for deps I'd need to match on the JOB variable
<Keybuk>    /etc/init.d/$JOB stop
<Keybuk> end script
<AStorm> No pidfile support
<Keybuk> though that's not quite right, since stopping the upstart job would not stop the gentoo one
<Keybuk> what I might do there is
<AStorm> Gentoo is using the pids itself in the scripts
<Keybuk> post-start script
<Keybuk>     /etc/init.d/$JOB start
<Keybuk> end script
<Keybuk> script
<AStorm> Just call /etc/init.d/$JOB stop
<AStorm> Yes, that's it.
<Keybuk>     while /etc/init.d/$JOB is-running; do sleep 1; done
<Keybuk> end script
<Keybuk> pre-stop script
<Keybuk>     /etc/init.d/$JOB stop
<Keybuk> end script
<AStorm> "is-running" is impossible yet. Just sleep instead :P
<Keybuk> right, but how do you know if someone stops the job when you weren't looking? :p
<Keybuk> if you don't care, then omit the "script ... end script" bit
<AStorm> Well...
<Keybuk> (and replace with exec sleep inf until I fix this bug)
<AStorm> Exactly, don't care.
<Keybuk> ok
<AStorm> Stupidity is not rewarded :P
<Keybuk> so this gives you a job that will start and stop any gentoo job when it, itself, is started and stopped
<AStorm> And init scripts are disallowed to call stop on others explicitly
<AStorm> (Gentoo policy)
<Keybuk> of course, you need to mark this "instance" because you want multiple copies running
<AStorm> Yes.
<AStorm> But I need a match on $JOB
<Keybuk> now, you'll want an event to start up an instance for a given job
<Keybuk> and another event to stop an instance for the same job
<Keybuk> easiest way to define that
<AStorm> to start its deps earlier
<Keybuk> initctl emit gentoo-start -eGENTOO_JOB=NAMEOFJOB
<Keybuk> initctl emit gentoo-stop -eGENTOO_JOB=NAMEOFJOB
<AStorm> Yes.
<Keybuk> so stick in the gentoo job file
<Keybuk> start on gentoo-start
<Keybuk> stop on gentoo-stop
<AStorm> But then, the deps are to be given as the parameters still
<AStorm> (because of the need system)
<Keybuk> and use $GENTOO_JOB throughout
<AStorm> or the single script won't work
<Keybuk> (getting to dependencies)
<AStorm> Can I do a match like:
<AStorm> on gentoo-start GENTOO_JOB=xyz *
<Keybuk> no
<AStorm> or would the DEPS variable be ignored?
<AStorm> (if I don't match on it)
<Keybuk> question
<Keybuk> how would you like deps to be handled?
<Keybuk> if you start FOO, should it cause its deps to be started?
<AStorm> Yes.
<Keybuk> right
<AStorm> and then foo itself.
<Keybuk> so now we improve the "gentoo-start" event
<AStorm> Yep.
<Keybuk> initctl emit gentoo-stop -eGENTOO_JOB=NAMEOFJOB -eGENTOO_DEPS="dep1 dep2 dep3 dep4"
<Keybuk> uh
<Keybuk> s/-stop/-start/ :p
<AStorm> Not a problem.
<Keybuk> now that instance, when it gets started, has $GENTOO_JOB which is the job we actually want to run
<Keybuk> (used in post-start and pre-stop)
<AStorm> I'd love to avoid parsing the GENTOO_DEPS though. there's no way yet, right?
<AStorm> (like just putting on started $GENTOO_DEPS)
<AStorm> Or rather:
<AStorm> when $GENTOO_DEPS
<Keybuk> and that instance also has $GENTOO_DEPS
<Keybuk> so the simplest way is to add
<Keybuk> pre-start script
<AStorm> which would expand to when dep1 and when dep2 and when dep3
<Keybuk>    for DEP in $GENTOO_DEPS; initctl emit gentoo-start $DEP; done
<Keybuk> end script
<Keybuk> that wouldn't do what you want
<Keybuk> that would emulate the second kind of system
<AStorm> It would do it too :-)
<AStorm> Ah, right.
<AStorm> the need would add when
<AStorm> the use would add on
<AStorm> :-)
<AStorm> that's the catch
<AStorm> Or even better.
<AStorm> use would still add when
<AStorm> after would add on
<Keybuk> err?
<AStorm> before would work like after, but backwards
<AStorm> Gentoo has 4 kinds of deps:
<Keybuk> nope, completely lost me
<AStorm> need, use, before and after
<AStorm> need means a hard dependency
<Keybuk> need implies that if you try and start $JOB, then its dependencies come up first
<AStorm> so we should get restarted when the dependency is
<Keybuk> ?
<AStorm> Yes
<AStorm> But also when you restart that dependency, the package itself is restarted too. Like when
<AStorm> use is like when, but optional - that's only a problem for dependency precalculator, to see if the thing is added to the runlevel and add the dep then
<Keybuk> ok
<AStorm> after and before are for ordering, doable using on.
<Keybuk> random thought; I wouldn't pass $UPSTART_DEPS as part of the evnet
<Keybuk> s/UPSTART/GENTOO/
<Keybuk> in the pre-start script, I'd parse the gentoo init script to get them
<AStorm> Hmm...
<Keybuk> that way you don't need to duplicate code everywhere
<AStorm> And add the aliases there too?
<Keybuk> right
<AStorm> Would be very fat.
<AStorm> Bad idea.
<AStorm> I can precalculate them.
<Keybuk> yeah, but you have a single job then which handles the entire case of starting and stopping a gentoo init script
<Keybuk> and just needs the name
<Keybuk> rather than trying to duplicate the code everywhere
<AStorm> Yes.
<Keybuk> you'd need the "extract list of deps" code in several places, otherwise
<AStorm> But parsing is slow.
<AStorm> I want to avoid this slowness by parsing once.
<AStorm> Just once - in adding the deps :-)
<AStorm> E.g. in gentoo depscan.sh
<AStorm> The deps would be perfectly calculated using that.
<AStorm> and then just set in the script, like a simple list
<AStorm> WHEN_DEPS="abc def ghi" ON_DEPS="xyz zy"
<Keybuk> right
<Keybuk> but then the job doesn't need to care about its deps, surely?
<Keybuk> if their parsed elsewhere, they can be handled elsewhere as well
<AStorm> Ugh... I'd prefer to have upstart order them
<AStorm> parallelise them
<AStorm> and not do that myself :-)
<Keybuk> right
<Keybuk> but then you end up with the situation where the job doesn't just need to know *its* deps
<Keybuk> it needs the list of deps for every one if its deps
<AStorm> Yep
<Keybuk> and their deps
<AStorm> I could generate multiple job files, well
<AStorm> with the deps pregenerated
<AStorm> but the only catch is that I'd have to regenerate some if a "use" dependency changed. Not that bad.
<AStorm> More clutter and puts the init code generator in the depscan.sh
<Keybuk> I can see quite easily how to convert a Gentoo init script into an Upstart job
<AStorm> Yes, it's damn simple most of the time
<_ion> What do you need the gentoo-start job for? Wouldn't it be enough just to start the existing rc script?
<Keybuk> but how to make a generic job that emulates the behaviour, without that job parsing the Gentoo init script, not sure
<AStorm> Just the script
<AStorm> _ion, for the deps
<AStorm> gentoo init script uses #!/sbin/runscript.sh
<Keybuk> the existing rc script handles all the deps :p
<_ion> I mean, the existing thing already handles the dependencies.
<Keybuk> it's not mad to try and replace it though
<AStorm> Yes.
<AStorm> But it's evil.
<Keybuk> e.g. we could have a sysv layer that iterated /etc/rc.d itself, etc.
<AStorm> It's damned slow
<AStorm> Keybuk, indeed. But then, I just need to mutate rc-update :P
<AStorm> And add some additional event parsing, like for reload and others.
<AStorm> So I'll just add a converter.
<AStorm> Hope it turns out well... would have to detect start-stop-daemon pidfile handling, not that bad.
<Keybuk> sounds like a fun project <g>
<AStorm> (of course, it wouldn't detect some broken scripts :P )
<_ion> Wouldn't that be a motivator for people to migrate their scripts to upstart jobs? :-) Then one nice day you notice that nobody uses the compatibility layer anymore.
<AStorm> _ion, yep :-)
<_ion> The slowness, that is.
<AStorm> The broken scripts more so
<AStorm> like mysql one, it does a lot of weird things
<AStorm> Like checking the config on running, which should rather be done by hand
<AStorm> _ion, I already have a crappy compat layer :P
<AStorm> Want it to become a bit better, so that I can sell upstart performance
<AStorm> (even on Gentoo init scripts converted to upstart scripts)
<AStorm> along with daemon autorestarting for some cases (where I can easily detect that a daemon is launched)
<Keybuk> http://people.ubuntu.com/~scott/cant-stop-execless-job.patch
<Keybuk> ^ that fixes the bug that means you need "exec sleep inf"
<AStorm> Keybuk, thanks :-)
<AStorm> Applying now :-)
<AStorm> The only minus is that I have to muck with that stupid configure script
<AStorm> that tries to install docs into PREFIX, and some other things too
<AStorm> instead of using EPREFIX
<AStorm> Blah, the other way around
<AStorm> Ugh, my badness, checked what I passed in the logs :P
<Keybuk> it does?
<AStorm> No, it doesn't. A brain fart.
<Keybuk> :p
<AStorm> Hmm, the ChangeLog conflicted :P
<AStorm> (expected - the patch is probably against bzr)
<Keybuk> yes
<AStorm> Ok, now on to more hacking - writing that basic layer
<Keybuk> hmm
<Keybuk> initctl stop doesn't hang for me here
<AStorm> and then to some converter
<AStorm> Keybuk, it shouldn't
<AStorm> I just supposed it would. I mean the job should be set as waiting
<AStorm> but then stopped only on explicit stop
<AStorm> Or even maybe... just hold in the running state.
<AStorm> Even better.
<Keybuk> you can do that
<AStorm> Will it be running?
<AStorm> (until stopped, that is)
<Keybuk> you've got the source in front of you?
<Keybuk> look at doc/states.png
<Keybuk> that's the state transition diagram
<Keybuk> notice that pre-stop blister at the top right
<Keybuk> pre-stop is special
<Keybuk> when you run "stop JOB" or when an event that the job has in "stop on EVENT" is emitted ...
<AStorm> Ok, nice :-)
<Keybuk> ... the job goes into pre-stop instead of stopping
<AStorm> Good.
<Keybuk> the pre-stop script can therefore decide to delay the stop
<AStorm> That's what I expected.
<Keybuk> or even revert it altogether
<AStorm> (it won't delay)
<Keybuk> in "pre-stop script", if the job cannot be stopped, just run "start" :)
<AStorm> The task is set to stopped after post-stop, right?
<Keybuk> there's no "stopped" state
<Keybuk> if you mean when does the stopped event get emitted, that is after post-stop, yes
<AStorm> Yes.
<AStorm> Good.
<AStorm> the pre-start is ran when?
<AStorm> just before the start itself, right?
<AStorm> with the starting event emitted, or no? (vetoable?)
<AStorm> and the started is after post-start?
<AStorm> I'm reading the graph right?
<Keybuk> starting is emitted
<Keybuk> then pre-start is run
<Keybuk> then the "exec"/"script" process (if any) is spawned
<Keybuk> then post-start is run
<Keybuk> then started is emitted
<Keybuk> -- 
<Keybuk> pre-stop is run
<Keybuk> then stopping is emitted
<Keybuk> then the "exec"/"script" process (if any) is killed
<Keybuk> then post-stop is run
<Keybuk> then stopped is emitted
<AStorm> What about when pre-start vetoes?
<Keybuk> -- 
<AStorm> Is the stopping emitted?
<Keybuk> if pre-start runs "stop", then you get stopping and stopped emitted
<AStorm> Hmm...
<Keybuk> (red line out of pre-start)
<AStorm> Bad for my health :P
<AStorm> I'd just like to veto a start
<AStorm> Go back to waiting then deleted maybe...
<AStorm> Some way.
<AStorm> So that whichever got started due to starting event, is there
<Keybuk> tbh, I can't remember why starting/pre-start are that way round, but pre-stop/stopping are the other way around
<AStorm> (even if it's listening on stopped)
<Keybuk> you can do that in an odd way
<AStorm> Ah right.
<AStorm> a fail event
<Keybuk> if you have something that does "start on starting"
<AStorm> This won't call the stopping, right?
<Keybuk> then it can look at $1, and call "stop $1" :)
<AStorm> Hmm.
<Keybuk> (the theory is that pre-start's "opposite job" is post-stop)
<AStorm> Because those Gentoo scripts are pesky and I want to emulate the whole behaviour
<Keybuk> so if you run pre-start, you always need to run post-stop
<Keybuk> and because post-stop is run, you'd get a stopped event
<Keybuk> so you need some kind of starting event first
<AStorm> the brokenness is that the deps aren't stopped when the task fails to start
<AStorm> (e.g. due to checkconfig)
<Keybuk> and since you have a starting event, you also need a stopping event, since some things might run between those two things
<AStorm> And I'd have to do that in the script itself then :P
<Keybuk> that's possible in upstart
<AStorm> And can't dep on started :/
<Keybuk> gentoo-start/failed
<AStorm> Hmm.
<AStorm> I know.
<Keybuk> that event will be emitted if the job it tried to start failed to start
<AStorm> They'd have to depend on both the usual and the failed :P
<AStorm> Brokenness emulated bug for bug.
<AStorm> The slash is required, or can I write on started gentoo-start failed?
<AStorm> or even * there?
<Keybuk> slash is required
<Keybuk> since it's a different event
<AStorm> Ah, ok.
<AStorm> Not a problem.
<Keybuk> you could also do something like; exit 1 from pre-start to fail the job
<Keybuk> then you get a "gentoo-job stopping failed pre-start" event :p
<AStorm> But that wouldn't launch the deps.
<AStorm> I want to emulate bug for bug :P
<AStorm> I think I'll go with the "multiple files" approach.
<AStorm> code duplication all right, but will look more like handwritten code
<AStorm> the runscript would still have to be modified anyway, to disable its own dep resolution
<Keybuk> right
<Keybuk> dinner
<Keybuk> bbl
<Keybuk> enjoy
<AStorm> Or is there a way to bypass #! line?
<Keybuk> sure sh -escript
<AStorm> Great.
<AStorm> Hmm, even the "when" would be too far
<AStorm> Just on
<AStorm> stop on stopping ourdep
<AStorm> Because that's broken in Gentoo init scripts too :P
<AStorm> Blah, even better
<AStorm> I just need to source the given init script
<AStorm> then call its "start" function
<AStorm> the more problematic would be reload which some scripts have
<AStorm> Which doesn't necessarily just restart the app.
<AStorm> Though that could be just an another handler, e.g. on some parameter
<AStorm> So you could do: initctl emit xyzzy reload
<AStorm> or initctl emit xyzzy stop
<AStorm> Or better, initctl stop xyzzy
<AStorm> Simple then.
<AStorm> Just read OPTS variable.
<AStorm> (gets sourced in)
<AStorm> the reload is the default one
<AStorm> If not present, it's just start/stop, will have to emulate that somehow.
<AStorm> Probably by defining our own bash function, then sourcing. This will override our own definition.
<AStorm> Wouldn't it be nice to have the reload event separated from restarting, generally?
<AStorm> E.g. special events "reloading xyzzy" "reloaded xyzzy"
<AStorm> But then... the reload xyz would just emit these simply and call pre-reload
<AStorm> reload
<AStorm> and post-reload
<AStorm> Actually, just launch a reload event with reloading and reloaded. No need for special syntax :>
<_ion> That could be useful. Let's ask Keybuk's thoughts about it when he returns.
<AStorm> Of course, the states would only be emitted if the event had reload in it.
<AStorm> and add the initctl function reload
<AStorm> it'd fail if the event wouldn't support it
<AStorm> s/wouldn't/didn't/
<AStorm> could just fall back to stop/start
<AStorm> or just start if not running
<AStorm> Temporarily, I'll just create more events
<AStorm> Actually, I'll use a parameter.
<AStorm> These become just $1, $2 etc?
<AStorm> I'm wondering... how to avoid checking filesystems from the same drive in parallel
<AStorm> Hmm.
<AStorm> Maybe just something simple... I'd do away with the fstab anyway - it'd be parsed.
<AStorm> Well, the simplest would be to just sort based on the drive ID, using standard Unix device names... but that'd break with LVM and some Udev manglings
<AStorm> LVM can be worked around by parsing lvs
<AStorm> But don't know about udev...
<_ion> The Ubuntu people might have a solution for that problem. They've surely had to think about it, as they're going to implement that for the next release.
<_ion> Better ask Keybuk.
<AStorm> Hmm... or maybe not :P
<AStorm> Maybe they just punted at the problem - the scanning will just get slower
<AlexExtreme> Keybuk said he would release an upstart-based init sequence for ubuntu today or tomorrow, we should wait to see what's been done there
<AStorm> Great, just great. I shall see.
<AStorm> Uh, yes, md would be problematic too (no, not you)
<AlexExtreme> :P
<AStorm> RAID and stuff - you don't know which is on which physical disc.
<AStorm> Would need physical FS data.
<AStorm> Hmm... there is an option...
<AStorm> parsing /proc/diskstats
<AStorm> Just do a simple read on each of the partitions
<AStorm> and see which disk's stats got upped
<AStorm> But that'd have to be done in single mode.
<AStorm> If one could get a hardware Udev id...
<AStorm> But then, that doesn't tell us anything about LVM or RAID. Though these can be worked around.
<arachnist> wasn't upstart supposed to be crossplatform? i'm quite sure that /proc/diskstats is nonexistant on bsd's, even with linprocfs mounted on /proc
<AlexExtreme> well
<AlexExtreme> this would be in the job files
<AlexExtreme> which are distro specific
<AStorm> :>
<arachnist> oh, ok
<AStorm> Ok.
<AStorm> udevinfo returns the hardware ID.
<AStorm> One problem less. Now I'll check the LVM.
<AStorm> Hmm, udevinfo is useless against LVM or RAID.
<AStorm> But these fortunately have their own tools. RAID has mdstatus
<AStorm> LVM has lvs
<AStorm> The parsing would be done by a special util, so as not to slow down the startup. Will write such a script now.
<AStorm> lvs+pvs for LVM (converting to physical device), udevinfo for physical volumes
<AStorm> Don't remember md, so it'll have to wait.
<Md> I think you are looking for /lib/udev/vol_id
<_ion> Ubuntu added /lib/udev/watershed to the udev packaging recently, it should be helpful when multiple fscks are supposed to be run.
<_ion> (i think)
<AStorm> Md, that's one thing.
<AStorm> No, udevinfo will be enough.
<AStorm> vol_id requires the device path, so it's useless.
<AlexExtreme> _ion, what does that do?
<AStorm> Knowing the device path means I know everything.
<AStorm> For knowing the LVM volumes, one just needs to run vgscan - and that's needed anyway
<AStorm> vgscan, then parse lvs and pvs info
<AStorm> then we get the device name.
<AStorm> Which can be probed using udevinfo --name=device --query=env
<AStorm> to get the unique hardware id
<_ion> alexextreme: If you run /lib/udev/watershed sleep 2 twice, the other one won't be started until the first one has finished.
<AlexExtreme> ah
<AStorm> Even better :>
<AStorm> One can just do some ls on sysfs
<AStorm> to get where the device mappings are stored
<AStorm> I'll see the libsysfs
<AStorm> Yes, there is a tool in sysfsutils
<AStorm> systool
<AStorm> But why depend on an external tool, when few ls or finds will suffice?
<AStorm> *a few
<AStorm> The basic partitions are just subdirs of the drive subdirectory
<AStorm> the device mappings are on their own, but they have the parition(s) they're contained in symlinked in slaves subdir
<AStorm> Also, the partitions/discs have the symlink to the mappings in holders
<AStorm> subdirectory
<AStorm> Simple enough to write a script to detect that in realtime.
<AStorm> Only swap partitions will have to be ignored...
<AStorm> (/proc/swaps)
<AStorm> Bah, can't use /proc/swaps.
<AStorm> The entry won't be there yet, the swap isn't enabled.
<_ion> Yay, i booted my computer using upstart 0.3.5 + my watch_delayed patch. It works.
<AStorm> The simplest would be to create fsck.swap, which does nothing.
<AStorm> How does one detect that a partition is swap in Linux? :>
<AStorm> w/o trying to mount it
<AStorm> Ah, right.
<AStorm> mount -f -v
<AStorm> Blah, that does print unknown only
<AStorm> Any ideas?
<phsdv> you do not want to look in /etc/fstab? I mean there could be swap partitions that I do not want to use
<AlexExtreme> hmm
<AlexExtreme> just installed herd 2 in vmware from an iso i downloaded a while back
<AlexExtreme> "only" 409 updates :p
<AlexExtreme> night
<phsdv> night
<AStorm> Blah, it's just a syscall, that swapon.
<AStorm> Heh, the first page of swap contains a magic ID
<AStorm> SWAP SPACE for old swap
<AStorm> SWAPSPACE2 for newer one
<AStorm> SWAP-SPACE for old
<AStorm> old is unsupported in 2.6 AFAIK anyway, so we don't have to bother.
<AStorm> The only thing I have to know is current page size.
<AStorm> Now, the idea is - can I get the pagesize w/o launching any C code? :P
<AStorm> (that and some head+tail would be enough for basic detection)
<AStorm> In case of problems, I'll just punt and check the largest pagesize
<AStorm> Ah, it should be in the libc headers.
<AStorm> Ok, it's in Linux :P
<AStorm> The largest number of bytes is 1 << 22
<AStorm> That's some kind of sparc64
<AStorm> Usually it's 1 << 12 or 4096
<AStorm> 1 << 22 is... 4MB!
<AStorm> Now that's some page :>
<AStorm> I'd like to avoid grepping 4 MB of the swapfile, but oh well :P
<AStorm> head -n 4m | grep -U SWAPSPACE2 is ok... but..
<AStorm> I think that trying to swapon would be faster than that...
<AStorm> though the simple check would be faster if I could somehow get the page size
<AStorm> or write a tiny C prog "isswap"
<_ion> Keybuk's dinner has taken a while. :-)
<AStorm> Right.
<AStorm> And I've finished that swap detector
<AStorm> as a bonus, it detects old v1 swap space as non-swap
<AStorm> so will bork :-)
<AStorm> A special return code of 2
<AStorm> 1 if not swap space
<AStorm> 0 if swap space v2
<AStorm> 254 for file open error
<AStorm> 255 for argument error
<AStorm> No usage (quite obvious - give it a device name)
<AStorm> Uses mmap for extra speed :P
<_ion> In case anyone's interested, this is the upstart patch i've been using for a while, it seems to do the right thing. http://soijabanaani.net/tmp/upstart_watch_delayed.diff
<_ion> It compiles with the libnih from https://code.launchpad.net/~ion/+branch/libnih/watch-delayed
#upstart 2008-02-04
<darius12> does process handover work with current upstart bzr? (from an initramfs upstart to the "real" upstart)
<Keybuk> no
<darius12> what is missing? the ipc protocol between the two instances of upstart?
<Keybuk> right
<darius12> is it just that, or there needs to be any refactoring before this protocol is added?
<Keybuk> the complete lack of any IPC is a major todo item right now
<Keybuk> the necessary conf changes have already happened
<darius12> I see.
<Keybuk> a related, but not critical path, item is the atomicity of start & stop
<darius12> they are not yet atomic?
<darius12> I 'm setting a qemu image to play with boot-time facilities (upstart and grub2)
<Keybuk> no
<Keybuk> in the sense that:
<Keybuk>  start JOB with environment FOO=x BAR=y
<Keybuk> this should start the job, storing those environment variables in it, and those environment variables should persist throughout the life of the job, including its stop scripts
<Keybuk> if I now do
<Keybuk>  stop JOB
<Keybuk>  start JOB with environment FOO=y BAR=x
<Keybuk> (immediately after each other - ie. restart)
<Keybuk> the job should stop with FOO=x and BAR=y and not adjust its environment until it has completely stopped
<darius12> I see, interesting
<Keybuk> actually, it's turned out to be quite a headache
<darius12> is "with environment" really needed?
<darius12> (I guess it has to do with supporting different instances of a service right?)
<Keybuk> right
<Keybuk> and if you don't have environment, you don't know what event started you
<darius12> right
<darius12> and I guess I need service instances
<Keybuk> instance cases are even more fun
<Keybuk> since in theory, the environment attached is similar enough anyway
<Keybuk> start getty TTY=tty1
<Keybuk> stop getty TTY=tty1
<Keybuk> start getty TTY=tty1
<Keybuk> doesn't really make much difference :)
<darius12> and why is it such a problem for the atomicity? (I haven't looked at the source yet)
<darius12> you are storing an event together with its environment, not?
<darius12> I meant a job instance together with its environment
<Keybuk> right
<Keybuk> you'd need to store its current environment
<Keybuk> and its next environment
<Keybuk> or...
<Keybuk> spawn a new instance, and don't let it start until the other stops
<darius12> right, I see
<Keybuk> I'm not sure which is the right solution
#upstart 2008-02-05
<reppel> Hi, is there a way to run a job with a given user != root?
<reppel> I mean, without su user -c command
<reppel> I see there is no user stanza in 0.3.9
<darius12_> Is Bean's git repository public? The patch doesn't apply well here and I see diff --git
<darius12_> so maybe I can just pull in his changes via git
<ion_> Huh?
<darius12_> oops, wrong channel :-)
#upstart 2008-02-06
<darius12_> can you guys build upstart bzr?
<darius12_> it seems autoreconf may be broken here
<darius12_> autoreconf -i wants to call "aclocal --install" and aclocal does not have this option
<darius12_> I upgraded autoconf to the latest release from debian sid but the problem remains :-(
<darius12_> ok, this was a debian/personal config issue (automake/aclocal weren't the latest installed versions by default)
<darius12_> what do you use to test upstart? qemu?
#upstart 2008-02-07
<darius12_> hi, upstart's testsuite hangs in nih_child_poll() (with signal from traced child)
<darius12_> I left it for ~ 15 minutes before I killed it
<ion_> keybuk: Btw, did you notice this?
<ion_> 2008-01-25 17:02:41 < ion_> keybuk: An idea occured to me: how about disallowing nih_ref when the object has a parent (so that it always has a reference count of 1 and nih_unref would be used just like nih_free is now â not callect directly on the object), thus reference counting could *optionally* be used with parentless objects?
<ion_> 2008-01-25 17:03:54 < ion_> Children would be released whenever their parent is released, and the refcounting may be used with the parent when appropriate just by using nih_ref.
<Keybuk> darius12_: kernel version?
<Keybuk> ion_: that wouldn't seem unreasonable
<Keybuk> ion_: would that let you do what you want?
<darius12_> 2.6.18 from debian etch
<ion_> keybuk: Yes
<darius12_> I suspected the kernel as well
<Keybuk> darius12_: you need a newer kernel (assuming you're talking about trunk's test suite)
<darius12_> so I 've been building 2.6.24 to try with this too
<darius12_> ah, thanks :-)
<Keybuk> the test suite manages to find a couple of kernel bugs ;)
<Keybuk> in fact, that particular one it's hanging on, got a CVE assigned to it
<darius12_> yes, I 'm talking about trunk's latest testsuite, I noticed you mentioning about the usefulness of upstart as a kernel bug uncovering tool :-)
<Keybuk> the test suite uses waitid(W_NOWAIT) so it can ensure that there's no race conditions
<Keybuk> ie. if it kills a child, it waits without reaping for the child to die, so then when it calls nih_child_poll() it knows *that* function's call to wait() will work
<Keybuk> it turns out that waitid(W_NOWAIT) isn't used much, so had some issues
<Keybuk> especially when combined with ptrace
<darius12_> I see
<darius12_> I 'm a bit scared about upstart using ptrace
<darius12_> Especially if there is a bit of flux in this area when/if utrace gets merged
<darius12_> I 'm ok with strace breaking for a while but pid #1 is a different story ...
<darius12_> Then again, if upstart manages to get in fedora it will get testing combined with utrace so bugs will probably get fixed before utrace becomes mainstream
<Keybuk> I haven't heard of utrace before
<darius12_> It is roland mcgrath's heroic effort to reimplement ptrace in the kernel
<darius12_> (the kernel-userspace interface of course stays the same)
<darius12_> It is quite nice, e.g., with it you can implement policies such as "on segfault, just freeze the thread and wait for me to attach a debugger instead of dumping core"
<darius12_> very easily in few lines of code
<ion_> Neat
<darius12_> and it gets even neater when you want to implement dtrace-like monitoring etc
<darius12_> It is already in the fedora kernel and it is slowly getting merged upstream
<Keybuk> if the interface is the same, there shouldn't be any problems there?
<darius12_> just increased probability for new bugs :-)
<darius12_> ptrace is pretty hard to get right
<Keybuk> reimplementations always do
<Keybuk> happily we have a test suite ;)
<darius12_> The test suite will give you reassurance that the bug is not yours.
<Keybuk> it also helps us fix the kernel bug too
<Keybuk> since it's a small (10-20 lines of code) test case for the bug
<darius12_> yep, this is also true :-)
<darius12_> maybe upstart's testsuite should be added to test.kernel.org
<Keybuk> :-)
<darius12_> Is there a way to declare in upstart that bash wants to be killed with SIGHUP?
<Keybuk> it does?
<Keybuk> (not yet)
<darius12_> yes, otherwise it doesn't save its history
<darius12_> which is very annoying
<Keybuk> you spawn a login shell with Upstart? :)
<Keybuk> don't you usually spawn getty or login for that?
<darius12_> yes, but how about kde konsole sessions?
<darius12_> bbiaw
<Keybuk> those get killed by other means
<Keybuk> Upstart doesn't send them a signal directly since it doesn't know about them
<Keybuk> they might be in a process group of something that Upstart does know about
<Keybuk> or they might get the signal from something else that is being killed itself
<darius12_> back 
<darius12_> you are right. Login sends sighup to its child login shell when it gets a sigterm
<darius12_> This didn't happen when I was testing it ages ago (it seems it has been fixed since 2003)
<darius12_> So there is no problem
<darius12_> for kde I guess when it doesn't work, konsole is to blame
<darius12_> Keybuk: with kernel 2.6.24 I get 3 testsuite failures:
<darius12_> nih_dir_walk()  nih_main_write_pidfile() and nih_watch_new()
<Keybuk> which failures?
<darius12_> http://pastebin.ca/895177
<Keybuk> err, ok
<Keybuk> how kooky
<Keybuk> things that should fail are not failing
<darius12_> which kernel version are you testing upstart with?
<Keybuk> ubuntu hardy stock
<darius12_> it looks like it is 2.6.24-rc8 based
<darius12_> strange
#upstart 2008-02-08
<darius12> Keybuk: I just looked a bit at the testsuite errors I was getting and it turns out that these were because I ran the tests as root
<darius12> everything passes now (maybe something can be added to the testsuite to disable those tests in this case, or XFAIL them or something)
<darius12> when I run it as a user all tests pass
<Keybuk> oh, right
#upstart 2008-02-09
<solemnwarning> Hi all
<solemnwarning> I'm trying to install Upstart under Debian
<solemnwarning> If I create an event.d entry for each rcS.d link, how can I make an event that waits for ALL the rcS events to finish starting?
#upstart 2008-02-10
<mkelly32> hi, is there a patch available to add functional support for the pid stanza to 0.3.9?
<mkelly32> or is that something i'll have to wait for until 0.5 comes out?
#upstart 2009-02-02
<sadmac> Keybuk: did you get that new set of async stuff?
<Keybuk> not yet
<Keybuk> still travelling
<sadmac> oh. where are you?
<Keybuk> brussels
<Keybuk> on the way to berlin
<sadmac> brussels. good town. try their sprouts
#upstart 2009-02-03
<iamthelostboy> hello.. im new to upstart and trying to have a bash script run on startup instead of a tty..  for a start though, if i specify a runlevel on my grub line, it seems to be completely ignored..
<sadmac_> iamthelostboy: distro?
<iamthelostboy> debootstrap of ubuntu
<iamthelostboy> minimalist install
<sadmac_> hmm. not my distro then
<iamthelostboy> basically just ubuntu/debian
<sadmac_> I'm the Fedora maintainer :(
<iamthelostboy> oh..
<iamthelostboy> ok.. if i do want it to run a script, rather than a login prompt, I can just change the exec getty line in the rcX file to be the script?  would that be the correct way to do it?
<sadmac_> that would work.
<iamthelostboy> cool.. then if i wanted that script to be able to start a tty, and be returned to when that tty is exited?  I added the same getty into my script, but when i exit from the tty, the system seems to pretty much die
<sadmac> what are you trying to accomplish?
<iamthelostboy> our distribution goes onto machines which people have no idea how to operate linux
<iamthelostboy> and we dont want to let them login anyway to ensure they dont mess with the system
<sadmac> okay...
<iamthelostboy> they have a few maintenance tasks which need to be taken care of occasionally
<iamthelostboy> i have created a menu system using bash and dialog so they can choose the things they want to do
<iamthelostboy> like calibrating the touch screen and installing .deb files or running .sh files from a usb key
<iamthelostboy> another option in the menu would be to actually start a terminal which would require login..
<iamthelostboy> we will set grub up with a default item of starting our application, and an administration mode of a different run level in which this menu runs
<iamthelostboy> the menu itself is actually working, and if i 'init 4' the menu will run
<iamthelostboy> if i put 4 on the grub line, it stays in runlevel 2
<iamthelostboy> if i init 4 into the menu, and go to the 'adminstration mode' which runs getty, it starts the console, and then if i 'exit' it logs out, but then doesnt go anywhere, and if I switch to another terminal, i have no keyboard access.. so i have to reboot
<iamthelostboy> actually, they are dead from the moment i 'init 4', so i assume they wouldnt be there if i actually booted into runlevel 4
<sadmac> that's not an upstart issue most likely
<sadmac> the grub cmdline not working is in the job definitions. not upstart specifically. The rest is general tty-foo
<iamthelostboy> ill keep looking :)
<iamthelostboy> thanks
<iamthelostboy> it appears to be a ubuntu bug which has been in existence since early 2007..
<sadmac> hmm
<iamthelostboy> rc-default is missing some critical stuff to figure out what runlevel was requested.. add a few lines of code and it will do it properly
<sadmac> send the patch to em
<iamthelostboy> i got it from the bug report..
<iamthelostboy> it was posted early 2007 and againlast year..
<iamthelostboy> maybe one day they will put it into the distro
<sadmac> one can only hope
<iamthelostboy> it took me a few minutes to figure out what it was actually doing, and why the default one wasnt working.. my bash knowledge is still pretty limited
<iamthelostboy> thanks for your help :)
<sadmac> np
<keesj> hi
<keesj> sadmac: thanks for the kernel upgrade tip under 2.6.28 I can debug upstart using gdb
<keesj> (under amr)
<sadmac2> keesj: np
 * Keybuk arrives
<sadmac2> Keybuk: what did you bring me?
<Keybuk> snow
<sadmac2> damnit
<sadmac2> we just got rid of the last pile of that stuff
<KDesk> Keybuk: Hi, are you planning to include upstart 0.5 in Jaunty?
<Keybuk> no
<KDesk> Keybuk: ah, then are you going to update upstart for 9.10?
<Keybuk> if 0.10 is ready by then (which is the plan)
<KDesk> Keybuk: ah, ok, thanks for the info!
#upstart 2009-02-04
<keesj> sadmac2: are you aware of https://bugs.launchpad.net/upstart/+bug/324890 (nitctl emit --no-wait should not wait)
<keesj> ion_: are you a xmoto player?
<ion_> keesj: Yes. How so?
<keesj> I used to develop xmoto 
<ion_> Oh, cool.
<ion_> How did you figure i play it? :-)
<keesj>  /who'ed you and followed the link to the website
<keesj> ported xmoto to the maemo platform http://wiki.xmoto.tuxfamily.org/index.php?title=SDL_gfx
<ion_> Ah. My most recent obsession has been the level Little Hole. 3522 plays and still not finished. :-P
<keesj> I can only finish the every easy levels, but it's still fun becasue there are so many new levels every time
<ion_> keesj: Mortonâs Adventure Part 4 is the coolest xmoto level with the new physics so far. Driving over a platform or rolling a stone to the correct hole cause levers to trigger changes that allow you to finish the level. One could take the concept further and create nice puzzles.
<keesj> going to try it later today, thanks for the tip
<sadmac2> keesj: yeah, I know about that one. nih_dbus couldn't do that at the time I wrote initctl.
<sadmac2> Keybuk: the other day you said you brought me snow, and then last night it snowed
<Keybuk> awesome
<sadmac2> Keybuk: oh, and some time tonight I should be able to complete all of the async test cases
<Keybuk> sweet
#upstart 2009-02-06
<CrummyGummy> hi, how can I allow a normal user to run an upstart script?
<ion_> Instruct her to use sudo.
<CrummyGummy> her is a scripts user that needs to start/restart scripts from a cron job.
<ion_> Again, sudo.
<CrummyGummy> Ok, I'll give it a stab as soon as I can get these scripts to work.
<ion_> sudoers(5) for instructions for giving a user access to specific commands without password.
<CrummyGummy> thanks, will it be possible to wrap the upstart script in an LSB compliant init script. Heartbeat needs it...
<ion_> Might as well not convert the script to an Upstart job in the first place as long as Heartbeat doesnât support Upstart.
<CrummyGummy> ion_: the only reason for the move is that I like the respawn capability of upstart. I was running everything on daemontools but it just died on upgrading to intrepid. No idea why.
<keesj> what is the right way to regenerate the dbus glue code?
<keesj> It goes by magic if the configure OBJDIR is not explicetly set
<keesj> I implemented a solution for --no-wait for initctl and would like to discuss it
<Keybuk> sure
<keesj> What I did was to add an aditional parameter the the EmitEvent dbus interface (currently called sync). Now in  in init/control.c  in the control_emit_event method I check that paramter and if "not sync" the message is not blocked unlit the evernt is consumed but I directly call control_emit_event_reply
<keesj> I am no sure this aproach will work for start/stop but what do you think?
<keesj> http://paste-it.net/public/o633c62/
<Keybuk> rather than calling with --no-reply ?
<Keybuk> (which I guess inhibits error returns such as "No such job")
<keesj> yes rather then solving it on dbus level
<keesj> Keybuk: your talk at fosdem is concurent with Maemo on the BeagleBoard. it's a difficult choice
<ion_> Thatâs what fork() is for.
<keesj> Indeed I can bring my kids of course
<ion_> Children are more akin to cat "$0" /usr/bin/something-else | shuf >kid; chmod 0755 kid; ./kid &
<suihkulokki> keesj: It seems people are expecting too much from kaltsi's maemo/beagleboard talk :)
<Keybuk> worst still, I'm in the large room
<Keybuk> I hate talking in large rooms
<Keybuk> much prefer smaller ones, which always feel well attended
<keesj> suihkulokki: perhaps, I do like the kind the things she does
<ion_> Iâd pick Keybukâs talk because Nokia sucks. :-P Nokia got tired of pesky investigations against them for snooping employeesâ email, so they threatened to leave Finland if Lex Nokia isnât passed. The law is against the constitution; it allows certain entities (such as companies, schools, apartment buildings, libraries) that provide an Internet connection to snoop much of the net usage. Unanimous expert statements against the law were ignored by the ...
<ion_> ... lawmakers, and itâs almost certain the law will get passed soon.
<suihkulokki> the horror, the shock, they want to pass a law allowing grepping mail logs
<suihkulokki> (now please ignore while we are setting up at the same time a national fingerprint registry with full access for the policy)
<suihkulokki> http://www.theregister.co.uk/2009/02/03/finland_fingerprints/ <- ie this one is much scarier shit
<Keybuk> is anyone successfully using 0.5 ?
<Keybuk> ah, no, doofus problem on my end
<Keybuk> things break if /dev is empty for a while ;)
<sadmac_> Keybuk: I've had some thoughts on transactions and how to use them to do certain things
#upstart 2009-02-07
<mbiebl_> Keybuk: I'm using 0.5.1, fwiw
<mbiebl_> still with the sysv compat scripts though
#upstart 2009-02-08
<Keybuk> "slip into the comfort of your own narcolepsy"
 * Keybuk has to use that lyric as a release name one day
<sadmac> I've just been watching music videos with good release names
<sadmac> "same as it ever was"
<Keybuk> "this is the new shit" ?
<sadmac> that'd be a good 1.0 release name
<Keybuk> true
 * keesj wanted to shake hands today a fosdem but did not have the patience to wait
<sadmac> Keybuk: I've been thinking about transactions a bit lately.
<Keybuk> oh yes?
<Keybuk> keesj: I didn't know you were there! :-(
<sadmac> Keybuk: I'll cover the bad news first: we can't preserve the transactional property of the system :)  Consider:
<sadmac> open transaction
<sadmac> stop A
<sadmac> start B
<sadmac> commit
<sadmac> We go to apply, we stop A. B won't start
<sadmac> We try to revert. A won't start
<sadmac> we're stuck in an inconsistent state. We can't revert or complete.
<Keybuk> right, I figured that :-/
<sadmac> Keybuk: but transactions also give us an opportunity to assign certain contexts to actions. Consider opening a transaction with the "shutdown" option. When its applied, anything we kill, we just ignore rather than killing and let it run. Then at the end of the transaction we fire off the halt.
<sadmac> if we abort we just reclaim ownership of the lost processes.
<Keybuk> how do you mean?
<sadmac> well, really we'd never release them in the first place. The point is because of the context we know we don't have to actually stop the services. They'll die at the poweroff (or on a mass-kill somewhere near the end of the transaction)
<Keybuk> ah, I had a feeling that's what you meant
<Keybuk> treat the shutdown context specially and not really kill services
<sadmac> exactly
<sadmac> transaction properties are a good way to trigger things like halt or reboot too. just a flag that says "when you commit this transaction, reboot"
<Keybuk> the trouble is you get a limited set of "when you..." to it
<sadmac> what's the issue?
<Keybuk> well, you could only implement a limited set of FOO for "when you commit this transaction, FOO"
<Keybuk> otherwise its behaviour is identical to an event - you emit it, wait for it to finish, then do something if successful
<sadmac> there's only a couple of things we'd want. reboot, halt, stuff like that.
<sadmac> (katzj probably wants "eject cd tray" in there. I've been refusing his patch for awhile now)
<Keybuk> eject cd tray?
<sadmac> Keybuk: Jeremy Katz wants pid 1 to be able to eject the cd drive.
<sadmac> I'm not quite as eager for that feature.
<Keybuk> for?
<Keybuk> on shutdown?
<sadmac> yes, shutdown after a livecd
<Keybuk> we just readahead the reboot binary ;)
<sadmac> yeah, he really didn't like that
<sadmac> *shrug*
<Keybuk> :)
<Keybuk> I actually do intend for init to make the reboot() system call
<Keybuk> which solves the underlying problem, provided eject is the last thing you do
<sadmac> I think it makes more sense in newer upstart.
<sadmac> he's got a patch to make 0.3.9 do the eject thing though.
<sadmac> I've been ignoring it in bugzilla for months.
<Keybuk> but then it makes sense to do suspend/hibernate in init too ;)
<Keybuk> and richard hughes won't like that
<Keybuk> davidkit's ok with the idea
<sadmac> who was it that was doing the dbus in kernelspace stuff?
<sadmac> I can't google it for shit.
<Keybuk> Marcel
<sadmac> how far along is that now?
<Keybuk> Holtmann
<Keybuk> it's from Marcel
<Keybuk> how's Hell doing in the Freezing Over stakes?
<sadmac> he not carrying it along or upstream not happy about it?
<sadmac> or fd.o screwing things up?
<Keybuk> no...
<Keybuk> Marcel invents a lot of things
<Keybuk> Marcel implements substantially fewer things
 * sadmac is game
<Keybuk> it makes sense
<sadmac> has he written anything?
<sadmac> ah. exeunt Keybuk.
#upstart 2010-02-09
<johnflux> Hey all
<JohnFlux> Upstart added various functions to get the properties of jobs
<JohnFlux> various dbus functions, I mean
<JohnFlux> but they don't seem to actually work :-)  I just get permission denied
<JohnFlux> As a random example:
<JohnFlux> qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart/jobs/networking author
<JohnFlux> Error: org.freedesktop.DBus.Error.AccessDenied
<JohnFlux> Rejected send message, 2 matched rules; type="method_call", sender=":1.72" (uid=1000 pid=6687 comm="qdbus) interface="(unset)" member="author" error name="(unset)" requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init"))
<JohnFlux> same even running as root
<filip> hi, I am trying to create an upstart based system, and I have a little problem here:
<filip> http://pastebin.com/m1a164ddb how is this consistent?
<mbiebl> JohnFlux: how does your /etc/dbus-1/system.d/Upstart.conf look like?
<JohnFlux> mbiebl, http://pastebin.com/m2f97827d
<mbiebl> JohnFlux: if you want to give a certain user full access, you can copy the user=root section
<JohnFlux> mbiebl, but it doesn't work even if I do  sudo qdbus..
<JohnFlux> root@.. # qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart getAllJobs
<JohnFlux> Error: org.freedesktop.DBus.Error.AccessDenied
<mbiebl> works for me
<JohnFlux> mbiebl, :-/
<JohnFlux> mbiebl, could it be anything to do with it saying com.ubuntu.Upstart0_6   in the config file, when I don't see that in qdbus ?
<mbiebl> try this: sudo dbus-send --print-reply --system --dest=com.ubuntu.Upstart /com/ubuntu/Upstart com.ubuntu.Upstart0_6.GetAllJobs
<JohnFlux> mbiebl, that worked
<mbiebl> that should even work as non-root
<JohnFlux> mbiebl, it prints lots of entries
<JohnFlux>       object path "/com/ubuntu/Upstart/jobs/alsa_2dmixer_2dsave"
<JohnFlux> etc
<mbiebl> there you go
<JohnFlux> take: qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart/jobs/networking description
<JohnFlux> mbiebl, how do I do that with dbus-send ?
<mbiebl> JohnFlux: do you want to read a property?
<JohnFlux> mbiebl, right
<Keybuk> JohnFlux: the Upstart0_6 bit is only the interface definition
<Keybuk> all the paths are unversioned
<JohnFlux> Keybuk, I think I'm having two separate problems.  The first is how do I view a property. The second problem is that it ends up with two possibilities for some reason, so fails because of that
<Keybuk> properties are done with the standard D-Bus properties interface
<Keybuk> you send something like
<JohnFlux> qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart GetAllJobsError: org.freedesktop.DBus.Error.AccessDenied
<JohnFlux> Rejected send message, 2 matched rules; type="method_call", sender=":1.104" (uid=0 pid=7182 comm="qdbus) interface="(unset)" member="GetAllJobs" error name="(unset)" requested_reply=0 destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<JohnFlux> (note the "2 matched rules"
<JohnFlux> )
<Keybuk> org.freedesktop.DBus.Properties.Get with the object path and interface
<Keybuk> or it is the property name and interface?
<Keybuk> JohnFlux: what was the command you used for that?
<JohnFlux> qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart GetAllJobs
<Keybuk> you missed out the interface
<Keybuk> qdbus --system com.ubuntu.Upstart /com/ubuntu/Upstart com.ubuntu.Upstart0_6.GetAllJobs
<Keybuk> maybe
<JohnFlux> okay I think that is working:  qdbus: I don't know how to display an argument of type 'ao'
<JohnFlux> which I think means it's working okay
<JohnFlux> but why is there an ambiguity?
<Keybuk> there isn't
<Keybuk> there's just a strict security policy
<Keybuk> you are talking to the init daemon after all ;)
<Keybuk> you can fiddle in /etc/dbus-1/system.d/Upstart.conf and relax it
<Keybuk> if you were root, that would be allowed
<JohnFlux> I am root
<JohnFlux> it's not allowed :P
<Keybuk> may be a qdbus bug then
<Keybuk> sending messages without an interface is generally considered bad form anyway
<Keybuk> the dbus upstream dbus-send thing doesn't even permit it
<JohnFlux> Keybuk, hum, so my app needs to hard code in the upstart version? :-(
<Keybuk> yes
<Keybuk> your app is hardcoding the upstart version anyway
<Keybuk> you're using a pre-release interface that's subject to change
<Keybuk> that's why the 0_6 is there
<JohnFlux> okay that's fair enough
<JohnFlux> any idea when it will be finalised?
<Keybuk> 1.0
<JohnFlux> I'm continually looking at adding upstart support to KDE System Monitor
<Keybuk> shouldn't be hard
<Keybuk> you can get the version property of /com/Ubuntu/Upstart
<Keybuk> and just support multiple versions
<Keybuk> ie.
<Keybuk> for upstart_interface in ("0_6", "0_7", ...):
<Keybuk>     upstart.Get("com.ubuntu.Upstart%s" % upstart_interface, "version", interface="org.freedesktop.DBus.Properties")
<Keybuk> whichever one succeeds is the supported interface for this version of upstart
<JohnFlux> Keybuk, that could work
<Keybuk> http://upstart.ubuntu.com/wiki/DBusInterface
<Keybuk> I almost documented it
<JohnFlux> Keybuk, could you add command line examples? :)
<JohnFlux> Keybuk, It's very complicated to print out the value of a property
<JohnFlux> Keybuk, also, how do I get the PID of a job? :)
<Keybuk> that's a good idea
<JohnFlux> a quick grep of that page shows no "pid" string
<Keybuk> PID of a job -> it's the processes property of an instance
<Keybuk> so something like
<Keybuk> GetJobByName() -> to get the job
<Keybuk> GetInstance() -> to get a running instance
<Keybuk> Get() -> to get the processes array
<Keybuk> wing-commander scott% dbus-send --type=method_call --print-reply --system --dest=com.ubuntu.Upstart /com/ubuntu/Upstart/jobs/dbus/_ org.freedesktop.DBus.Properties.Get string:com.ubuntu.Upstart0_6.Instance string:processes
<Keybuk> method return sender=:1.0 -> dest=:1.151 reply_serial=2
<Keybuk>    variant       array [
<Keybuk>          struct {
<Keybuk>             string "main"
<Keybuk>             int32 1090
<Keybuk>          }
<Keybuk>       ]
<JohnFlux> cool, that works for me too :-)
<JohnFlux> as a normal user
<JohnFlux> so "1090" is the pid, right?
<Keybuk> yes
<Keybuk> right
<Keybuk> I tried fairly hard to make sure that all the "read"y things are usable as ordinary users
<mbiebl> Keybuk: you are planning a 0.7 :-)
<Keybuk> you only need to be root to change
<Keybuk> mbiebl: yes
<mbiebl> would you mind blogging about your new roadmap?
<Keybuk> I don't have a roadmap yet
<mbiebl> hm, ok
<JohnFlux> Keybuk, offtopic a bit, but I recently added support for showing the memory usage of a process to system activity
<JohnFlux> Keybuk, http://img199.imageshack.us/img199/2900/ksysguarddetails4.png
<JohnFlux> Keybuk, it's pretty cool imho :-)
<mbiebl> Keybuk: I know you don't like #ifdefs, but the introduction of __abort_msg in libnih bumped the glibc dependency to 2.11 if I see that correctly
<Keybuk> JohnFlux: the private library bit of C++ apps always scares me
<Keybuk> it's the relocation tables
<ion> johnflux: /me suggests 3.6&nbsp;MB (assuming itâs using a HTML renderer).
<Keybuk> mbiebl: only if you build against glibc 2.11
<Keybuk> and only if your glibc is configured strangely
<Keybuk> (afaik __abort_msg isn't a versioned symbol for glibc - it's a private one)
<JohnFlux> ion, actually I was thinking of making it a non-breakable half space
<mbiebl> Keybuk: well, it seems I can't compile libnih with 2.10
<JohnFlux> ion, I'm not sure if I can do that in html
<Keybuk> mbiebl: should be able to.  you trying 1.0.1 ?
<mbiebl> lemme try again
<Keybuk> it's a weak reference anyway, your glibc can be missing it entirely and things still work
<ion> johnflux: &#x2009;
<ion> johnflux: Sorry, that wasnât nonbreakable. (Oh, and &thinsp; would be a better name for the same thing anyway.)
<JohnFlux> ion, I think there might be a 0-width nonbreakable character
<ion> johnflux: CSS: .nobr { white-space: nowrap; } and then <span class="nobr">...</span>
<JohnFlux>   ah maybe 202F
<JohnFlux> NARROW NO-BREAK SPACE
<JohnFlux> ion, maybe your way is better though :-D
<JohnFlux> since they are already in a span anyway
<mbiebl> http://paste.debian.net/59231/
<mbiebl> Keybuk: I'm at revision 1031
<mbiebl> libc is 2.10.2-5
<JohnFlux> ion, your way worked nicely - thanks :-)
<Keybuk> mbiebl: I just renamed __abort_msg to _x_abort_msg and it worked for me
<Keybuk> (in the code)
<mbiebl> Keybuk: have you pushed those changes?
<Keybuk> yes
<Keybuk> huh
<Keybuk> looks like lp is weirdly out of date
<Keybuk> if I pull from lp via ssh, I have -r 1036
<Keybuk> but if I pull via http, I have 1031
<Keybuk> let me try forcing a push again
<mbiebl> yep, that's what I get
<Keybuk> ok
<Keybuk> try pulling now
<Keybuk> I've forced a push again
<Keybuk> http://bazaar.launchpad.net/~scott/libnih/trunk/revision/1033 being the important commit ;)
<mbiebl> Keybuk: make passes, make check is running but it takes looong
<Keybuk> test_node ?
<mbiebl> that one almost killed my poor laptop :-)
<Keybuk> it's always been a big one
<Keybuk> and since it's basically really stress testing the code that interfaces init to the rest of the system, I feel it deserves really thorough testing :p
<mbiebl> ok, all tests passed
<Keybuk> sweet
<mbiebl> no, on to trying this --with-local-libnih option
<mbiebl> how is that supposed to work?
<Keybuk> basically
<Keybuk> bzr branch lp:libnih
<Keybuk> bzr branch lp:upstart
<Keybuk> cd libnih ; autoreconf ; ./configure ; make
<Keybuk> cd ../upstart ; autoreconf ; ./configure --with-local-libnih=../libnih ; make
<mbiebl> trying...
<mbiebl> Keybuk: http://paste.debian.net/59235/
<mbiebl> sorry, German locale
<mbiebl> but I guess you get the error
<mbiebl> upstart bzr is at -r1228 fwiw
<mbiebl> Keybuk: that one is better http://paste.debian.net/59237/
<mbiebl> I guess it's a quoting problem
<mbiebl> -I"\"/home/michael/bzr/libnih\"" looks suspiocious
<mbiebl> http://paste.debian.net/59238/ fixes it for me
<Keybuk> oh, hmm
<Keybuk> wonder what I was thinking there
<Keybuk> probably -D ;)
<Keybuk> (and I wonder why it works here)
<mbiebl> oh
<mbiebl> interesting
<Keybuk> gcc difference maybe
<Keybuk> it only needs to be -I"..."
<Keybuk> the "\"...\"" thing is for when you do -Dsomethingdir="\"...\""
<pilch> Helo. My upstart/init is telling me, "Failed to connect to to socket /com/ubuntu/upstart: connection refused". Any suggestions on what to read to fix this? I don't know where /com/ubuntu comes from...
<pilch> I'm perfectly happy being pointed to the correct FM to RT...
<Keybuk> upstart isn't telling you that
<Keybuk> now tell us what is telling you that
<pilch> The only way I am able to boot my system is by booting with init=/bin/bash. After remounting rw, I attempted to run "init 1" which then tells me that error.
<mbiebl> pilch: which distro?
<pilch> just upgraded to ubuntu/lucid
<pilch> there is no "/com/ubuntu" directory. I'm assuming something creates it? Not sure what...
<Keybuk> pilch: if you do init=/bin/bash, you're not running Upstart
<pilch> keybuk: is it possible to transition from bash to upstart? 
<Keybuk> pilch: exec /sbin/init
<pilch> ah. ok. Let me try that.
<pilch> Ah, thank you. Now at least I can see what's going on while upstart is, uh, starting up. It had previously been hanging on a blank screen when I would try to boot up normally.
<pilch> hmm. It appears to be stuck on the if-up.d/upstart script. It's running initctl emit net-device-up IFACE=lo ADDRFAM=inet METHOD=loopback
<pilch> any idea why that command would hang?
<Keybuk> pilch: update your lucid install
<pilch> meh. I did... hmm, maybe dpkg-reconfigure will work now.
<Keybuk> that was an NM bug that was fixed
<pilch> oohh. well, let me try again and see if it grabs an update...
<pilch> ooh, fun. A TeX upgrade is included...
<pilch> well, hopefully this will solve it... off to reboot.
<pilch> Hmm. No. It still hangs.
<pilch> :/
<mbiebl> Keybuk: interesting. Apparently sysvinit used SIGUSR1 to reopen /dev/initctl
<mbiebl> just wondered, why the Debian init scripts send a kill -USR1 1
<mbiebl> mountall.sh, to be precise
<lnieves> Hello, I was wondering if anybody could point me in the right direction about trying to solve LP#328881
<lnieves> which deals with the issue of boot logging
<lnieves> what I know so far: the handler for the "console" stanza is system_setup_console() in init/system.c
<Keybuk> lnieves: what do you mean by "solve" ?
<lnieves> there should be a case CONSOLE_LOGGED or something similar, which is missing
<lnieves> I mean, try to implement the "console logged" stanza, which is ignored
<lnieves> and by that, add the boot logging, which has been missing since long time ago
<Keybuk> console logged was removed deliberately
<lnieves> https://bugs.launchpad.net/upstart/+bug/328881
<Keybuk> you already pointed at the wishlist bug
<lnieves> So, is there no plan or intention to solve that bug/wishlist?
<lnieves> maybe i misunderstood
<Keybuk> the bug is open, so there's an intention to solve it
<Keybuk> there's no plan though
<Keybuk> other than "find a way to log output of jobs, even while the root filesystem is read-only, that doesn't cause other problems"
<lnieves> i see.
<lnieves> OK, so, I'm a right that the place to start thinking about changing is in init/systeá¸¿.c ?
<sadmac2> lnieves: sounds like a plan
<lnieves> OK, another question. The (in)famous bootlogd manages to somehow get the output from jobs and send them to /var/log/boot
<Keybuk> lnieves: certainly that's where the change would begin
<Keybuk> lnieves: no it doesn't
<lnieves> so, **in principle** it would be possible to "borrow" code from bootlogd?
<lnieves> no? I thought it did
<lnieves> some people pointed to bootlogd as a workaround for the lack of boot logging in upstart
<Keybuk> no, bootlogd does something really quite different
<lnieves> in which way?
<Keybuk> in every way
<lnieves> do you care to elaborate?
<Keybuk> do you know how bootlogd works?
<lnieves> no, if i knew I would not be asking, would i?
<lnieves> But, never mind. I have the source code for both projects, so I can look it up myself.
<lnieves> I was just trying to get an idea quicker than it would have taken me to surf through the source code.
<lnieves> I'll give it a try and you'll certainly know when/if I succeed or when/If I have more "structured" doubts about the changes.
<lnieves> cheers!
<Keybuk> "hi, I don't know anything, but I'm going to solve the world - could you tell me how?"
<sadmac2> Keybuk: I was him once. Come to think of it I still don't know anything. Still, I'm very close to curing cancer.
<Keybuk> sadmac: at least he didn't ask for help programming in C
<ion> keybuk: http://www.youtube.com/watch?v=ReOw_2f4lpY
<sadmac> woohoo! one bug left and I can submit all this shit!
<sadmac> Keybuk: several bloody months later, libnih /will/ grow that parser I promised.
<sadmac> this is the most hard-fought 435 lines of my career
#upstart 2010-02-10
<ion> Awesome
<ion> http://johan.kiviniemi.name/blag/world-of-resources/
<Q-FUNK> hi!
<Q-FUNK> is there any howto on converting init scripts to upstart services? I'd like to give it to CUPS.
<sadmac2> Q-FUNK: no precise howto. the manpages may help though
<Q-FUNK> sadmac2: that was somehow the last place I expected to look :)
<coolo> moin
 * coolo is trying to get upstart@opensuse and fails to figure out basic stuff
<coolo> how to debug why a job is not set to stopped when the last line of script is run?
<AaronSDG> Hello, all!  I have some software that starts with special startup.sh and shutdown.sh scripts.  Is it possible to give upstart different exec stanzas for startup and shutdown?
<sadmac> AaronSDG: no, though you may be able to place the shutdown in pre-stop
<AaronSDG> I hadn't thought of that.  I will give it a try.
<ion> clangâs static analyzer seems nice: http://www.hitzemann.org/stuff/report.html#EndPath
#upstart 2010-02-11
<JanC> coolo: that's difficult to say if we don't know what script, what you expect to happen, and what happens...  ;)
<coolo> JanC: I try to get the basic rc.conf und tty.conf to start
<Speedy2> Hey all.  I'm trying to debug an issue with my Upstart configuration ; I don't seem to get tty / getty is not running.  I've tried copying over /etc/init, /etc/rc* and /etc/init.d from a working setup to mine (both Karmic).  But, still no getty / tty process.
<Speedy2> Looking at the /etc/init/tty*.conf, everything seems in order.
<Speedy2> It sounds like the scripts are not running any of the run-levels since the ttys are tied to being in runlevel.
<coolo> a little googling revealed, I have http://www.mail-archive.com/upstart-devel@lists.ubuntu.com/msg00747.html
#upstart 2010-02-12
<coolo> JFYI, http://lists.opensuse.org/opensuse-factory/2010-02/msg00092.html
<Keybuk> sweet
#upstart 2010-02-13
<coolguy4> hello, I want to configure upstart so that when I do ALT-CTRL-Fn, I can load xorg inside a chroot
#upstart 2011-02-07
<djszapi> Keybuk: ty ;)
<Keybuk> djszapi: no problem; hopefully that will solve your problems
<Keybuk> since it should end up on minicom
<Keybuk> and if all else fails, will be buffered in dmesg
<djszapi> ok :)
<djszapi> How are you btw ?
<Keybuk> not too bad
<Keybuk> still settling in to new country and job, but it's a good thing
<djszapi> hehe that is nifty :)
<djszapi> I have just relocated half a year ago, thus I know what you are talking about :)
<ion> Oh, youâve moved to the Free World.
<ion> Done reading the blog entry. :-)
<Keybuk> the blog entry I posted months ago?
<ion> 2011-01-11
<Keybuk> a month ago, :)
<ion> Have fun with Google. :-)
#upstart 2011-02-08
<djszapi> Keybuk: btw, I am not sure I understand your implementation
<djszapi> I mean the bootlogd of the sysvinit is much longer.
<djszapi> I understand you just open the /dev/kmsg up for writing, but... ;)
<djszapi> http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/bootlogd.c?root=sysvinit&view=markup
<Keybuk> right
<Keybuk> bootlogd is a really complicated thing that never works
<Keybuk> it *tries* to work by redirecting console output into itself with an ioctl
<Keybuk> (assumedly into a tty)
<Keybuk> and then buffering that output internally until a filesystem is available (by constantly trying to write)
<Keybuk> and then finally once a filesystem is available, flushing out, and then carrying on writing
<Keybuk> the thing is
<Keybuk> bootlogd rarely works
<Keybuk> because it relies on a whole massive stack of things that generally you don't have in the earliest phases of boot
<Keybuk> so I cheated :p
<Keybuk> my patch makes init stuff its output into the kernel's own log system
<djszapi> rotfl ;)
<Keybuk> (the same one that printk() uses in the kernel)
<Keybuk> that's already buffered by the kernel
<Keybuk> and you can change the size of that buffer on the command-line if it overflows
<Keybuk> and there are well understood mechanisms for getting the data out (dmesg)
<Keybuk> or for flushing and writing to files after (klogd)
<Keybuk> etc.
<Keybuk> the only thing it needs is /dev/kmsg, which tends to exist fairly early
<Keybuk> thanks to devtmpfs :)
<Keybuk> (where fairly early is before userspace)
<djszapi> you might want to mention these information on the mailing list before others start asking or to just englighten others about the differences.
<Keybuk> if people ask, I shall answer
<djszapi> let me ask it there :P
<djszapi> so it needs devtmpfs...mg.
<djszapi> * I mean mmh
<djszapi> so what happens before mounting that ?
<djszapi> 'it *tries* to work by redirecting console output into itself with an ioctl' and 'bootlogd rarely works' -> sounds hilarious in a way ;)
<djszapi> I mean it is so old stuff, I would expect it is quite stable.
<SpamapS> Keybuk: could this same trick be used for bug #328881 ? or.. did I miss where you said thats the whole point?
<SpamapS> Keybuk: I know the plan for that bug (logging job output) is to use a ring buffer inside upstart.. which I think would be preferrable..
<Keybuk> djszapi: before that, it'll probably just fail to log
<Keybuk> but since /dev will be one of the very first things you create ...
<Keybuk> SpamapS: right, it's quite different
<djszapi> Keybuk: sounds about bad :)
<Keybuk> I don't think we want to dump job output into dmesg ;)
<djszapi> but the bootlogd implementation depends on the /dev too as long as it tries to write it, thus...can be tolerated :P
<Keybuk> yeah
<Keybuk> bootlogd actually usually depends on /dev *and* /dev/pts
<Keybuk> and in many situations, /dev/pts might be one of the very last things you setup (since nominally, you don't need it until you come to fiddling with xterms)
<Keybuk> (you could always mknod /dev/kmsg in your initramfs, if you have one :p)
<djszapi> yeah, I see.
<djszapi> *giggles*
<djszapi> fine with me then, I do not just understand why that hackery exists at all :P
<Keybuk> because this is not a solved problem
<djszapi> huh ?
<Keybuk> doing anything (such as logging) during boot
<Keybuk> it's not a solved problem
<Keybuk> so hackery is required
<djszapi> well.....
<djszapi> did you see the mail in 2002 about it on the kernel mailing list ? :)
<Keybuk> "it"
<Keybuk> and my god, you expect me to remember an LKML mail from 9 years ago?!
<Keybuk> have you SEEN the traffic on that list?! :p
<djszapi> well you should ;)
<djszapi> hehe :P
<Keybuk> no, I really shouldn't
<Keybuk> :p
<djszapi> muhah
<djszapi> well it was interesting thread in fact.
<djszapi> targetting the issue we are talking about :)
<djszapi> but anyway...3 am, ty again ninis :)
<seventoes> is su the only way to run jobs as unprivileged users right now?
<seventoes> How do i figure out which rule caused this message?
<seventoes> start: Rejected send message, 1 matched rules; type="method_call"
#upstart 2011-02-09
<twb> the varnish sysvinit script does "ulimit -n ${NFILES:-131072}" and "ulimit -l ${MEMLOCK:-82000}", to increase process limits.
<twb> When translating that to an upstart job, would they go in pre-start script, or what?
<twb> Never mind, I don't care.  increasing ulimits isn't permitted in my varnish container in any case, because it doesn't have CAP_SYS_ADMIN.
<JanC> twb: upstart also has a "limit" stanza
 * twb reads upstart(7) manpage
<JanC> it's in upstart(5)  ;)
<twb> Ah, cool.  I didn't realize that was there
<JanC> and I meant init(5) of course  ;)
<twb> http://paste.debian.net/106987/
<twb> How does that look (for lucid)?
<twb> Add a update-rc.d varnish remove in there, too
<SpamapS> twb: you have to specify the soft and hard limit
<twb> Doesn't matter now; it turns out varnish can't do HTTPS, so I lost interests
<SpamapS> bummer
<twb> Now I'm trying to learn enough apache to make it authenticate against PAM
<twb> It turns out the old server was using mod_perl's "PerlAuthenHandler Apache::AuthenNIS"... yeesh
<SpamapS> sounds like a classic
<twb> AFAICT I can point apache directly at slapd (which might work), but I can't say "just trust pam like a normal bloody package"
<SpamapS> mod_auth_pam has worked for me in the past
<twb> Apparently it's unmantained
<soren> Stuff that uses pam for authentication also often needs root privs.
<soren> Something I'd rather not bestow upon a web server.
<twb> granted
<twb> FWIW, mod_authnz_ldap worked perfectly (to my immense surprise)
<SpamapS> ok, I know its time for bed when I see jhunt signing on
<SpamapS> jhunt: given any thought to that ureadahead bug about not having a writable /var/lib/ureadahead ?
<jhunt> SpamapS: I like the idea of sending a signal. Maybe we can contrive a nasty test to see how big we can make the packs. keybuk has mentioned that the fix for bug 523484 might work but isn't optimal since by the time /var (separate partition) is mounted, ureadahead will have lost the opportunity to consider reads for libc, etc.
<SpamapS> Right...
 * jhunt double-takes
<jhunt> bed? no. dinner yes :)
<SpamapS> I'll post my ideas about the implementation of the signal idea in the bug report. You're off to dinner then?
<jhunt> in a few mins. back l8r prolly...
#upstart 2011-02-10
<Keybuk> morning
<adam_g> heya.
<Keybuk> how goes?
<adam_g> well. working with upstart for the first time.
<adam_g> does a concept equivilent to the status operation of an LSB init script exist in upstart currently?
<djszapi> hi Keybuk
<djszapi> Keybuk: upstart logging does not work ...
<Keybuk> djszapi: it does, millions of people use it every day
<Keybuk> it may not be working for you
<Keybuk> I'm honestly starting to suspect somebody at Nokia has disabled that code in your source tree
<djszapi> nope
<djszapi> I made an own build today.
<Keybuk> well, it works for me
<Keybuk> perhaps you could tell me more about what doesn't work
<Keybuk> what you've tried
<Keybuk> etc.
<djszapi> it does not help me if you keep repeating it :)
<Keybuk> it doesn't help you if you just say "nope" either ;-)
<djszapi> I just know it can work, thus it is worthwhile to try to fix it.
<djszapi> well "nope" is a kool word :P
<djszapi> btw, have you read my mail ?
<Keybuk> I haven't read your mail
<djszapi> I do not know what else I could amend it with ...
<Keybuk> ok
<Keybuk> so you've patched upstart with my kmsg patch?
<Keybuk> and that version of upstart is currently running as pid #1 ?
<djszapi> well, about.
<Keybuk> "about" ?
<djszapi> yeah, the patch did not change anything to the previous statement, there are *NO* such messages anywhere.
<Keybuk> right, I'm asking whether you have that version patched and running ;-)
<Keybuk> ok
<Keybuk> so let's try something
<Keybuk> (as root) run the following
<Keybuk> # initctl log-priority
<Keybuk> it should print a word, what is that word?
<djszapi> FYI: I am @ home.
<djszapi> 21:06 pm
<Keybuk> can you not access that box?
<Keybuk> no VPN or anything?
<djszapi> to the prototype ?
<djszapi> no, I cannot.
<Keybuk> ah
<djszapi> it is quite perfectly locked into the safe box.
<Keybuk> what time of day can you usually access it?
<djszapi> while being there ? :)
<Keybuk> what time?
<djszapi> no idea :)
<Keybuk> haha, right
<djszapi> change day by day
<djszapi> really...
<Keybuk> so what I'll do is reply to your mail with a sequence of debugging steps
<Keybuk> if you could follow them exactly, and answer each of them when you have access to the box
<Keybuk> then I should be able to figure out what's going wrong with it
<djszapi> well
<Keybuk> please don't skip steps if you think you know the answer, the output I'm asking for is subtle and you might miss something that would tell me the problem
<djszapi> I can access to it in 11 hours
<djszapi> ok sure do not be afraid of that :)
<Keybuk> yeah, in 11 hours I'll be going to bed
<djszapi> btw, we use 0.6.6
<djszapi> with quilt patchset
<djszapi> where should I see kmsg logs ?
<djszapi> I tried the dmesg and the console where printk happens.
<Keybuk> I actually have a hunch what's wrong
<Keybuk> based on something somebody else at Nokia told me earlier this week ;-)
<djszapi> or go thorugh pls.
<djszapi> maybe I can answer for some of them
<djszapi> which can already show the mistake ...
<Keybuk> well, first in your mail you say "warn" which actually means upstart will log *less*, you want log-priority info ;-)
<djszapi> somebody ?
<djszapi> me or other guy ?
<djszapi> yes
<Keybuk> but I think in MeeGo you have an /sbin/init shell script wrapper for Upstart
<djszapi> I tried info
<djszapi> that was done
<Keybuk> and that wrapper is not passing command-line arguments to Upstart
<djszapi> nothing changed regarding this
<djszapi> that is a typo in the mail, sorry.
<Keybuk> right
<djszapi> I wanted to send a mail.
<Keybuk> well, reply to my mail when you have the box, and follow the steps
<djszapi> I have just been at the school
<Keybuk> and we'll chat tomorrow
<djszapi> "but I think in MeeGo you have an /sbin/init shell script wrapper for Upstart" -> why so ?
<djszapi> btw, ROTFL !!! :-) http://i.imgur.com/4kepL.jpg
<Keybuk> djszapi: because someone else told me you do in the thread where I posted the kmsg patch
<djszapi> huh ?
<djszapi> not gotcha ...
<Keybuk> it's ok
<Keybuk> we'll pick this up tomorrow
<djszapi> highly doubt
<Keybuk> hey ;-) I'm trying to help here
<djszapi> during your sleep ?
<Keybuk> tomorrow my time
<djszapi> if yes, I am fine with that :)
<Keybuk> ie. this time tomorrow once you've gone through the steps in my mail
<djszapi> well ...
<djszapi> when I will get to my box, you will be sleeping.
<Keybuk> yes
<Keybuk> so you reply to the mail
<Keybuk> and then when I'm awake, I read the mail
<Keybuk> and hopefully in the output of all the commands will be the clue that tells me what's wrong
<djszapi> well I have access to the srouce code.
<djszapi> * source
<djszapi> if I can help anything with that, do not hesitate to tell me ...
<djszapi> btw, I did see nowhere this --verbose option.
<djszapi> maybe it is just not documented ?
<Keybuk> it's built-in to nih/option.c
<djszapi> odd I was thinking that it is kernel thingy ;)
<Keybuk> no
<Keybuk> it's an upstart thingy
<djszapi> Alright.
<djszapi> cya tmrw.
<djszapi> ty in advance.
<Keybuk> (mail should be in your inbox now btw)
<djszapi> it is not.
<djszapi> just the thread ...
<djszapi> got.
<djszapi> haha I think all the output will be ok :)
<Keybuk> I'm not looking for "ok" or not "ok"
<djszapi> (I am just kidding)
<Keybuk> I'm looking for a clue that tells me what's wrong that you may miss
<Keybuk> Upstart, like most software, uses different strings for the same states in different places
<Keybuk> so by reading a log, as a developer, I can see what it's doing which isn't obvious to others
<djszapi> that is exactly what I meant with "ok", nothing is gonna inform you :)
<djszapi> okay, let us see and really thank you.
<Keybuk> np :p
#upstart 2011-02-11
<BlackDex> Hello...
<BlackDex> I am trying to create an upstart conf script
<BlackDex> but it is not working very wel..
<BlackDex> How can i debug the script?
<BlackDex> see the output or something?
#upstart 2011-02-12
<Renfield> I'm looking at a problem with starting a service via upstart. I'm using Ubuntu (not sure exactly which version), with, I believe upstart 0.6.3-11.
<Renfield> The behavior leads me to believe that procps is not starting at boot. This is on a RackSpace virtual server.
<Renfield> I'm having difficulties determining if in fact procps is starting or not, actually.
<Renfield> If I've read documentation correctly, if I pass init="/sbin/init --verbose" on kernel boot, that should give me more information about what upstart is doing.
<Renfield> However, in this virtual server, I don't have access to change the kernel parameters.
<Renfield> I tried adding "exec /sbin/initctl log-priority debug" to the script stanza of /etc/init/mountall.conf, but then the server does not complete a boot up.
<Renfield> Also, though that causes some upstart information to come out on console, it doesn't also log it anywhere, and the console access from RackSpace isn't great.
#upstart 2012-02-07
<SpamapS> jodh: https://code.launchpad.net/~clint-fewbar/upstart-cookbook/clarify-complex-start-stop/+merge/90379 ... bump
<jodh> SpamapS: merged! I tweaked the content a little so let me know if its still unclear.
<SpamapS> jodh: no, looks good.
<bencer> hi dudes, i'm writting upstart scripts for some packages we use in zentyal, like dansguardian, isc-dhcp-server, bind9, slapd, etc... i'm migrating all the features present on their current init.d scripts
<bencer> do you think we are still on time to upload these changes? would be anybody interested in sponsor the uploads?
<JanC> I can't sponsor anything, but would love to see more upstart jobs  âº
<JanC> BTW: upstart jobs aren't "scripts"  ;)
<bencer> they still have script magic between the script stanzas ;-)
<JanC> bencer: also, this is not really the place to ask for Ubuntu package sponsors (this is the upstream upstart channel)
<JanC> asking comments on your upstarts jobs is okay of course
<JanC> a good review by an upstart developer might help getting it into Ubuntu
<JanC> and yes, some upstart jobs contain script fragments
<bencer> what is the upstream suggestion on where to add things like mkdir /var/run/named , in the  pre-start or in the script section? what's the recommended usage of each one?
<bencer> well, this is the approach i took: http://paste.ubuntu.com/833162/
<JanC> bencer: pre-start exec/script is defined as âThis process will be run after the job's starting(7) event has finished, but before the main process is run.  It is typically used to prepare the environment, such as making necessary directories.â
<bencer> so according to that, the mkdir-like things, should go to the pre-start
<JanC> bencer: so I guess creating directories is best done in the pre-* part
<JanC> right
<bencer> that not what i saw in other upstart scripts :) but, okey
<JanC> except if there is a good reason to do it elsewhere  ;)
<JanC> bencer: feel free to file bugs for those other *jobs*...
<bencer> ok, good, with that i will review what i did and i will file the bugs
<JanC> either those jobs or the manpage is wrong  ;)
<JanC> (or there is some exception to the rule involved)
#upstart 2012-02-08
<SpamapS> Hrm.. jenkins forks and exits when you send it HUP
<SpamapS> meaning the job appears to die, and upstart loses track of the pid
<SpamapS> May have to drop pid tracking for it then. Bummer.
<marrusl> what's a good late-in-boot-as-possible event normally?  runlevel 2?
<marrusl> SpamapS, ^
<SpamapS> Heh, we just had a big discussion about this yesterday
<SpamapS> there isn't a good one
<marrusl> :)
<SpamapS> the best you have is 'stopped rc RUNLEVEL=[2345]'
<SpamapS> Which is when tty1 pops up
<marrusl> SpamapS, brings to mind the famous question...  what's your sleep(1) number?
<SpamapS> marrusl: we need an intermediate job for mid-boot things that you want to track the state of. this goes back to the 'network-services' job.
<SpamapS> lol
<SpamapS> marrusl: what class of things do you want to be after?
<SpamapS> If its "everything" .. we're probably going to transition nearly everything that is 'start on runlevel [2345]' to be 'start on starting network-services'
<SpamapS> and then if you want to be "after that stuff" you will be 'start on started network-services'
<marrusl> SpamapS, in this case networking indeed.
<marrusl> and it's on lucid.  :-/
<SpamapS> marrusl: for networking, runlevel 2 is good 11.10 and later
<SpamapS> marrusl: for lucid, your best bet is to delay runlevel 2 for all of the network devices
<SpamapS> I wonder..
<SpamapS> perhaps we should backport the static-network-up event
<SpamapS> not the change to /etc/init/rc.conf
<marrusl> SpamapS, basically so far your idea to use "start on started udev" seems ok, but since the problem condition is so rare (~3-5% of boots) we have to script checking for the problem conditions...
<marrusl> and if none, reboot.
<marrusl> but when I had an invalid upstart job starting infiniband (well failing to start)
<marrusl> the script didn't catch the error condition and kept rebooting. 
<SpamapS> marrusl: burn-in test :)
<marrusl> SpamapS, haha.  basically yup.
#upstart 2012-02-09
<bradleyayers> I'd like to do complex "start on" conditions and restarting is important to me, I think I saw someone say the issue could be worked around by using extra jobs, but I don't remember the specifics, can anyone point me in the right direction?
<bencer> i've made the followin dansguardian upstart job but echo doesnt work despite using console output http://paste.ubuntu.com/834957/ could anyone  give me some hints?
<bencer> JanC: you suggested a couple of days ago that this was the right channel to ask feedback on upstart scripts?  if you have the time, have a look at my previous message
<marrusl> what are the most likely reasons to see runlevel "unknown" ?
<marrusl> SpamapS, ^ :)
<marrusl> from what I gather it's often a sys v service failing?
<SpamapS> marrusl: if you're up to sysv.. you're at runlevel 2 already
<marrusl> doh
<marrusl> SpamapS, sooooo.... no.
<marrusl> What else?
<marrusl> I'm going to get a --verbose log regardless.
<marrusl> But it hasn't happened since we started looking!  (of course)
<bradleyayers> bencer: i assume you're using upstart 1.4?
<bencer> bradleyayers: i'm using precise
<bencer> so, yes, 1.4
<bencer> everything works fine, but the output thing
<bradleyayers> does it work if you log to a file?
<SpamapS> marrusl: unknown is schroedingers runlevel
<marrusl> SpamapS, lol.  yea verily.
<bencer> bradleyayers: as far as i could see no, should go to syslog, right?
<bencer> or you mean echoing into a /tmp file?
<bradleyayers> well there's console options to output to a file aren't there? i meant try those
<bencer> ok, going to give that a try
<bradleyayers> perhaps pre-start stuff doesn't adhere to the same console rules as exec/script
<bencer> by default should be logging to syslog, right?
<SpamapS> I'm not 100% certain but IIRC console log is still disabled in precise
<SpamapS> you have to boot with '--log'
<bencer> SpamapS: so, now way to echo anything into the console?
<bencer> basically i'm trying to replicate init.d behaviour as close as possible: http://paste.ubuntu.com/834957/
<SpamapS> bencer: console output will go to /dev/console
<SpamapS> bencer: and | logger  will go to syslog
<bencer> and what about echoing to the terminal?
<SpamapS> thats not possible
<bencer> ok, understood
<SpamapS> its been discussed.. perhaps via a dbus channel to initctl
<SpamapS> but first we wanted to be able to log somewhere reliably :)
<bencer> what do you suggest i should do in this case?
<bencer> /dev/console or syslog?
<bencer> because i'm going to find this issue in other init.d scripts
<SpamapS> bencer: for precise?
<bencer> yes
<SpamapS> bencer: --log will be on by default
<SpamapS> so use console log
<bencer> SpamapS: what i'm trying to do is to submit patches to migrate dansguardian, isc-dhcp, bind9 and slapd (at least) to upstart
<SpamapS> bencer: slapd you have to be careful with.. 
<bencer> and i've 7 days left :)
<SpamapS> bencer: its signals are non-standard
<SpamapS> bencer: it may be better to still call the init.d script, from pre-start and post-stop scripts.. and just the upstart job to control when it starts/stops in the boot
<bencer> what should i do in this case?
<ianl`> is it possible to start a process as another user, instead of as root using upstart?
<bencer> actually i'm very interested in the respawn thing
<bencer> not in the boot speed up
<SpamapS> ianl`: http://upstart.ubuntu.com/cookbook/#changing-user
<ianl`> thanks
<SpamapS> bencer: s/boot speed up/boot coordination/
<bencer> agreed, speed up is only a consecuence of that :)
<SpamapS> bencer: having an upstart job has very little to do with speed up.. it allows you to coordinate the start of other things which need slapd
<bencer> and is there any way to transform signals or something like that? or i'm basically against the wall here?
<SpamapS> bencer: you can change the kill signal, but not the reload signal
<bencer> SpamapS: so the problem is that slapd doesnt use sighup for reloading?
<SpamapS> bencer: right, and I think TERM is also dangerous
<SpamapS> bencer: RTFM on slapd before doing this. :)
<bencer> i will
<bencer> thanks for the feedback
<bencer> well, i could imagine if nobody had done this before for popular packages like slapd, there was a reason
<SpamapS> bencer: there are open bugs on many
<bencer> well, for example on dansguardian seems to be trivial to do
<SpamapS> bencer: frankly, I don't see enough value for some things. slapd actually does need to be done, because it can be used to support local auth
<bencer> on my experience, for example, dansguardian is very useful, on zentyal dansguardian used to die from time to time, using the respawn thing, if it crashes, everybody is happy because it comes back to life itself
<bencer> and this way, we dont have to install other things like runit or similar
<SpamapS> I love the concept. But upstart's development hasn't really blossomed enough to support all the use cases that init.d scripts can.
<bencer> what we used to do in zentyal to take advantage of the respawn thing was
<bencer> pre-start script
<bencer>     /etc/init.d/slapd stop || true
<bencer> end script
<bencer> exec /usr/sbin/slapd -d 0 -h 'ldap://0.0.0.0/ ldapi://%2fvar%2frun%2fslapd%2fldapi/????x-mod=0777' -u openldap -g openldap -F /etc/ldap/slapd.d/
<bencer> respawn
<bencer> but then, if we slapd gets updated, the postinst does invoke-rc.d slapd restart
<bencer> and things can go funny
<SpamapS> bencer: in newer versions of invoke-rc.d, restart is stop/start
<SpamapS> bencer: it used to not reload the upstart file
#upstart 2012-02-10
<dcorbin_work> This is a valid start clause, right? "start on (getUpdatesComplete and runlevel [2345])"
<dcorbin_work> When I emit "getUpdatesComplete" my script will not start, even though I'm in runlevel 3.
<wereHamster> how can I activate/deactivate services? Is start/stop the only way?
<wereHamster> with perp I can set a bit on a directory mode, and the daemon will start/stop the service accordingly. Anything similar I can do with upstart?
#upstart 2012-02-11
<SpamapS> dcorbin_work: thats because those are *events* not states.. so you have to emit getUpdatesComplete *and* runlevel
<SpamapS> dcorbin_work: if you want to check state, use pre-start...
<SpamapS> dcorbin_work: [ "`runlevel`" = "N 3" ] || stop
<SpamapS> wereHamster: yes start/stop , or the 'start on/stop on' clauses are the only things that will change a job from its default goal of stop to start.
<wereHamster> SpamapS: does it mean I can edit the .conf file and upstart will start or stop it? Or do I have to explcitly tell upstart that I want the state changed?
<SpamapS> wereHamster: if you edit the conf file, and then an event you listed in the start on or stop on is emitted, then the job will be started
<SpamapS> wereHamster: the file changing wouldn't cause a start or stop on its own.. because upstart is event based, not state/dependency based
<wereHamster> bummer :(
<SpamapS> wereHamster: why bummer?
<SpamapS> the behavior is well defined.
<SpamapS> fairly easy to automate things when you can reliably predict the behavior.
<SpamapS> wereHamster: good luck.. heading to bed
<wereHamster> does upstart not source /etc/profile.d/*?
<JanC> wereHamster: of course not, why would it do that?
<wereHamster> because that's where I set $PATH, so it's avaiable to all users and scripts in the system
<JanC> wereHamster: /etc/profile & ~/.profile are only to be read by a login shell...
<JanC> wereHamster: maybe you can use the 'env' & 'export' stanzas to get the result you want?
<wereHamster> yep, that's what I'm doing
<wereHamster> but it's kindof duplication if I have to put the same path into two separate files
<wereHamster> that's my only concern
<JanC> you can maybe source it from the same file?
<wereHamster> true. Or use exec bash --login -c .. in the upstart file
<JanC> why do you need a special path BTW?
<JanC> I guess you could also set & export $PATH in an initramfs (if you use one)?
<wereHamster> because I'm installing software which is not in ubuntu, and am installing it into /opt
<JanC> well, you can always use the complete path when referencing a binary
<bdrewery> If I make a change to /etc/init/mysql.conf, will it get overwritten if I upgrade the mysql package?
<bdrewery> got my answer
#upstart 2012-02-12
<TheMule> hello everyone
#upstart 2013-02-04
<afournier> hi
<afournier> does upstart-socket-bridge handles udp connections ?
<Hurga> Hello. I have a problem with a job misbehaving, and upstart getting confused about its state.
<Hurga> This should illustrate the problem:
<Hurga> root@titan:~# initctl list | grep rsyslog
<Hurga> rsyslog stop/killed, process 18975
<Hurga> root@titan:~# ps ax | grep 18975
<Hurga> root@titan:~#
<Hurga> When I try to start or stop rsyslog in this situation, the start or stop just hangs and nothing happens.
<Hurga> This is not a vserver... I already fixed a similar problem with linux-vserver. In this case, the problem appears if I try to have rsyslogd use /dev/xconsole.
<Hurga> Distro is Xubuntu 12.04
#upstart 2013-02-05
<afournier> morning!
<wmp> hello
<wmp> who can help me? http://serverfault.com/questions/475589/how-to-change-upstar-order-network-after-fstab
<nimo> wmp, try adding in  /etc/init/network-interface.conf   .....  start on net-device-added and mounted
<nimo> wmp, it seems logical but im sure it will fail :(
<wmp> nimo: thank for reply, i try this
<nimo> im just stating to learn all this upstart script.... i will just experiment until I learn them
<wmp> ;)
<wmp> http://wklej.org/id/948135 - and stop on this
<nimo> wmp, which log file is this ?
<wmp> nimo: this is output on tty1
<wmp> so boot.log or dmesg.log
<nimo> wmp, weird i dont got any log messages of any init scripts run ?
<wmp> no
#upstart 2013-02-06
<marcoceppi> For an upstart script I need to exec three things, neither of these things fork, I've been searching through the cookbook but I'm not quite sure what to look for.
<marcoceppi> Would I just create three seperate upstart jobs and have them called by a fourth upstart script?
<Apes> Can Upstart be used to replace cron yet?
<SpamapS> Apes: no
#upstart 2013-02-07
<stgraber> slangasek: http://paste.ubuntu.com/1622593/
<slangasek> whee :)
<slangasek> stgraber: how many extra processes do we have running now, that weren't before? (thinking of memory footprint)
<slangasek> it's init --user + upstart-event-bridge, and that's it?
<stgraber> slangasek: should be just two, yeah
 * slangasek nods
<slangasek> do we expect gnome-session to go away in the near term?
<stgraber> that'd be more a question for desktop I guess, but I don't think it's going to disappear this cycle and I have my doubt about the next one too
<slangasek> stgraber: because you don't think we'll have the subprocesses transitioned over, or because you think we still need other features of gnome-session?
<stgraber> well, I'm not completely sure of what gnome-session actually does. It does seem to spawn a ton of stuff, so we'll basically need to look at every single thing it spawns and translate that into an upstart job
<slangasek> yeah
<slangasek> but that's fairly mechanical work
<slangasek> I'm more concerned about things like the dbus services gnome-session provides
<stgraber> I'm not sure it actually provides any dbus service itself, it spawns a ton of stuff that do though
<stgraber> I guess I can do a quick test with just spawning gnome-settings-daemon and compiz myself, see what I miss if I skip gnome-session entirely
<stgraber> slangasek: with just those two, I'm missing nautilus (no background) and I'm missing all the indicators (not sure what's actually spawning those usually...)
<stgraber> the rest looks good though ;)
#upstart 2013-02-08
<stgraber> dbus start/running, process 20286
<stgraber> gnome-session start/running, process 20323
<stgraber> nautilus start/running, process 20321
<stgraber> compiz start/running, process 20322
<stgraber> gnome-settings-daemon start/running, process 20320
<stgraber> upstart-event-bridge start/running, process 20287
<stgraber> that's a reasonable hybrid which gives me a working session, with the only problem that the session indicator doesn't show anything
<stgraber> alright, I have it in a packagable form, will push that to a PPA
<stgraber> slangasek: packaged and uploaded, will do a quick test on another machine and if it works as well as it does on mine, I'll send a mail to the team (for now) with a couple of notes on the problems I've spotted and had to workaround
<stgraber> (in short, our environment handling needs more work)
<slangasek> stgraber: sweet, nice going
<xnox> gnome-session starts /etc/xdg/autostart/*.desktop (if conditions apply) last time I poked seb & pitti about it they didn't want to transition all of those to upstart jobs, cause then you'd want a bridge anyway to continue maintain support for those.
<xnox> instead they wanted to transition _some_ of them to upstart jobs (the long running/idle/useful for events)
<xnox> which I understand as the once that are shipped by default ;-)
<marcoceppi> I need some help writing an upstart script for some ruby processes
<marcoceppi> Right now the show up in ps as starting but then just disappear and respawn, all but one are non-forking so I'm not sure why it's so circular
<jodh> marcoceppi: have you read http://upstart.ubuntu.com/cookbook/#expect (specifically http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count)?
<marcoceppi> jodh: I did, it forks 47 times :\
<marcoceppi> Really not sure how to convey that to upstart
<jodh> marcoceppi: it sounds rather broken. Is there any way you could arrange for a way for the main process to send SIGSTOP to itself? This is a facility to handle such unusual applications and indicates to Upstart that the process which sent itself SIGSTOP is the master (see init(5) for further details).
<jodh> marcoceppi: presumably most of those forks are starting worker processes? If not, it's very broken.
<marcoceppi> jodh: I'm not sure, if it helps I'm trying to get sidekiq to run via upstart. So it's creating works
<jodh> marcoceppi: sorry, never used it. You might find there is a way to run it in the foreground (and ideally stop it starting working processes until some later time).
<marcoceppi> jodh: when I run the process normally, it never detaches from console, none of them do
<marcoceppi> At least not by default. But when I remove the expect upstart doesn't exhibit the same results as when I run the command as my user
<jodh> marcoceppi: ? In which case, it may well be failing to understand the environment upstart runs it in. See http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in and http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job.
<marcoceppi> jodh:  thanks for the links, I'll start there
<jodh> marcoceppi: good luck!
<marcoceppi> Well, that doesn't really work well.
<SpamapS> marcoceppi: perhaps the code is doing something clever like checking to see if stdin is a tty, and if it is, don't detach?
<marcoceppi> SpamapS: Probably, I'm not sure how to skirt around that. The application stores it's own "pid" file to they can track each other. Any way to tell upstart to use that files contents?
<SpamapS> marcoceppi: yeah, if you just use the pre-start and post-stop
<SpamapS> marcoceppi: you can't use respawn then
<SpamapS> marcoceppi: and the pid won't be shown.. you're just using upstart to coordinate the job with other events at that point
<SpamapS> marcoceppi: Its pretty silly if it can't just run in the foreground
<marcoceppi> SpamapS: I agree
<marcoceppi> As far as googling around I found foreman for ruby/rails that can create upstart scripts for your processes, which might be something I explore. Can't find any of the generated outputs from that though
<SpamapS> marcoceppi: it should not be difficult...
<SpamapS> marcoceppi: if it is.. the thing is overly complicated anyway
<marcoceppi> I would have hoped not
<marcoceppi> SpamapS: so how can I mimic a tty? I've tried playing with the console options but those don't seem to yield the results I wanted
<marcoceppi> If it helps, there are the three files I've created: https://gist.github.com/marcoceppi/4741567
<xnox> what are you trying to start?
<marcoceppi> Rails, sidekiq, and clockwork
<marcoceppi> From the command line, I use bundle which preloads a bunch of environment variables then executes the command based on options supplied
<xnox> bundle is culprit here, but it's a pain to replicate what bundler does.
<marcoceppi> To me, this just seems like an extremely trivial thing, all the previous upstart scripts I've made for other software have been so straight forward. But this whole convoluded forking business, does it fork does it not what is it doing and I can't seem to figure out where to even start
<xnox> bundler does ugly &  crazy stuff despite looking innocent.
<marcoceppi> xnox: I figured, ugh this silly rails stuff has to be so complicated
<xnox> marcoceppi: here http://serverfault.com/questions/327965/how-to-start-a-rake-task-using-upstart people complain about bundler
<xnox> it works with rvm-shell (that one does less hacks)
<marcoceppi> I guess I'll have to install rvm-shell
<xnox> there is also http://ddollar.github.com/foreman/
<marcoceppi> I've seen people mention it. This isn't my project but I might see how hard it would be to put in upstream
<marcoceppi> SpamapS: xnox if it's any conselation. I got foreman to work, but foreman export upstart's scripts also fail
<SpamapS> marcoceppi: doh
<SpamapS> ruby: why you so bad
#upstart 2013-02-10
<min|dvir|us> Hi, having trouble getting my script to start automatically on reboot. https://gist.github.com/dan-transparensee/a0d3ded0f2b655a1257d
#upstart 2014-02-04
<tds5016> hi all.
<tds5016> can someone tell me if there is a way to get the description from the config file?
<tds5016> er the conf file
<tds5016> using initctl?
<jodh> stgraber: hi - could you test https://code.launchpad.net/~cameronnemo/upstart/ipv6/+merge/204599 on ipv6 when you get a chance?
<stgraber> jodh: I could but not very soon, got a bunch of stuff to do before LXC rc1. However if you have that branch built, you can trivially test it yourself even without a global IPv6. Just test with localhost (::1).
<xnox> jodh: is there a way to "query" if a job is set to "manual" over initctl?
<xnox> jodh: or over dbus?
<jodh> xnox: the best you can do is use show-config to determine if 'start on' is set. This is not reliable though since the 'start on' either was no specified, or was cleared via 'manual' - you can't know which.
<xnox> jodh: ack. Going for compatible solution then ;-)
<xnox> jodh: http://paste.ubuntu.com/6874114/
<xnox> jodh: not suitable for user-session, since it has gazzilion of directories that can have override =) but then again wait-for is not shipped as a session job either.
<jodh> xnox: ack - agreed.
#upstart 2014-02-05
<Mariano9> hi guys
<Mariano9> my initctl start/stops hangs in "job goal changed from stop to start/ from start to stop" and will be there for ever
<Mariano9> any ideas why?
<cwright> hi. does anyone have an example of a no-op upstart config?  I need the config file to be in /etc/init and to be called during deploy
<cwright> but to not actually do anything.  i've tried creating a simple /bin/true task but that fails on `service .. stop`
<xnox> cwright: and empty file is a valid job, i thought. let me check
<xnox> cwright: indeed, you can start an empty job.conf and stop it.
<cwright> xnox: thanks, let me give that a try
<xnox> cwright: it's kind of like "initctl emit starting JOB=jobname" and ditto started, stopping, stopped.... apart from you can do it with $ start / stop / restart etc commands
<cwright> xnox: thanks, that really helped
<rm_work> Can someone eye this script and tell me if they see something obviously wrong? https://raw2.github.com/pcrews/lbaas-salt/master/lbaas-haproxy-base/libra-worker.conf <-- I'm getting "/proc/self/fd/9: 2: /proc/self/fd/9: ââ: not found"
#upstart 2014-02-06
<robert_ancell> I'm having trouble with session upstart in Ubuntu. I've forked gnome-settings-daemon into unity-settings-daemon and copied the upstart scripts (http://paste.ubuntu.com/6885290/, http://paste.ubuntu.com/6885292/). However, if I try and run a session gnome-session doesn't start. If I disable the gnome-settings-daemon script it does. So it appears the gnome-settings-daemon script is confusing the startup somehow
<robert_ancell> Any ideas?
<robert_ancell> http://paste.ubuntu.com/6885304/ is the output of upstart on a failed case
<robert_ancell> It doesn't mention gnome-settings-daemon at all
<jodh> robert_ancell: so unity-settings-daemon starts, but gnome-session does not. How are you disabling gnome-settings-daemon? Also, is there anything relevant in ~/.cache/upstart/*.log ?
<robert_ancell> jodh, I'm disabling by moving the .conf to .conf.disabled
<robert_ancell> jodh, I looked in the logs but couldn't see anything obvious
<robert_ancell> I can bundle them up
<robert_ancell> http://people.canonical.com/~bob/upstart-logs.tgz
<jodh> robert_ancell: unity7.conf specifies 'start on xsession SESSION=ubuntu and started gnome-settings-daemon' so if you've disabled gnome-settings-daemon that won't start (unless you've changed other .confs?)
<robert_ancell> jodh, I have also changed that to do "or unity-settings-daemon"
<robert_ancell> no other changes
<robert_ancell> I notice there is a gnome-session log there, might be from a working boot though
<robert_ancell> I'll clear the logs and retry
<jodh> robert_ancell: can you share the whole config for unity7 as that is likely the issue
<robert_ancell> http://paste.ubuntu.com/6885356/
<robert_ancell> http://people.canonical.com/~bob/upstart-logs.tgz for the logs on a fresh run after clearing
<robert_ancell> http://people.canonical.com/~bob/upstart-logs2.tgz
<robert_ancell> I mean
<jodh> robert_ancell: surely that won't work with gnome-settings-daemon though since gnome-settings-daemon specifies 'xsession SESSION!=ubuntu' but unity7 states 'xsession SESSION=ubuntu'
<robert_ancell> we are replacing gnome-settings-daemon with unity-settings-daemon in Unity
<robert_ancell> gnome-settings-daemon should only run for GNOME etc
<jodh> robert_ancell: according to the logs, the unity7 job is stopping in pre-start and not starting compiz. Could that explain it?
<robert_ancell> jodh, I think compiz is started by gnome-session currently
<robert_ancell> so it's behaving correctly
<robert_ancell> my upstart logs in a normal session confirm that (compiz is in the gnome-session.log, unity7.log says "GNOME Session is starting Compiz")
<robert_ancell> fancy coming into the office? ;)
<robert_ancell> jodh, Is there any more information I can collect?
<xnox> robert_ancell: jodh: the typical way to resolve this is to introduce an arbitrary sync event.
<xnox> robert_ancell: jodh: e.g. both "unity-settings-daemon" and "gnome-settings-daemon" should do "initctl emit settings-daemon"
<Mariano9> hi guys
<xnox> robert_ancell: then unity7 would start on "xsession SESSION=ubuntu and settings-daemon"
<robert_ancell> ok, I can try that
<xnox> robert_ancell: ditto e.g. gnome/other desktop environments can do something else.
<Mariano9> is there a command to check if an upstart job is correctly formated? like init-chkconfig or some?
<xnox> robert_ancell: that way one would also be free to use one of the alternative settings-daemons.
<jodh> Mariano9: yes - I put it in the mail I sent you - init-checkconf /path/to/job.conf
<xnox> robert_ancell: one would do "initctl emit settings-daemon" in e.g. post-start
<Mariano9> hey jodh
<Mariano9> cannot find the command
<Mariano9> it isn't there, init-chkconfig
<xnox> robert_ancell: this is similar to how "indicators-*" start events work, it's simply emitted when indicators should start loading. And e.g. unity, gtk3-old-style-applet and others emit it to indicate they are ready to receive indicators.
<jodh> Mariano9: it's *init-checkconf* not chkconfig
<Mariano9> sorry, init-chkconf
<Mariano9> "init-checkconf /etc/init/newrelic_rs_dfw_1.conf, -bash: init-checkconf: command not found"
<xnox> Mariano9: what version of upstart are you using?
<jodh> Mariano9: run "initctl version" to establish that
<Mariano9> 0.6.5
<xnox> Mariano9: excellent =) so pre-historic. Well, we can attempt to valide that job for you by reading it, if you can pass it on to us. e.g. paste.ubuntu.com
<Mariano9> haha, just a sec
<robert_ancell> xnox, same problem after adding the settings-daemon event. Still works if disabling the gnome-settings-daemon config
<Mariano9> https://gist.github.com/Mariano-gon/8845357
<Mariano9> xnox: there you go
<Mariano9> (notice that I've commented some lines as I'm trying to get it goint)
<jodh> Mariano9: you have 2 execs - only the last will be honoured.
<xnox> robert_ancell: hm. Is there a ppa i can try, or is just by co-installing gnome & ubuntu settings daemon on my desktop?
<Mariano9> *going
<seb128> xnox, you should come to the office to help us debug those g-s-d u-s-d issues ;-)
<xnox> seb128: you want me to comute into the office _now_ ?! =)
<seb128> xnox, tomorrow morning would work as well ;-)
<seb128> strike should be over then?
<robert_ancell> xnox, it's not in a PPA at the moment, but I could add it
<jodh> Mariano9: assuming you are running ubuntu lucid, procenv won't be available unless you built it from source?
<Mariano9> nope, centOS 6.x here
<xnox> seb128: i use trains anyway, so i'm unaffected. Tube is mostly non-existent south of the river.
<jodh> Mariano9: what output do you get if you run "sudo start newrelic"?
<jodh> Mariano9: ah, ok :)
<robert_ancell> xnox, if you could come in tomorrow that would be great, we don't need to solve this immediately
<Mariano9> "newrelic_rs_dfw_1 start/running, process 9251"
<Mariano9> upstart sees it as running normal, but it isn't
<xnox> Mariano9: that gist has two exec lines, i think last one wins.
<xnox> Mariano9: the problem is the "bundle exec" was that that strange thing for ruby?
<Mariano9> xnox: yes, it's a ruby gem
<xnox> Mariano9: that will not work nicely as bundle forks many times and relies on environment variables and HOME, neither of which are set from within upstart
<xnox> Mariano9: so you need probably need to do:
<xnox> script
<jodh> Mariano9: comment out the last line (exec bundle) so that upstart runs procenv first if you have that installed, then diff /tmp/procenv-job.log with a procenv log you take in an environment it does start in.
<xnox>     source /path/to/bundle.sh
<jodh> Mariano9: as mentioned, it may well be env vars. I have no idea what newrelic is but does it need $HOME?
<xnox>     bundle exec /path/to/newrelic_rs
<xnox> end script
<xnox> Mariano9: and you probably want "expect daemon"
<xnox> Mariano9: how is your bundle installed? user level or system-wide/root ?
<Mariano9> xnox: jodh ok, does it matter the order of the stanzas?
<xnox> Mariano9: you can't have duplicates, and at the moment I see two "exec" stanzas.
<jodh> Mariano9: no, but as mentioned, if you specify a particular stanza multiple times, only the last is honoured.
<xnox> Mariano9: it's declarative, not a top-down execution.
<jodh> xnox: we've already covered that - see above
<xnox> ah, sorry =)
<Mariano9> right, i meant different stanzas order
<Mariano9> but, it's declarative, so it doesn't matter the order
<xnox> Mariano9: order of different stanzas does not matter, so you can have "start on" at the very end, etc.
<Mariano9> great, let's try those
<xnox> Mariano9: you should source bundle environment, it usually drops a script in /etc/profile.d or the users ~/.bashrc and the like. Not sure where it would live on a CentOS system however.
<xnox> Mariano9: without that, bundle is mostly non-operational.
<xnox> robert_ancell: ok, i'll be in tomorrow.
<xnox> robert_ancell: and we can debug it.
<robert_ancell> xnox, thanks
<seb128> xnox, thanks
<Mariano9> xnox: i think it's the same folder as newrelic_rs
<xnox> Mariano9: right, so try:
<xnox> script
<xnox>     source that-file
<xnox>     bundle exec
<xnox> end script
<Mariano9> because if I cd into it and run bundle exec ./bin/newrelic_rs, it will start great
<xnox> Mariano9: due to chdir stanza you should be in the right directory already.
<xnox> Mariano9: right, but bundle probably installed a script somewhere for your shell to find and source whenever you enter that directory.
<Mariano9> like a link?
<xnox> Mariano9: so one needs that "magic" snippet in the same way.
<xnox> Mariano9: it's been many years since I last used bundle =)
<Mariano9> source stanza will give the right path to execute the bundle command right?
<xnox> source is not a stanza, source is a sh built in command
<xnox> things between script... end script are just normal shell lines executed.
<xnox> and that would be replacing exec.
<Mariano9> ok
<Mariano9> so, again, bundle path is the same as newrelic_rs then
<xnox> Mariano9: oh there appears to be an easy solution for bundler.
<xnox> Mariano9: --deployement --binstubs options
<xnox> Mariano9: http://askubuntu.com/questions/105761/how-to-get-a-bundler-enabled-rails-app-running-as-a-service-with-upstart
<xnox> Mariano9: apart from changing start on/stop on to what you had, it should just work on centos.
<Mariano9> let's see
<Mariano9> two questions xnox: 1- what if the stop job hangs?
<Mariano9> how do I actually stop the initctl job?
<Mariano9> "init: Sending TERM signal to newrelic_rs_dfw_1 main process (11127)" and will stay there for ever
<Mariano9> ctrl+c, now it is shown as stop/killed, process 11127
<xnox> Mariano9: after starting a job establish if the reality matches upstart expectations.
<xnox> Mariano9: which is: process id in `ps' output matches, initctl status.
<xnox> Mariano9: if they don't, the expect stanzas are wrong. more recent upstart handles such situations better.
<xnox> Mariano9: but in your case you probably will need to add "expect fork", or "expect daemon".
<xnox> Mariano9: and to clear the state, you'd need to re-exec upstart -> which actually for such old upstart means reboot.
<xnox> Mariano9: i hope you are not developing this job on a production server.
<Mariano9> host reboot?
<Mariano9> there's no process in ps from newrelic, I've added the expect daemon before executing the start
<Mariano9> is there a way to upgrade this version?
<Mariano9> in fact there is
<Mariano9> would it be good to upgrade it?
<xnox> Mariano9: i don't know. I wonder if we should explore pushing a more up to date upstart into EPEL repositories.
<Mariano9> xnox: so in order to clear the state I need to reboot the server?
<xnox> Mariano9: or rename the job ;-) then the state is clear for the "new job name".
<Mariano9> xnox: right, eventually I'll have tons of jobs :) 
<Mariano9> xnox: is there a way to reload configuration once a job script is edited?
<xnox> Mariano9: the configuration is automatically reloaded, but it will only take affect on newly start instance. So e.g. after a proper $ stop foo, the next $ start foo will use new configuration.
<Mariano9> ok
<xnox> Mariano9: reload/restart is not enough, those keep on using the in-memory configuration.
<mc_bluebeard> Is it advisable to have an exec command that "blocks"â¦ie, that does not daemonize or return, but is instead long-running?
<JanC> if you can, sure
<xnox> mc_bluebeard: you can do that, in that case "your command is ~ running in foreground" and then you shouldn't specify any "expect ..." stanza.
#upstart 2014-02-07
<rojaro> hi
<rojaro> i would like to make sure that my openvpn service is always started immediately after the network start, but before other services start that wait for the network
<rojaro> can anyone point me in the right direction?
<Mariano9> hi xnox: I've asked rackspace support and they told the newrelic plugin agent doesn't daemonize..in fact if I run it, it won't detach from console (i don't know if you remember from yesterday)
<xnox> Mariano9: hm. interesting.
<xnox> Mariano9: i'll setup bundler in experiment. I'm quite busy at the moment however. Can you give me your email in private?
<Mariano9> sure thing
<Mariano9> guys, is it a must to stop a service to be added to upstart monitoring?
<Mariano9> I mean, while I write the script and add it to /init/ the monitored service has to be down?
<jodh> Mariano9: no, but if you want upstart to manage it you'll have to stop your instance at some point and 'start $job'.
<Mariano9> jodh: great
<mc_bluebeard> xnox - thx
#upstart 2014-02-08
<twm> Hey, this cookbook recipe <
<twm> http://upstart.ubuntu.com/cookbook/#stop-a-job-from-running-if-a-pre-start-condition-fails> should note that it's incompatible with setuid.
<twm> If someone could update that, it would be great.  The failure mode is rather confusing; I get this message in /var/log/upstart/{foo}.log:
<twm> stop: Rejected send message, 1 matched rules; type="method_call", sender=":1.161" (uid=121 pid=17016 comm="stop ") interface="com.ubuntu.Upstart0_6.Instance" member="Stop" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
<twm> While I'm here, it's obnoxious that init-checkconf complains about the file extension, because that makes it useless for checking the syntax of debian/{package}.upstart jobs.
<twm> fg
<JanC> twm: I assume that's because it will look for both a *.conf and an *.override, but maybe a parameter to ignore the extension would be useful...
<JanC> (assuming initctl wouldn't complain about it?)
#upstart 2014-02-09
<cantstanya> how did you guys let poettering win, seriously
<cantstanya> you had it in the bag
<cantstanya> they're dual licensed LGPLv2.1 and MIT, you're GPLv2
<cantstanya> like how can you lose with such a lead
<cantstanya> This is pretty much like Gary Coleman vs Mike Tyson, and gary biting his knee and some how winning
<cantstanya> how does this even happen
<JanC> I don't think trolling in here is going to help you...
<cantstanya> JanC: what are you kidding me, I don't need help
<cantstanya> I'm just curious how an upset like this can happen with upstart
<cantstanya> Like was there even effort
<cantstanya> Even without effort, it should have been in the bag
<JanC> why would Debian care about LGPL vs. MIT vs. GPL licensing, as all those licenses are acceptable to them?
<cantstanya> because GPL is the least permissive and obviously they love that, it's part of their agenda. see ICEWEASEL vs Firefox.
<cantstanya> Oh wow I see
<JanC> that has nothing to do with GPL vs. other licenses
<cantstanya> huh?
<cantstanya> are you kidding me
<JanC> it's about trademarks
<JanC> and Mozilla's trademark policy
<cantstanya> that's just part of the ploy
<cantstanya> s/'s/ reasoning is/
<cantstanya> you guys are quitters
#upstart 2015-02-04
<holms> hi :) does anyone knows how to debug upstart? job is unable to start, i have tons of env vars in there. Command itself works, if used standalone.. but with  upstart job it doesn't, and I can't even see why
<holms> hello =\?
<holms> support for 5$ anyone =?
<holms> i'm stuck for so long time
#upstart 2015-02-05
<hitlin37> hi, i want to delay a job start. should i try to add sleep thing? or is it not nice to sleep before start?
<hitlin37> or may be the question should be is it ok to sleep 60 in pre-start?
<gansbrest> hi. I'm using old upstart version 0.6.5 and would like to identify reload signal to handle it in my app
<gansbrest> which signal is used for reload operation?
#upstart 2015-02-07
<tiger98> hello programmers 
<tiger98> please give me a minute of your precious life 
<tiger98> i am trying to write a script that should run by default when the user logs in his Ubuntu system
<tiger98> storing the file in /etc/init folder with name my_script does not work can you please help ...... 
<givemefive912> start on runlevel [2345]
<givemefive912> stop on runlevel [!2345]
<givemefive912> exec yourprogram
<givemefive912> tiger98: 
<givemefive912> tiger98: or do you just want a script for a user?
#upstart 2016-02-09
<TinyNatty> Hi. I'm having some trouble with upstart. I'm no longer able to access my services.
<TinyNatty> Is there a way to verify that I'm upstart is running and not something else?
<JanC> run 'initctl version' maybe?
<TinyNatty> Thanks. I'm getting the error: initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<TinyNatty> That's the same error I get when I try to use the service command.
<JanC> which probably means upstart is not running...
<Natty> Yeah, not sure how that happened. Turned out a reboot fixed it.
#upstart 2016-02-12
<Synthead> I'm trying to write an upstart script for ubuntu 14.01
<Synthead> here's what I have now, just for testing
<Synthead> http://pastie.org/10719758
<Synthead> for some reason, when I do "start test", it hangs
<Synthead> what's going on here?
#upstart 2017-02-06
<fchorney> Hi, I haven't been able to find an answer for this. For an upstart service, you can type "service thing status", and it shows that the process is running or not and shows the PID number. Is there some way to inject some other info for when the status message is sent to the service?
