#upstart 2007-02-26
<reppel> How do i use the `daemon' keyword?
<Trevelyan`> hi, I thought I'd try upstart on debian using the experimental packages. However I was hoping/expecting to find at least some jobs/events already defined (basic stuff like starting udev and mounting fs). but startup-tasks has nothing in /etc/event.d, system-services just has tty?, and sysv-compat has what you'd expect
<Trevelyan`> i looked on the website too. are there no events/jobs already written for the basic/common stuff?
<AlexExtreme> nope, not yet. work has been started though
<AlexExtreme> https://code.launchpad.net/~keybuk/+branch/upstart/replacement-initscripts
<Md> myself, I plan to work integrating upstart with udev and the rest of Debian after the release
<Trevelyan`> looking at https://wiki.ubuntu.com/ReplacementInitscripts, cups should follow hplip (stopped), or the cups hp backend wont be ready
<AlexExtreme> that's just a rough draft
<Trevelyan`> sorry, thought it would help to point it out
<AlexExtreme> :)
#upstart 2007-02-27
<Keybuk> *bounce*
<reppel> hi, is it possible to start a daemon with a given user?
<reppel> (eg. not root)
<reppel> oops
<reppel> is "with" implemented in complex-complex-event-config?
<_ion> Not IIRC
<_ion> The whole thing is probably going to be redesigned. :-)
<reppel> _ion: what do you mean with "the whole thing" ?
<_ion> http://upstart.ubuntu.com/wiki/ComplexEventConfig/UseCases
<reppel> thanks
<khermans__> hello!
<khermans__> Ubuntu Server uses upstart and boots increibly fast -- is this because of upstart?
<khermans__> how can i prove it?
#upstart 2007-02-28
<punkrockmcduck> morning everyone.
* Starting logfile irclogs/upstart.log
<mdales> on upstart 0.2.7, which is what edgy seems to have, what's the correct way to make one script dependent on another having run? currently I have the first script to "initctl emit myevent" and in the dependent script "start on myevent"
<mdales> is this correct?
#upstart 2007-03-01
<cwillu> how can I get a program in an event to start on a particular tty?
<cwillu> nvm, guess it was a getty question
<reppel_> is it possible to pass a env variable from the pre-start stanza to the exec stanza?
<reppel_> sorry 
<reppel_> the respawn stanza
<Keybuk> I'm not sure I understand?
<reppel_> well
<reppel_> i need to respawn a daemon
<reppel_> this daemon takes an optional argument
<reppel_> -D
<reppel_> and i know if i have to call it with the option reading a file on the filesystem
<reppel_> so i thinked about reading this file in the pre-start stanza
<reppel_> but it seems i can't pass env variables from pre-start to respawn
<Keybuk> right
<Keybuk> you can set the same variable for both though
<reppel_> Keybuk: how?
<reppel_> lag lag
<Keybuk> env FOO=BAR
<Keybuk> in the job
<reppel_> Keybuk: yep but the problem is that i need to set FOO to BAR if /etc/sysconfig/video exists (or veryfing a generic condition), otherwise i need to set FOO to another value
<reppel_> you can map this problem to /etc/default/ files
<reppel_> if you source for example /etc/default/daemon and you found interfaces="eth0,eth1"
<reppel_> you need to pass these options to the daemon
<Keybuk> I understand the problem, there isn't a solution to it yet
<reppel_> ok thanks
<reppel_> is it planned for the future?
<Keybuk> dunno
<Keybuk> I've never seen the point of /etc/default files
<reppel_> neither I
<reppel_> just wanted to help you understand :)
<Keybuk> if I were to worry about those, I'd just implement an env FILENAME option or something
<reppel_> Keybuk: what do you suggest in my case?
<reppel_> respawning a script?
<Keybuk> sure
<Keybuk> script ...
<Keybuk> end script
<Keybuk> respawn
<reppel_> you can respawn a script/end script stanza?
<Keybuk> yes
<reppel_> nice :)
<reppel_> much cleaner
<reppel_> thanks Keybuk 
<reppel_> oh, just another question
<reppel_> i have a job used as state
<reppel_> its definition is the following:
<reppel_> on stopped some_event
<reppel_> if i try to stop it i get from initctl the following message:
<reppel_> # initctl stop system-up
<reppel_> system-up (stop) running
<Keybuk> which upstart version?
<reppel_> 0.3.5
<Keybuk> yeah, known bug
<Keybuk> fixed in bzr trunk
<reppel_> in the main trunk?
<Keybuk> yes
<reppel_> ok, thanks a lot
<mdales> initctl emit foo - should that gerenate event foo?
<mdales> or did I misunderstand the docs?
<reppel_> mdales: yes it does
<mdales> okay, but not on 0.2.7?
<Keybuk> initctl trigger on 0.2.7
<mdales> (i.e., what's on edgy)
<mdales> ah
<mdales> thanks
<reppel_> mdales: don't know about 0.2.7, i'm using 0.3.5
<Keybuk> (we changed the terminology)
<mdales> right
<mdales> many thanks
<reppel_> Keybuk: are you still working on specs of complex-event or you have reached a final state?
<Keybuk> still working on it
<Keybuk> we're really not happy with it
<mdales> the respawn scrip thing mentioned above - is the syntax for that just "respawn script ... end script"?
<mdales> +t
<Keybuk> no
<Keybuk> "respawn" appears on a line on its own
<mdales> okay
<Keybuk> respawn CMD is just a (removed in bzr trunk) shortcut for "respawn\nexec CMD"
<mdales> is that the right thing to do for a respawning process that emits an event as it starts - the script will do an initctl trigger and then run the command, and I specify that script as respawn?
<mdales> okay
<Keybuk> the only difference would be that instead of running exec() on the command directly, it would exec() a shell and pipe in the script instead
<mdales> cool
<mdales> okay, many thanks for that. I now have proper dependancy on scripts
<mdales> much appreciated
<nakee> hey
<Keybuk> hi
<_ion> Hi
<nakee> upstart also replaces cron and so on?
<_ion> Not yet.
<nakee> but it suppose to be something like the daemon they have now on macosx?
<Keybuk> we're heading in that direction, yes
<Keybuk> but a little earlier in the development cycle than they are
<Keybuk> (which reminds me, the launchd never did e-mail me)
<pschulz01> Hello.. How do I enable a serial console in edgy?
<pschulz01> (Fresh install)
<Keybuk> pschulz01: try #ubuntu
<pschulz01> Keybuk: Sorry.. dev forum?
<Keybuk> Ubuntu users/support channel
<_ion> pschulz: Look at /etc/event.d/tty1, create /etc/event.d/ttyS0 just like it but modify the parameters on the "respawn" line appropriately.
<_ion> (I think)
<pschulz01> _ion: Ta.. exactly what I was after.
<pschulz01> (/etc/inittab was missing :-?)
<_ion> /etc/event.d is the Upstart equivalent of inittab.
<pschulz01> _ion: Restart required?
<Keybuk> no
<_ion> sudo initctl start jobname (where jobname is the filename, e.g. ttyS0)
<pschulz01> _ion: Wahoo!!! ta. one wyse terminal connected and talking :-)
* _ion wonders whether any hardware terminal supports UTF-8
<mdales> hmmm. I had a respawned script that did "initctrl trigger myserverstart \ /usr/bin/myserver" and all was well
<Keybuk> you'd get "started myserver" anyway
<mdales> when I added a initctrl trigger myserverstop after the myserver line the script no longer seems to stop myserver
<mdales> yes
<mdales> that was fine
<Keybuk> right, it would kill the shell script not the daemon running inside it
<Keybuk> you need to use trap to kill the daemon
<mdales> but it did that in the first case
<mdales> both cases are scripts
<Keybuk> ?
<Keybuk> can you pastebin the job?
<mdales> sure
<mdales> http://pastebin.ca/377040
<mdales> if you remove the second call to initctl it works
<mdales> anoying Xvnc doesn't dump it's pid anywhere
<Keybuk> what does it do if you remove the second initctl call?
<Keybuk> and what does it do if you don't/
<mdales> when I so a stop Xvnc will terminate
<mdales> without it it continues to run
<Keybuk> so without the second initctl line, Xvnc gets killed?
<pschulz01> How do I send upstart output to a serial console?
<Keybuk> with the second initctl line, Xvnc doesn't?
<mdales> yes
<Keybuk> pschulz01: console=/dev/ttyS0 on the kernel command-line
<Keybuk> mdales: shell behaviour, I would guess
<mdales> fair enough
<mdales> I'll add a trap handler for TERM
<mdales> I assume that otherwise that's a good way to stignal the start/stop of a service?
<mdales> it's mostly so when I do a stop comamnd it stops the thing that was started by vcnserver11 event
<mdales> +the
<mdales> I guess I could do that in the stop stanza
<mdales> anyway, once again, many thanks for your advice
<pschulz01> Keybuk: I did that... I'll have a look at it again though.. as I thought that I would be seeing more messages than what I currently am.
<Keybuk> pschulz01: in normal operation, you won't see any messages
<pschulz01> Keybuk: Ta,
<Keybuk> mdales: I don't see why you need the initctls there, though
<mdales> in you can't see why I need the events?
<mdales> of why I've put them there in particular?
<mdales> s/of/or/
<mdales> I have another script that launches another program in response to Xvnc starting/stopping
<mdales> we have some hardware thin clients that are essentially ethernet attached framebuffers. there's a program called nivo2vnc that I use to connect the Xvnc session to the thinclient
<Keybuk> mdales: right, but you get events when jobs start and stop for free
<mdales> ah, okay
<mdales> I missed that in the docs
<mdales> I'll go and reread
<Keybuk> assuming that job file is called vncserver
<Keybuk> you get a vncserver/started and vncserver/stop event
<mdales> okay
<mdales> thanks
<mdales> I need to go to a meeting now, but I'll try that when I get back
<reppel_> Keybuk: "start on started someevent" and "start on someevent/started" have the same meaming?
<Keybuk> reppel_: no
<Keybuk> they're different events, from different versions of upstart
<reppel_> i'm using 0.3.5 with "start on started event"
<reppel_> is it different in trunk or previous versions?
<Keybuk> you mean "start on started job"
<reppel_> sorry
<reppel_> yep
<Keybuk> and that's correct for 0.3.5, started is emitted when the job is running
<Keybuk> job/started is what 0.2.7 emits, at a similar, but not identical point
<reppel_> Keybuk: is it possible to run a daemon under a given uid with upstart?
<reppel_> currently i'm using su
<Keybuk> use su
<reppel_> is it a planned feature?
<Keybuk> we're planning for user jobs
<Keybuk> where a job can be registered in the name of a user, and only that user (or root) can start/stop it, etc.
<Keybuk> and the processes associated with that job are run as that user, in a full PAM session
<reppel_> ah ok
<reppel_> Keybuk: do you think feisty+1 will be purely upstart based?
<Keybuk> reppel_: I don't know, maybe
<Keybuk> feisty isn't upstart-based yet
<Keybuk> getting promoted didn't leave me enough time to do that
<mdales> are there circumstances under which respawn will stop trying to work?
<Keybuk> yes
<Keybuk> if the limit is reached
<mdales> cool
<mdales> ta
<Keybuk> respawn limit TRIES INTERVAL
<Keybuk> e.g.
<Keybuk>   respawn limit 100 10
<Keybuk> may only be restarted 100 times every 10s
<Keybuk> if it steps over that, it's stopped
<mdales> okay
<mdales> hmmm
<mdales> that's presumably over the lifetime of a system?
<Keybuk> yes
<mdales> okay
<mdales> can I set it to infinite?
<Keybuk> respawn limit 0 0
<mdales> okay
<mdales> thanks
<Keybuk> the TRIES counter is reset if INTERVAL is passed
<Keybuk> so if the 100th respawn happens more than 10s after the first one, it's not counted as a runaway job
<mdales> ah
<mdales> okay
<mdales> that's more what I want I suspect
<mdales> hmmm. still not working. I need to add some logging to find out why my child scripts aren't being launched at boot
<Keybuk> boot with --debug
<mdales> --debug on the kernel option?
<Keybuk> yeah
<mdales> will that dump to the screen or to a log file?
<Keybuk> screen
<Keybuk> you don't have a writable filesystem ;)
<mdales> ah
<mdales> hmm. okay, I suspect one thing I need to do is make my Xvnc script dependant on xfs having been started
<mdales> Xvnc struggles to start, and I'd wager xfs not being ready would be a good reason for that to happen
<_ion> Sigh, bloody ISP.
<Keybuk> :)
<Keybuk> is there any other kind?
<_ion> :-)
<mdales> is there an easy way to tie an upstart script to a rc.d event? I've been looking through the code to see if I can spot it but failed thus far to spot anything
<_ion> At least this one doesn't charge 25 /month for a static IP address and say "you can't have a server" (even though the Finnish law doesn't allow an ISP to say so).
<Keybuk> mdales: define "rc.d event"
<mdales> where do I define that? I've not seen any examples of defines. Basically I want to tie my script to the starting of xfs whcih on edgy is started in rc2.d
<mdales> apologies if I'm missing some obvious docs on this stuff
<Keybuk> no, I mean can you define "rc.d event" for me, since I don't understand what you mean
<Keybuk> the most you could do would be to start your script on rc2.d/stop
<mdales> okay
<Keybuk> or modify /etc/init.d/rc to emit upstart events
<mdales> yeah
<mdales> I was pondering that option
<mdales> but I think your idea of having it start on rc2.d/stop would work too
<mdales> and mean less messing with other scripts
<AStorm> Hello guys.
<AStorm> Any new releases? (need a new one for my liveUSB :> )
<Keybuk> what do you need a new one for? :p
<Keybuk> what's wrong with the old one?
<AStorm> Complex events?
<AStorm> Maybe I'll just use the latest bzr.
<AlexExtreme> complex-event-config is being rather complex to design ;)
<Keybuk> complex events aren't even in bzr trunk
<Keybuk> so they wouldn't appear in the next release anyway
<AStorm> Keybuk: uh...
<Keybuk> still "drafting"/"experimental"
<AStorm> Uh... ^2
<AStorm> But I can manage with current upstart too.
<AStorm> But then, any init system would work fine for that.
<Keybuk> need to finish the design of complex-events before the implementation can be released
<AStorm> Good. Hate to use unfinished and broken tools.
<Keybuk> I hate it when test cases break when I change things
<mbiebl> Keybuk: with feature freeze nearing for feisty, do you still hold on your ambitious plans of upstartifying the core system services?
<Keybuk> no
<Keybuk> they'll be optional packages instead
<AlexExtreme> IIRC feature freeze already started
<Keybuk> general advice; if you want time to do things, *don't* say yes to becoming a manager
<Keybuk> geg
<Keybuk> he
<mbiebl> turns out ComplexEventConfig was more complex than anticipated ;-)
<AlexExtreme> heh
<Keybuk> mbiebl: nah, I anticipated it would be complex
<Keybuk> I just want it to be elegant, really
<mbiebl> Well, I just noticed your hesitations (better think twice than rush it)
<mbiebl> But getting it right (which includes elegance imo) is surely more important than getting it out quickly
<Keybuk> exactly
<mbiebl> Keybuk: the vim syntax highlighting file, I wrote: where is the best place to put that?
<Keybuk> mail it to the list
<mbiebl> ok. but what about updates (new keywords etc.)
<Keybuk> if you mail it to the list, I'll stick it in bzr :)
<Keybuk> alternatively, make your own bzr branch and add it there, and I can pull
<Keybuk> contrib/ directory or something would do
<mbiebl> never worked with bzr, so I'll go with the first option ;-)
<mbiebl> but maybe a good occasion to learn about bzr...
<Keybuk> yay
<Keybuk> job->pre_start/post_start/etc. are all gone!
<Keybuk> along with job->pid
<_ion> \o/
<Keybuk> there's now a single job->process array
<Keybuk> the first five elements of which are builtin to be the default main/pre-start/etc. actions
<Keybuk> and each member has its own pid
<_ion> Nice
<Keybuk> this makes some code more sane, e.g. the child_reaper doesn't guess which process failed by the state anymore
<Keybuk> it now knows it was the post-start script :)
<Keybuk> also it makes adding custom actions really easy
<_ion> If the job has multiple instances, will they be added to the array?
<Keybuk> instances are still separate entries in the jobs hash table
<_ion> Ok
<Keybuk> I haven't disconnected the state from the configured job
<Keybuk> (yet, maybe)
<wasabi_> Keybuk: Where'd the term watershed come from?
<Keybuk> no idea
<Keybuk> it's a dictionary word
<Keybuk> things flow over the top of a watershed
<wasabi_> hmm
<wasabi_> I can't even find any CS references to it. :0
<wasabi_> Except in evms.rules. =)
<Keybuk> I doubt there are
<Keybuk> it's a geography term :p
<Keybuk> when a river reaches a watershed, the water is collected to be returned at a later time
<Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott@netsplit.com-20070301180322-inrigno2arsd68dk?start_revid=scott%40netsplit.com-20070301190545-9fdab2fn014jyx9y
<wasabi_> udev lesson: What happens when a br0 interface is added.
<wasabi_> I see 25-iftab.rules.
<wasabi_> Seems like that would invoke it.
<Md> try it: use udevmonitor and create a new bridge
<wasabi_> ooh. neat utility.
<wasabi_> Have a friend whose getting weirdness with interfaces being renamed involving bridges. I'm wondering if there's anyplace anywhere that DOESN"T rename br0 to eth*
<afancy> hi
<afancy> This channel requires that you have registered and identified yourself with the network's nickname registration services (e.g. NickServ). Please see the documentation of this network's nickname registration services that should be found in the MOTD (/motd to display it).
<afancy> I got the above msg.
<afancy> how shoud i do
<wasabi_> interesting. What makes 25-iftab rules NOT continue processing events for the interface?
<wasabi_> The interface it just renamed.
<wasabi_> Or, does it, just under the new name?
<Keybuk> wasabi: the point is that udev continues processing events under the new name
<Keybuk> there should be an IRC flag meaning "I need an operators help"
<Keybuk> and there should be a channel flag that prevents people joining the channel if they have that :p
<AlexExtreme> :p
* Keybuk sets mode #upstart -Md
<Keybuk> :p
<AlexExtreme> :P
<AlexExtreme> gotta go, cya
#upstart 2007-03-02
<Keybuk> morning
<mdales> morning Keybuk 
<mdales> thanks for your help yesterday, my system seems to be doing what I want now :)
<Keybuk> cool :) no problem
<mdales> thought I'd loiter for a bit still as I learned a bit from just watching the general chat here yesterday
<Keybuk> hmm
<Keybuk> action reload script
<Keybuk>  ...
<Keybuk> end script
<Keybuk> action reload on some-event
<Keybuk> syntax could use some work there :-/
<Keybuk> action reload
<Keybuk>   on some-event
<Keybuk>   script
<Keybuk>     ..
<Keybuk>   end script
<Keybuk> end action
<Keybuk> that might work
<_ion> Looks quite intuitive.
<Keybuk> need to sort out the job status messages first though
* Keybuk made things a wee bit more complicated :p
<Keybuk> for a given job, "foo", there may be:
<Keybuk>  - old versions running from before the config file was modified
<Keybuk>  - a master instance that never runs
<Keybuk>  - multiple running instances
<Keybuk>  - or a single instance of the job
<Keybuk> and for each instance, there may be:
<Keybuk>  - a "main stream" process (pre-start, main, post-start)
<Keybuk>  - a "side stream" process (post-start, pre-stop)
<Keybuk>  - any number of user actions
<Keybuk> start foo => obviously only cares about the master/single instance of current versions
<Keybuk> stop foo => only needs to care about single or multiple instances, but of both current and old versions
<Keybuk> status foo => probably cares about them all?
<Keybuk> this comes back to how instances are implemented
<Keybuk> right now they're just extra entries in the hash table
<Keybuk> perhaps separating all the non-config state into a JobInstance structure, and having a list of those in the job, is one way to do it
<Keybuk> *giggles*
* Keybuk finds silly bugs
<Keybuk> a deleted job can't stop
<Keybuk> because the job_change_goal() function won't let you run it for a deleted job
<AlexExtreme> heh
* Keybuk wonders if anyone will ever reach 4 billion jobs or events on a running system
* AlexExtreme highly doubts that
<mdales> AlexExtreme: we'll quote you on that in 5 years when 32 bit pids are a cause of global concern
<AlexExtreme> :D
<wasabi_> They are a cause for concern right now in my world.
<wasabi_> Heh.
<Keybuk> it doesn't matter, I've deliberately put in code to cope with it just in case
<Keybuk> that branch is sub-optimal though
<Keybuk> since once the counter wraps, it has to scan the entire jobs hash each time you want to add a new one to ensure uniqueness
<Keybuk> (there's probably a clever way to avoid that)
<wasabi_> oh, pids. n/m.
<wasabi_> for whatever reason my mind thought uid
<Keybuk> not pids
<Keybuk> the Job and EventEmission structures have a unique id field
<Keybuk> so you know *which* "foo" job, and which "block-device-added" event it is
<wasabi_> uh huh
<Keybuk> they're uint32_t, which wraps after 4 billion job file changes, or 4 billion initctl emits
<Keybuk> (or 4 billion job state changes)
<Keybuk> obviously once wrapped, job->id = job_id++ is no longer guaranteed to be unique
<wasabi_> so you need to scan before allocating.
<Keybuk> right
<Keybuk> but only once we've wrapped once
<wasabi_> store a "lowest known job id value". update it when you lease/release a number. when leasing one, use the "last known one ++" and check if it's < the lowest known. if not, do teh forward scan.
<Keybuk> the "update when release" is the tricky bit :p
<wasabi_> well you only have to update on release when release == current lowest known
<wasabi_> none of which really matters anyways.
<wasabi_> the jobs hash is going to be small enough for it to not matter.
<Keybuk> indeed
<Keybuk> and job creation isn't a time-critical activity
<Keybuk> in fact, upstart has no time critical activities :p
<wasabi_> only at boot. and that won't have looped anyways
#upstart 2007-03-03
<AStorm> Any good C programmer around?
<AStorm> I mean _damn good_.
<AStorm> cmpdir.c:125: error: invalid operands to binary &
<AStorm> line:
<AStorm>         if ((!(difftype & 5) || untrusted_size) && S_ISREG(st))
<AStorm> difftype is unsigned
<AStorm> Gah!
<AStorm> Now I've got it.
<AStorm> Wrong parameter to the macro.
<AStorm> Should be st->st_mode
<AStorm> C preprocessor is smarter than me :P
<AStorm> Can't just say "Possibly the argument 1 to macro XYZ is of invalid type", heh?
<AStorm> Macros are phun :P
<Keybuk> editing the eINIT wiki is probably cheeky ;p
* Keybuk just corrected someone's "look eINIT boots in 15s compared to sysvinit's 52s" bullshit page
<pkt> Keybuk: yeah, with a bit of kernel tweaking and UPX compression I could make a *386sx/25* boot in ~30s
<pkt> the challenge is to boot to *something useful* fast :-)
<Amaranth> funny, i thought sysvinit compatibility was a nice demo of how flexible the system was
<Amaranth> according to eINIT it's something that holds you back
<AStorm> It is, but only sometimes.
<AStorm> SysVInit is a good system, but has no dependency support.
<AStorm> And thus no parallelism.
<AStorm> A bit not scalable.
<Keybuk> but how does compatibility with that hold you back?
<Keybuk> pkt: that's the thing that concerns me about the approach of removing shell scripts in favour of C modules
<Keybuk> you throw away a lot of flexibility
<Keybuk> the point of the boot sequence being written in shell is that it's easy to change it
<pkt> Keybuk, exactly
<pkt> and especially shell scripts instead of other languages because you can also get an interactive shell if you screw up
<pkt> which is surprisingly easy in super-complex installations
<Keybuk> at some point, I'm going to get around to implementing a "UNIX Script" language that has direct access to syscalls :p
<Md> perl?
<Keybuk> true, Perl probably suffices
<AStorm> Keybuk, no, they won't remove shell scripts.
<Keybuk> "remove" ?
<AStorm> remove support :>
<AStorm> There will be a "shell" module.
<AStorm> Some other things will be also optionally in C.
<AStorm> (actually, the defaults will be in C)
<Keybuk> I'm not convinced by the whole C-vs-Shell argument anyway
<Keybuk> I can't see it making any measurable difference on desktop-class machines
<Md> what was the point of what ubuntu did to udev then? :-)
<Keybuk> which bits?
<Keybuk> the fact some of the helpers are written in C not Sh?
<Md> yes
<Keybuk> the ones we did in C had bugs which couldn't be "nicely" cured in Sh
<Keybuk> e.g. the "look at /proc/ide" one, which in Sh had a massive race condition if /proc/ide didn't turn up in time
<pkt> Keybuk, anyway you *please* only focus in correctness (as you have so far), it is much easier to add speed (at least for site-specific configurations)
<pkt> The reason I 'm keeping an eye to upstart is the typicall "root in usb disk" bug
<Keybuk> oh, don't worry; my focus right now is to get the "when a job runs" problem solved
<pkt> where with something like sysvinit you can only wait for an arbitrary time slowing down boot rediculously for other users and *still* not being correct
<pkt> yep, please stay focused on that, the other stuff is much easier
<AStorm> Keybuk, eInit is geared towards embedded, not desktop.
<Keybuk> AStorm: except their website seems to suggest they're entirely gearing it as an alternative to sysvinit and/or upstart, and that it's ideal for desktop deployment
<Keybuk> their example distribution is Gentoo
<Keybuk> etc.
<Keybuk> the eINIT *design* is perfect for embedded systems
<AStorm> :>
<Keybuk> the marketing isn't :p
<AStorm> Well, Gentoo on Arm works great.
<AStorm> :>
<AStorm> Actually, it's not Gentoo, it's a snapshot of it, crosscompiled.
<Keybuk>  29 files changed, 4515 insertions(+), 3530 deletions(-)
<Keybuk> (since 0.3.5 ... ouch; I must get more into the hang of making releases :p)
<Keybuk> trouble is, I tend to break things immediately after a release and take ages to get around to fixing them again
<AStorm> Keybuk, what about a nice test suite?
<Keybuk> AStorm: how do you mean?
<AStorm> If you know something is broken, write a test against that functionality.
<AStorm> That will remind you to fix it.
<Keybuk> have you ever looked at the upstart source code? :P
<mbiebl> iirc, that is exactly how keybuk does it ;-)
<AStorm> Keybuk, yep
<AStorm> Looks nice, clean and understandable.
<Keybuk> AStorm: ever looked in the tests sub-directory? :p
<AStorm> Nope? :P
<Keybuk> around 60% of the upstart source code is the test suite
<AStorm> I'm currently creating a new distro, so am a bit busy. :>
<Keybuk> run "make check" :p
<AStorm> Hehe.
<Keybuk> Today's problem is how to communicate the new job structure over IPC
<Keybuk> e.g. when you do "emit foo", it currently notifies you of the jobs started or stopped by that
<Keybuk> should it just say "frodo started", or should it say "frodo started, now running, pid 456"
<Keybuk> ?
<Keybuk> (likewise, if it causes an action to be run, should it say "frodo reload invoked, pid 1234" ?
<Keybuk> or should that be included in above)
<Keybuk> etc.
<AStorm> I'd suggest going for verbose output.
<AStorm> It's an internal command anyway.
<Keybuk> it's how to lay out the messages that's fun
<AStorm> Pass some nice packed struct, maybe?
<Keybuk> the trouble with packed structs is extending them later ;)
<Keybuk> ie. what happens if I add an extra field to the JobProcess struct
<AStorm> Not for you.
<Keybuk> how do older versions of initctl know to skip over that so they can find the start of the next one
<AStorm> Older versions are obsolete :P
<Keybuk> I don't agree there <g>
<Keybuk> you shouldn't have to update all your software just to update init
<AStorm> When you install upstart, you should also install up-to-date initctl
<AStorm> It's a bundle, right?
<Keybuk> and up-to-date udev, acpid, network manager, etc.?
<AStorm> Structs are for internals!
<Keybuk> how about up to date gnome services manager?
<Keybuk> ah, but the IPC isn't internal
<Keybuk> that's the point
<AStorm> Text output is for externals :>
<AStorm> Hmmmmm.
<Keybuk> it's supposed to be a stable API for other applications
<AStorm> Why use IPC and not FIFO?
<Keybuk> FIFO is a form of IPC
<AStorm> IPC for me means SysV IPC.
<Keybuk> upstart uses an abstract-domain datagram unix socket
<Keybuk> which is a kind of fifo, I guess
<Keybuk> preserves message boundaries and ordering
<mbiebl_> Keybuk: for tools like a gnome service manager, a upstart D-Bus interface would be much better imo
<Keybuk> mbiebl_: yes, that's the actual plan
<Keybuk> but then you'd have to upgrade the upstart d-bus interface :)
<Keybuk> and a console service manager might not want to use the d-bus interface, but the direct one
<mbiebl_> Sure, but the gnome program wouldn't notice
<Keybuk> if it's only a little more effort to maintain a stable API, I think it's worthwhile
<mbiebl_> Why not use D-Bus for the console too?
<mbiebl_> I don't mean, for the core tools like initctl
<Keybuk> because that introduces d-bus as a base-system dependency
<mbiebl_> but for a service manager, i thinks it'd be fine.
<Keybuk> server people won't like that
<Keybuk> you don't normally have dbus or hal on a web server
<wasabi> That's always confused me. I don't particularily care what goes on most of the servers I use. heh
<Keybuk> heh
<Keybuk> we used to be really paranoid at Demon, even removed compilers, etc. from the servers
<Keybuk> (right, my dinner's on now -- just need to keep feeding it every now and then)
<_ion> Dinner is a security hole. Viruses can attain access to the system via ingestion.
<wasabi> Most of the world doesn't particularily care, as evidenced by the rise of wIndows based servers.
<wasabi> And I mostly fall in that camp. I'd like the system to just get the job done so I can go play. =)
#upstart 2007-03-04
<urban> hi, how can i deny sshd service to start more than once?
* Keybuk has a think how "status" and "list" should work
<_ion> Well? :-)
<Keybuk> still thinking
<Keybuk> the typical problem can be defined as the "I just upgraded apache but haven't restarted it yet" one
<Keybuk> you'd have an apache job, marked for deletion, that's still running
<Keybuk> and a newer version of the apache job that's no longer running
<Keybuk> you'd want "status apache" to show them bove
<Keybuk> s/bove/both/
<Keybuk> e.g.
<Keybuk> # status apache
<Keybuk> apache (start; deleted) running, process 12345
<Keybuk> apache (stop) waiting
<Keybuk> #
<_ion> Right.
<Keybuk> in which case, that's identical to "list" :p
<_ion> Hmm
<_ion> Perhaps list should accept a search pattern, so 'list apache' as well as 'list pach' would list both of them, but 'status apache' would be guaranteed to list only zero or one entries; in that case, "apache (start; deleted) running, process 12345".
<Keybuk> so what criterion would status use to determine which one of the multiple apache jobs to return?
<_ion> The one that is running. :-) But that criterion fails if there are multiple instances running simultaneously...
<_ion> In the case of a single instance and an updated config file, the "apache (stop) waiting" would be kind of redundant information from the user's point of view, as the previous line already says "deleted".
<Keybuk> interesting
<_ion> This is just thinking out loud, i definitely haven't thought the whole thing through. :-)
<Keybuk> you can technically start the new apache without first stopping the old one
<_ion> I'm not sure that should be allowed, if the conffile doesn't allow instances.
<Keybuk> aye, not sure how to prevent that yet :p
<_ion> apache (deleted) running, apache (stop) waiting: any goal changes apply to the former, *until* it reaches the 'waiting' state. Then it vanishes and goal changes apply to the latter.
<Keybuk> what if the two have different event matches, and the event sequence for the newer one happens? :p
<_ion> Good question. :-)
<Keybuk> for instance jobs, this gets even more interesting :p
<Keybuk> for those, you probably *do* want the newer one to be the one that's started, and not the older one
<_ion> Yeah.
<_ion> "what if the two have different event matches, and the event sequence for the newer one happens?" Intuitively, i'd expect upstart to ignore that, until the running, deleted job is gone. Or can you think of a reason that would be a bad thing?
<Keybuk> instance jobs
<_ion> Yeah, i specifically meant non-instance jobs.
<Keybuk> not off-hand
<_ion> The rules would be different for instance jobs.
<Keybuk> defining a sensible set of rules is the tricky bit ;)
<_ion> Another interesting question: what happens if a job's multi-instance flag is changed :-)
<Keybuk> how can it be changed?
<_ion> I mean, the deleted conffile says 'instance' and the new one doesn't, or vice versa.
<Keybuk> the new conffile creates a new job
<Keybuk> that's kinda the point :p
<Keybuk> and why you end up with deleted jobs for the old conffile
<_ion> Yes. I mean:
<Keybuk> oh, you mean wrt instance behaviour?
<Keybuk> yes, I see your point
<_ion> If there's a rule that:
<_ion>  not 'instance': the new one can't be started if the old one is still running
<_ion>  'instance': new instances are started based on the new conffile's rules
<_ion> what to do when the 'instance' is changed :-)
<_ion> +setting
<Keybuk> *thinks*
<Keybuk> we could define the following rule
<Keybuk>  * For any job name, there is one master job that holds that name.
<Keybuk>  * That job may have multiple instances
<Keybuk>  * That job may also have a potential replacement
<Keybuk> -- 
<Keybuk> parsing a new conffile, would locate the existing job, destroy any existing replacement, and place itself as the replacement of that job
<Keybuk> it would not be a "master" until the job it replaces has been deleted
<Keybuk> instances are also not a "master" because they're an instance of another job
<Keybuk> --
<Keybuk> start, stop & status would all operate on the current master job
<Keybuk> they may also, through specific job id, operate on an instance of the job
<Keybuk> but may never operate on a replacement job while the master exists
<_ion> would stopping the master job kill all the instances?
<Keybuk> good question
<Keybuk> the above would solve the instance/not-instance problem -- whatever flag is "current" applies, and applies until the current job is gone
<_ion> Yeah.
<_ion> From the point of a daemon's postinst script, it might be best if it's certain 'stop foobard && start foobard' actually kills any instances of the old version. It might be a critical security update.
<Keybuk> yeah
<Keybuk> should sysadmins be allowed to explicitly start a replacement job by id?
<_ion> What would be an use case for that?
<Keybuk> what would be the use case for not allowing that?
<Keybuk> if they've identified it explicitly by id, should that be considered valid?
<_ion> Sorry, i'm not exactly sure what you mean by starting a replacement job by id. Is that the id of an instance?
<Keybuk> all jobs have a unique id
<Keybuk> so you can do something like
<Keybuk> # initctl list -v apache
<Keybuk> apache [#1234]  (start) running, process 12345
<Keybuk> apache [#1980]  (stop) waiting
<Keybuk> # 
<Keybuk> where the 1980 one is the "new" replacement for the other
<Keybuk> if you then did
<Keybuk> # start --id 1980
<Keybuk> should it give you an "unknown job" error, because it's not yet replaced #1234, or should it just do it since you were explicit
<_ion> I'm still thinking it should be enforced that no two apaches can be running simultaneously if it's not an 'instance' job.
<Keybuk> even though the sysadmin was clearly trying?
<Keybuk> it's easy enough to add some code to enforce that
<_ion> Yes, even though she was clearly trying. :-) But that's only my personal opinion.
<_ion> There could be an informal message, like "Please stop the deleted job before starting the new one".
<_ion> If the job doesn't specifically say 'instance', i think it's a mistake from the sysadmin to try to force multiple instances to run.
<_ion> E.g. apache: the second instance is going to try to listen on the same port, write to the same logfiles, etc.
<Keybuk> yeah
<Keybuk> ok
<Keybuk> so how about the following:
<Keybuk> a job is in the DELETED state if
<Keybuk> - it's an instance which has finished
<Keybuk> - it's a non-instance or instance-less job that has been replaced
<Keybuk> when we move a job with a replacement into the DELETED state, we unmark the replacement so it becomes the new master
<Keybuk> when finding a job by name, we never return instances or replacements
<Keybuk> we don't allow spawning an instance, changing the goal or handling events for DELETED jobs or replacements
<Keybuk> (technically we don't allow spawning an instance of instances either, but that's handled differently by redirection)
<_ion> Sounds good.
<_ion> Hmm, perhaps present the job IDs to the user in base-36? :-) '1234' would be 'ya' and '1980' would be '1j0'. They'd be shorter and perhaps even easier to remember.
<Keybuk> heh
<Keybuk> so, "start apache" would only ever start the current version
<Keybuk> it'd say unchanged if it was running, might spawn a new instance, or just start the real thing
<Keybuk> "stop apache" would stop the current version
<Keybuk> it'd say unchanged if it was running, might stop all instances, or just stop the real thing
<Keybuk> "status" apache would query the current version
<Keybuk> it might return a single status, or a list of instances with the master first
<_ion> Yeah.
<Keybuk> dunno what next door are doing
<Keybuk> lots of banging and drilling sounds
#upstart 2008-02-25
<keesj> Keybuk: for testing it would be great
#upstart 2008-02-26
<runlevel> i have added snmpd to upstart and initctl list shows the deamon but shows that it is "stop" or not started. when i try to start the deamon it starts it and then ends up stoping it. i cant seem to get this thing working. is there any good documentation. 
<runlevel> snmpd (stop) waiting
<runlevel> root@floyd:~# initctl start snmpd
<runlevel> snmpd (start) waiting
<runlevel> snmpd (start) starting
<runlevel> snmpd (start) pre-start
<runlevel> snmpd (start) spawned, process 15098
<runlevel> snmpd (start) post-start, (main) process 15098
<runlevel> snmpd (start) running, process 15098
<runlevel> root@floyd:~# ps ax | grep 15098
<runlevel> 15157 pts/0    S+     0:00 grep 15098
<runlevel> sorry i didnt mean to paste all that!!! SORRY
#upstart 2008-02-27
<sadmac> Keybuk: ping
<Keybuk> sadmac: hey. how goes it?
<asdaf> hi all
<asdaf> I have a question, does upstart 0.3.9 kill all subprocesses spawned by a process when the job is stopped?
<asdaf> from the description of bug #121733, it seems this only applies to scripts executed using the script/end script stanza
<Keybuk> asdaf: it would kill all
<Keybuk> asdaf: exec is morally equivalent to
<Keybuk>   script
<Keybuk>     exec ...
<Keybuk>   end script
<Keybuk> except that Upstart may optimise out the use of a shell if no interesting characters are used
<Keybuk> exec /bin/getty $TTY
<Keybuk> for example is absolutely identical to
<Keybuk> script
<Keybuk>   exec /bin/getty $TTY
<Keybuk> end script
<Keybuk> since it needs the shell to do the expansion of $TTY
<keesj> did somebody experiment with changing the rootfs while upstart is runing , is there a way to do this ?
<keesj> can upstart "exec" itself away?
<Keybuk> sure
<keesj> What a long aswer :p
<sadmac> Keybuk: have you had any thoughts on logd and a way of making it work?
#upstart 2008-02-28
<sadmac> Keybuk: how do I build upstart from bzr (0.3 branch)
<sadmac> Keybuk: (automake is not being friendly)
<sadmac_> Keybuk: I'm still getting errors from autoreconf.
<sadmac_> Keybuk: Makefile.am:3: required directory ./intl does not exist
<Keybuk> sadmac_: what errors do you get?
<Keybuk> what version of gettext do you have?
<sadmac_> Keybuk: 0.16.1-12.fc8
<Keybuk> hmm
<Keybuk> that should work
<sadmac_> I get these first:
<sadmac_> configure.ac:14: required file `./config.rpath' not found
<sadmac_> configure.ac:42: required file `intl/Makefile.in' not found
<sadmac_> configure.ac:14: required file `./ABOUT-NLS' not found
<sadmac_> configure.ac:19: required file `./ltmain.sh' not found
<Keybuk> oh
<Keybuk> autoreconf -i :-)
<sadmac_> ahh
<sadmac_> now I can configure it :)
<sadmac_> If it doesn't make it'll be my fault
<Keybuk> hehe
<sadmac_> Keybuk: I get this when I try to make
<sadmac_> make[2]: *** No rule to make target `../m4/codeset.m4', needed by `Makefile.in'.  Stop.
<Keybuk> gnargh
<Keybuk> try a fresh checkout
<Keybuk> autoreconf -i
<Keybuk> and go again
<Keybuk> that should have come from gettext
<keesj> hi
<keesj> I am trying to run a simple console like init does "-/bin/sh"
<keesj> but that does not work
<sadmac_> Keybuk: still same issue
<keesj> I am booting from from a serial (qemu)
<keesj> any tips?
<Keybuk> sadmac_: it could be a bug without gettext packages?  have you tried an unpatched version?
<sadmac_> Keybuk: I didn't do anything to the new checkout before I built it. Its all branch code.
<Keybuk> right
<Keybuk> but the error you're getting is from the gettext Makefile.in I assume?
<Keybuk> about a missing gettext file in m4?
<Keybuk> ...
<Keybuk> which version of automake do you have?
<sadmac_> 1.10-6.fc8
<Keybuk> after running autoreconf
<Keybuk> what does ls m4 say?
<sadmac_> Keybuk: http://rafb.net/p/R9QjbO65.html
<Keybuk> weird
<Keybuk> it *has* codeset.m4
<Keybuk> that's not a symlink, right?
<sadmac_> nope
<Keybuk> can you paste the "make" output?
<sadmac_> k
<mbiebl> sadmac_: does it help if you create a directory build
<mbiebl> cd build && ../configure && make
<Keybuk> it does?
<mbiebl> Keybuk: I noticed that before myself.
<mbiebl> It's somehow a result of the nihify scripts which uses symlinks.
<sadmac_> I'm having trouble reproducing it now
<Keybuk> ahhh
<Keybuk> you need to run "autoreconf -i" in *both* libnih and upstart directories
<sadmac_> Keybuk: that'd do it
<Keybuk> http://upstart.ubuntu.com/wiki/CompilingUpstart?highlight=(CategoryTemplate)|(CategoryDoc)|(CategoryCategory)|(DocTemplate)|(FrontPage)|((CategoryDoc))
<Keybuk> err
<Keybuk> http://upstart.ubuntu.com/wiki/CompilingUpstart
<Keybuk> probably configure too
<Keybuk> it's a bit of hack really
<sadmac_> yeah :)
<sadmac_> Ahh, I'm getting gcc lines now...
<sadmac_> compile error.
<sadmac_> hmm...
<Keybuk> heh
<Keybuk> don't think there should be any of those in trunk
<Keybuk> what is it?
<sadmac_> main.c:242: error: incompatible type for argument 3 of ânih_child_add_watchâ
<sadmac_> main.c:242: error: too few arguments to function ânih_child_add_watchâ
<Keybuk> which version of libnih?
<sadmac_> Keybuk: trunk (only branch I saw, do I need to roll back?
<Keybuk> no...
<Keybuk> what main.c is that?
<sadmac_> init
<Keybuk> which revno of upstart?
<Keybuk> line 242 isn't nih_child_add_watch for me
<sadmac_> Keybuk: head of the 0.3 branch
<Keybuk> ahhhhhh
<Keybuk> yeah, you'll need to rollback libnih
<Keybuk> that's just 0.3.9 isn't it?
<sadmac_> I'd assume (first time bzr user :)
<sadmac_> I actually have a software engineering lab to get to (the university is still persistent in their efforts to teach me Java) but I'll pick this up later.
<Keybuk> ok
<Keybuk> revno 426 seems to be about right
<Keybuk> bzr uncommit -r 426
<Keybuk> bzr revert --no-backup
<Keybuk> (I think)
<mbiebl> Keybuk: when will initctl (and the sysv compat tools) be back in trunk?
<Keybuk> mbiebl: err, now + some time + a bit more
<mbiebl> Keybuk: ;-)
<Keybuk> you could write a patch ... :p
#upstart 2008-02-29
<Keybuk> sadmac: Bill is using emit in a very strange way in #435368
<sadmac_> Keybuk: what's the issue?
<Keybuk> is it just a minimal test case that demonstrates the bug?
<Keybuk> ie. why are you using emit?
<sadmac_> exactly, just a test case
<sadmac_> the point is a job started by an event with arguments doesn't get those arguments again when restarted
<Keybuk> true...
<Keybuk> but since events don't even *have* arguments anymore in trunk
<Keybuk> and even while they still did, they weren't passed to the job anyway ...
<Keybuk> it's kinda a null test case :p
<Keybuk> it's certainly a bug in 0.3 that the associated event information is lost for services once they're running, so not available after the respawn - that is fixed in trunk
<sadmac_> Ah cool
<Keybuk> the trunk equivalent would be something like:
<Keybuk>   initctl emit foo DEV=bar PATH=baz
<Keybuk> and then you'd use $DEV and $PATH in the script
<Keybuk> and they survive respawn
<Keybuk> until a different event starts the job
<Keybuk> or you change them with start
<Keybuk> ie.
<Keybuk>   initctl start jobname DEV=wibble PATH=wobble
<sadmac_> cool
<sadmac_> Keybuk: have you had any thoughts on lod and making it work?
<Keybuk> lod?
<sadmac_> s/lod/logd/
<Keybuk> not really
<Keybuk> the only thing I've come up with would be making logd have a pty
<Keybuk> and telling upstart to divert output from jobs to that pty while running
<Keybuk> that doesn't fix logd dying though
<Keybuk> so has the same basic problems as the socket
<sadmac_> hm
<sadmac_> Keybuk: you could have upstart itself hold a pipe to each program, and then just bridge it through sunrpc to logd (since sunrpc has that lovely property of just sitting and buffering when the listener goes away)
<Keybuk> interesting
<Keybuk> would you need the bridge in that instance?
<sadmac_> the one big limitation of sunrpc is it has a custom interface (no file descriptors) so you can't just bolt it right onto stdio
<sadmac_> so yes
<Keybuk> ah
<sadmac_> oh, not sunrpc
<sadmac_> sunipc
<sadmac_> or sun ipc
<Keybuk> lol
<Keybuk> the problem with the bootlogd approach, btw (stealing console output via ioctl) is it doesn't work with our usplash
<Keybuk> and I suspect it wouldn't work with your X rhgb either
<Keybuk> since both *change* the console to be a graphical one, with text diverted elsewhere
<sadmac_> you could alter usplash of course. (I may rewrite rhgb once we get off the ground. right now I'm patching some stuff into upstart to deal with it)
<Keybuk> it isn't usplash that's the problem
<Keybuk> it's svgalib
<Keybuk> and I want to fiddle with that about as much as I want to wake up without my kidneys
<sadmac_> ah
<sadmac_> Keybuk: it looked like in trunk the event files had moved, is this the case?
<Keybuk> event files?
<sadmac_> /etc/event.d/*
<Keybuk> possibly moving to /etc/init/jobs.d
<sadmac_> yeah, any particular reason?
<Keybuk> to stop people calling them "event files" :)
<Keybuk> since they're not
<Keybuk> they're job files
<Keybuk> jobs and events are different things
<Keybuk> but everyone confuses the two because of the directory name
<sadmac_> ah.
<Keybuk> e.g. people think that if you have /etc/event.d/foo
<Keybuk> then initctl emit foo will start it
<sadmac_> yeah.
<Keybuk> which isn't true at all
<sadmac_> Keybuk: one more correction, it wasn't sun ipc. it was sysv.
 * sadmac_ should drink coffee while reading things
<sadmac_> specifically message queues
#upstart 2008-03-01
<charliecb> hi
<charliecb> i have a question: is it possible to have an event in upstart when a file changes?
<charliecb> something like: if file test.txt changes, do something...
<Keybuk> Pushed up to revision 486.
<Keybuk> I want my bzr commit animations plugin :'(
<Keybuk> on special numbers, it should do silly things
<Keybuk> e.g. that should play http://www.uspto.gov/go/kids/soundex/75332744.mp3
<ion_> 68000
<ion_> That would be a nice revision.
<Keybuk> I haven't even got to 1,000 yet
 * sadmac is waiting for over 9000
<Keybuk> 9000?
<sadmac> Keybuk: http://youtube.com/watch?v=TBtpyeLxVkI
<Keybuk> lol
<ion_> Some people shouldnât be given video editing software. :-)
<Keybuk> hurrah
<Keybuk> now given
<Keybuk> start on ((foo and bar) or (frodo and bilbo)
<Keybuk> if the foo, bar and frodo happen - the job will start
<Keybuk> (ok so far)
<Keybuk> but now, the job will only have environment from foo and bar
<Keybuk> since frodo is irrelevant :p
#upstart 2008-03-02
<ion_> Alright
<Keybuk> which seems reasonable
<sadmac> Keybuk: still looking for a new name for the "on" stanza?
<Keybuk> sadmac: potentially
<sadmac> Keybuk: I was thinking "when"
<Keybuk> and what would be the opposite?
<sadmac> Keybuk: when not?
<Keybuk> that's a bit ... odd :)
<Keybuk> especially since the following bits would be true :P
<Keybuk>   when started gdm
<Keybuk>   when not stopping gdm
<Keybuk> (except it's stopped *when* stopping gdm)
<sadmac> Oh, I thought on syntax did that all in one stanza
<sadmac> when started gdm until stopping gdm
<sadmac> but on that note, unti'
<sadmac> s/unti'/until/
<Keybuk> that syntax got dropped a while back
<Keybuk> the "until" operator's semantics got crazy
<sadmac> ah
<Keybuk> current front-runner is three stanzas
<Keybuk> "from" (morally equivalent to "start on")
<Keybuk> "until" (morally equivalent to "stop on")
<Keybuk> "when" (state matching)
<Keybuk> so, something like
<Keybuk>   from tty-added
<Keybuk>   until tty-removed $TTY
<Keybuk>   while multiuser
<Keybuk> (err, s/"when"/"while"/ :p)
<sadmac> so can you pair them explicitly?
<Keybuk> I think so
<sadmac> from a \n until b \n from c \n until d   Where if it starts on a it won't stop on d
<Keybuk> no
<Keybuk> you can't do that
<sadmac> hmm
<sadmac> how do the multi-instance jobs work then?
<sadmac> I guess that's more environment though
<Keybuk> example?
<sadmac> from some_tty starts
<sadmac> until that_specific_tty_that_started_me_stops
<Keybuk> right
<Keybuk> so you'd match that using environment
<Keybuk> from tty-up
<Keybuk> until tty-down $TTY
<Keybuk> the tty-up event carries TTY=tty1 as an environment payload
<Keybuk> that gets added to the jobs own environment while it's running
<Keybuk> (in fact, for getty, that would probably be the way unique instances are determined)
<Keybuk> because it will be in the environment of the job, the job can match against it in its own definitions
<Keybuk> so thus:
<Keybuk>   until tty-down $TTY
<sadmac> I also wanted to know how you have jobs become able to be started on events without starting them
<sadmac> I.e. `start job_x` fails
<sadmac> I plug in a smart card, nothing results directly from this
<sadmac> but while the smart card is in, `start job_x` succeeds
<sadmac> so basically "this job can only be run while in state X, but it doesn't have to be running in said state"
<Keybuk> means match the TTY variable from the tty-down event to the $TTY variable in the job
<Keybuk> you'd use states for that, maybe
<Keybuk> I'm not sure how much preventing the sysadmin from doing stuff we want to do
<Keybuk> I think I'm generally inclined to think if a sysadmin tries to start job_x, even while there's no smart card in, it should let them
<Keybuk> and obviously job_x will fail and give them meaningful error messages
<Keybuk> (ie. the daemon started will fail)
<sadmac> true
<Keybuk> obviously Upstart should never attempt to start it automatically
<sadmac> cool
<Keybuk> a more interesting question is if you start a job manually, should Upstart ever stop it automatically? :)
<sadmac> This does bring up a point about the flags/profiles things. Usually we want to prevent a service from coming up automatically, but if after loading the profile the admin decides to start one manually himself, we should let him
<Keybuk> right
<sadmac> Ok, might be more of a unix API question, unless nih has something I don't know about, but how would I change upstart init's tty from within the source code?
<Keybuk> how do you mean?
<sadmac> Like make nih_info/error/whatever and the stdout of 'console output' services route to /dev/some/specific/tty
<Keybuk> easiest way would be just to change upstart's own console
<Keybuk> ie in init/main.c
<sadmac> yeah, having trouble getting unix to do that for me.
<Keybuk> don't you just change it? :p
<sadmac> Right now I'm sending TIOCNOTTY to /dev/tty, and then open()ing the new tty, which should do it.
<Keybuk> do you even *have* /dev/tty at that point? :)
<Keybuk> on a udev-based system, you only generally have /dev/console and maybe /dev/null when init starts
<sadmac> hmm.
<sadmac> I should add that I want this to happen dynamically, and to revert the change later (I've got the revert thing figured out, if I can just change it in the first place)
<Keybuk> without knowing much more about Fedora, I'm not sure I can help :-/
<Keybuk> certainly on Ubuntu, nothing other than /dev/console exists when init starts
<sadmac> well my current technique isn't working even when I'm testing it (well after udev starts)
<Keybuk> what's taht?
<sadmac> after the TIOCNOTTY and the change, its still logging to the same place
<Keybuk> that could be syslog() doing that
<sadmac> basically I have an initctl push_tty /dev/something and an initctl pop_tty command. They appear to work, but logging behavior doesn't actually change.
<Keybuk> upstart's own log output?
<Keybuk> or the output of jobs?
<sadmac> upstart's own
<Keybuk> that's probably syslog doing that then
<sadmac> ahh, so nih_info outputs to syslog?
<Keybuk> does commenting out the openlog() and nih_log_set_logger() calls help?
<Keybuk> (then it'll just use printf)
<sadmac> I'll try that
<sadmac> In fact I should set up a test job to do things with actual job output
 * Keybuk yawns
<Keybuk> too damned windy again today
* Keybuk changed the topic of #upstart to: Upstart 0.3.9 | http://upstart.ubuntu.com/ | http://irclogs.ubuntu.com/ | https://lists.ubuntu.com/archives/upstart-devel/2007-October/000468.html | http://upstart.ubuntu.com/wiki/OutstandingIssues
* Keybuk changed the topic of #upstart to: Upstart 0.3.9 | http://upstart.ubuntu.com/ | http://irclogs.ubuntu.com/ | https://lists.ubuntu.com/archives/upstart-devel/2007-October/000468.html https://lists.ubuntu.com/archives/upstart-devel/2008-January/000573.html | http://upstart.ubuntu.com/wiki/OutstandingIssues
<Keybuk> dear valgrind, please exit 1 if you find an error, kthxbye
<ion_> Heh
<Keybuk> hurrah
<Keybuk> job->start_on is no more
<Keybuk> start and the resulting environment are now atomic
<Keybuk> so if you "start getty TTY=1"
<Keybuk> and then do "stop --id 123; start --id 123 TTY=2"
<Keybuk> the stop scripts will still have $TTY=1
<Keybuk> and won't get $TTY=2 until it restarts
<ion_> Neat.
<Keybuk> do you think it matters why a job is stopped?
<Keybuk> I'm thinking of only making the stop event environment available to the pre-stop script
<Keybuk> since that script can decide to start the job again without killing the running process
<Keybuk> I don't think post-stop should get the environment, since it shouldn't care ?
<ion_> Mm... I canât think of any use cases immediately.
<ion_> A post-stop script might e.g. want to send email based on the jobâs exit value, or something.
<Keybuk> it should do that by hooking the stopped event ;)
<ion_> Good point. :-)
<Keybuk> let me dump my thoughts here
<Keybuk>   start on foo or bar
<Keybuk>   stop on wibble or wibble
<Keybuk>   ... some job
<Keybuk> initctl emit foo
<Keybuk> job goal changed from stop to start
<Keybuk> job state changed from waiting to starting
<Keybuk> job state changed from starting to pre-start
<Keybuk>   (pre-start run with UPSTART_EVENTS=foo)
<Keybuk> job state changed from pre-start to spawned
<Keybuk>   (main process with UPSTART_EVENTS=foo)
<Keybuk> job state changed from pre-start to post-stop
<Keybuk> (err, start)
<Keybuk> job state changed from post-start to running
<Keybuk> ok
<Keybuk> so the job is running, and the environment remained the same
<Keybuk> now do
<Keybuk> initctl emit wibble
<Keybuk> job state changed from running to pre-stop
<Keybuk>   (pre-stop run with UPSTART_STOP_EVENTS=wibble)
<Keybuk> job state changed from pre-stop to stopping
<Keybuk> now:
<Keybuk> initctl emit bar
<Keybuk> job goal changed from start to stop
<Keybuk> initctl emit wobble
<ion_> Donât you mean from stop to start?
<Keybuk> yes, sorry
<Keybuk> missed a line :p
<Keybuk> job goal changed from start to stop
<Keybuk> we're still in the right line here, we were just blocking on our stopping event
<Keybuk> so we're going to continue towards death
<Keybuk> job state changed from stopping to killed
<Keybuk>   (kill the main process)
<Keybuk> job state changed from killed to post-stop
<Keybuk>   (post-run run with UPSTART_STOP_EVENTS= ... errr...)
<Keybuk> ie.
<Keybuk> if we attempt to run the post-stop with the environment from the stop events, that will be "wobble"
<Keybuk> yet pre-stop was run with "wibble"
<ion_> Yep...
<Keybuk> which is wrong :)
<Keybuk> if script A, B and C are run with one set of environmen
<Keybuk> so should script D
<ion_> Yep
<Keybuk> the reason we don't have this problem on start events is because we can always run through stop first
<Keybuk> so we have the notion of the "next" start environment
<Keybuk> wherever we are in the cycle, we can skip running and run through the whole thing again, and switch over the environment next time we pass through starting
<Keybuk> this isn't bad, since it appears like a restart, which given a stop/start sequence is exactly what you'd expect
<Keybuk> for stop, we don't really want to run through start again, just so we can stop it again :)
<Keybuk> especially if we know the stop event/state/etc. has already happened
<ion_> Aye
<Keybuk> so that's my rationale for why only pre-stop should see the environment of the stop events
<ion_> I donât see a reason to disagree.
<Keybuk> in a sensible job, the stop events should be balanced by the start events
<Keybuk> so if you have tty-added...tty-removed as a pair, you can see tty-added in the post-stop script so assume that it was tty-removed that caused you to be stopped
#upstart 2009-02-23
<MarcWeber> Does it make sense to you introducing init --expected-pid=2 ? Why? I'm trying to run nixos on a vserver. I can't replace the default init so I have to run upstart using PID 2. Of course I can patch those two lines. But maybe other people do have this problem as well ?
<Keybuk> Upstart depends on being pid 1
<Keybuk> and it expects the special behaviour afforded that process by the kernel
<MarcWeber> That's bad news. the vserver even starts without /sbin/init.. So I can't change that so I can't use upstart without heavy patching?
<MarcWeber> Keybuk: can you estimate the amount of work required to make this possible? I mean a PID 2 should be able to run jobs as well. (Maybe its killed by PID3 .. I think I must live with that..)
<MarcWeber> Maybe the solution is to try yet another hosting provider..
<Keybuk> pid 2 would not have daemon process children reparented to it
<Keybuk> which has always been a specific goal of upstart's to support
<MarcWeber> Hmm I think I have to dive into some documentation first to understand that.
<Keybuk> why can you not replace the existing pid #1 ?
<MarcWeber> Cause I don't have control over pid #1. All it seems I can do is providing runlevel code. And thats pid > 1. But can send another ticket to clarify that..
<Keybuk> why don't you have control over it?
<MarcWeber> because cat /proc/1/exe  results in permission denied. I don't where the file is. It's a virtual server.
<MarcWeber> Or do you have any idea how to find the location other then find . -name "init" (which showed only /sbin/init which isn't executed at all)
<MarcWeber> If a process starts another doesn't the kernel setup a parent -> child relation automatically?
<Keybuk> surely you have control over the distribution you installed?
<MarcWeber> Keybuk All files but /dev/* I can't mknod
<MarcWeber> I can start a repair system. This way I can access /vserver containing all files.
<Keybuk> you're a nixos developer?
<MarcWeber> When do you call somone a developer? I've been a contributor for over a year now. I haven't written much of the core C(++) code though.
<MarcWeber> And we already talked about a similar problem a year ago. That time I tried setting up upstart-0.5. I had to patch it cause the other hosting used a kernel not providing a feature..
<Keybuk> are you attempting to replace sysvinit in nixos with Upstart?
<MarcWeber> nixos has been using upstart-0.3 for years
<Keybuk> and when installed into a vserver, its pid isn't 1?
<MarcWeber> Eelco (core developper) told me he wants to start an upstart-0.5.1 branch now
<MarcWeber> I don't know how to tell the vserver to run upstart at all :-(
<Keybuk> :-/
 * Keybuk has heard of problems with vserver before
<Keybuk> I've had arguments with vserver upstream in fact
<Keybuk> over things like vserver failing to provide init with the special signal handling it expects
<Keybuk> which suggests that you can run upstart as init/pid #1 in a vserver
<MarcWeber> Keybuk: Can you tell me briefly why I want this reparenting or can you give me some keywords so that I can google it up?
<Keybuk> MarcWeber: supervision of daemon processes
<MarcWeber> The first hosting provider lets me use /sbin/init. The trouble is that I can't use recent coreutils. That means that all software packages hashes would change. This means I can neither use nor provide binary packages.. So I know that some vservers can use #1.
<MarcWeber> Reparenting = if a daemon dies its subprocesses are reparented to be direct childs of init so that init (upstart) can kill them ?
<Keybuk> exactly
<Keybuk> and more to the point
<Keybuk> so init (upstart) is notified when they die
<MarcWeber> So that it can restart the process. looking out wether a pid 10 still exists won't work cause the kernel might have given pid 10 to another process ?
<Keybuk> no, more than that
<Keybuk> upstart will never know that pid 10 has exited
<MarcWeber> It could try to find pid 10 10 times a sec..
<sadmac2> eew.
<MarcWeber> But that's no option.
<MarcWeber> So I'll look for yet another hosting service..
<sadmac2> Keybuk: I have a good chunk of a replace-nih-config-with-bison patch. Its pretty ratty but worth a guided tour. How long will you be around today?
<Keybuk> today is not a good day
<sadmac2> rgr
<MarcWeber> What's wrong with waitpid to get notified when a child terminates?
<sadmac2> MarcWeber: only tells you /your/ children. we need to know about the /daemon/'s children. grandkids
<MarcWeber> Ok. Then I was right.
<Keybuk> sadmac2: ok, let's look at your patch ;)
<sadmac2> Keybuk: err... its kind of at home and in pieces. I was hoping to do it in about an hour :)
<Keybuk> can I tell you my mad idea first?
<sadmac2> ghead
<sadmac2> Keybuk: still here?
<Keybuk> yup
<Keybuk> so you know how "initctl start" and "initctl stop" are just commands that muck around with the job state directly
<Keybuk> what if they weren't?
<Keybuk> by that I mean
<Keybuk> if I do "stop somejob", the job stops
<Keybuk> and if I reboot
<Keybuk> the job is still stopped
<Keybuk> and if I do "start someotherjob" to make a new copy
<Keybuk> when I reboot, that is started again
<sadmac2> Keybuk: how do you handle single user mode?
<Keybuk> no plans there
<sadmac2> I think you might be having those "neat when everything's running normally" type ideas. Hard to bootstrap, hard to deal with in an inconsistent state.
<sadmac2> Keybuk: actually, it could work.
<sadmac2> Keybuk: so things like single user mode would be done by just specifying which set of enabled services you want on the command line (out of a series of configured choices). start/stop would affect whichever was active
<sadmac2> so its just a matter of making /etc/init/enabled_services_foo-mode /var/lib/*/enabled_services_foo-mode
<Keybuk> well
<Keybuk> that's basically what I was thinking
<Keybuk> start <instance> would add a file in /var/lib/init that morally said that the particular instance should be auto-started
<Keybuk> (assumedly it was manual before)
<Keybuk> stop <instance> would add a file saying that it should not be auto-started
<Keybuk> start <creating a new instance> would create a new job file in /var/lib/init for the new instance, specifying the conditions in which it runs (from the cmdline)
<sadmac2> I assume one would add and one would remove :)
<MarcWeber> What actually happens when a child of a daemon exits?
<sadmac2> MarcWeber: if the daemon is still running, then nothing.
<sadmac2> MarcWeber: if the daemon dies, then its children get inherited by pid 1 (always pid 1, whatever that may be).
<MarcWeber> sadmac2: Example: mysqld dies but has still one serving process. What should happen? (same for apache or such)
<MarcWeber> of course the daemon should be restarted.
<sadmac2> MarcWeber: they get reparented to pid 1, which may then wait on them
<MarcWeber> When does upstart get to know about them? Whet those daemon child processes are created or when the daemon dies?
<MarcWeber> I'm trying to figure out wether I neet this upstart feature or not. I mean a lot of distributions still do use a traditional init..
<sadmac2> at the moment never :) upstart just sees them as wayward userspace processes when it inherits them. Working with kernel folks on a solution (0.5.* uses ptrace to monitor the daemon as it runs and capture its calls to fork() thus finding out that way)
<sadmac2> a service is considered dead by upstart when it has no more processes.
<MarcWeber> so a traditional init does restart services to early.
<sadmac2> a traditional init doesn't restart them at all :)
<sadmac2> well it can, but for most larger things it doesn't
<MarcWeber> sadmac2: I've tried it. apache is not restarted if you kill it. However writing a wget /curl cron job test running apachectl {stop,start} would take me less than a minute.
<sadmac> Keybuk: I'm at home now. still interested in this code/having mad ideas?
<Keybuk> sadmac: sure
<sadmac> Keybuk: http://sadmac.fedorapeople.org/parse_job.y
<sadmac> I don't seem to have the ignore rules right to get it to not look at generated files and otherwise do what it should, but basically that replaces parse_job.c
<sadmac> then we get some makefile.am changes and some changes to the test cases to account for the slightly altered error reporting.
<Keybuk> slightly altered?
<sadmac> most errors end up turning into UNEXPECTED_TOKEN the way things are written. This can change though.
<sadmac> (unfortunate part about that error, when isn't it true?)
<Keybuk> right, I think I ran across that before with bison
<Keybuk> I notice you're having token issues there
<Keybuk> isn't it normal to use flex to write the lexer/tokeniser then pass that to bison?
<sadmac> I kinda figured the lexer would be too simple to bother. Oops. :)
<Keybuk> is there any bits of syntax that are "hard" to do this wya?
<sadmac> context-sensitive keywords
<Keybuk> how so?
<sadmac> for example, with nih_config "start on start" is valid. the second start isn't a keyword anymore, it becomes an event name.
<Keybuk> isn't that just
<sadmac> its very doable, the problem is it can't be done categorically. every keyword needs a (one line) mention that it promotes to string when asked.
<Keybuk> start_on := "start" "on" EVENTTREE
<Keybuk> EVENTTREE := "event" | EVENTTREE "or" EVENTTREE | EVENTTREE "and" EVENTTREE
<sadmac> the other thing that was hard was allowing event operators to have linebreaks BUT only inside parenthesis. My solution to that isn't final
<Keybuk> err s/"event"/EVENT/
<Keybuk> EVENT := NAME ARG*
<Keybuk> heh, pythonic parens ;)
<Keybuk> randomly
<Keybuk> it's probably quite easy to parse the syntax in lua ;)
<sadmac> ugh. lua is scary.
<sadmac> that doesn't solve it
<sadmac> what type is NAME?
<Keybuk> that's a type
<sadmac> when you say "start" in bison, you declare a new type. a token with name "start" is of type "start"
<Keybuk> it can be a bare word, or a single or double-quoted string
<Keybuk> ARG is the same
<sadmac> so what we
<sadmac> what we'd need is a line like this
<sadmac> STR := LITERAL_TOKEN | "start" { $$ = "start" } | "on" { $$ = "on" } | "stop".....
<sadmac> the easier, and better option is to just say "keywords are keywords" and make users quote them.
<Keybuk> how do you mean?
<sadmac> start on start --> syntax error
<sadmac> start on "start" --> ok
<Keybuk> that third one can't be start
<Keybuk> it's not at the start of a line
<Keybuk> keywords only appear at the beginning of a line
<sadmac> Keybuk: the problem is the type
<sadmac> Keybuk: when "start" appears in the bison grammar, that isn't a string
<sadmac> that is a "start".
<sadmac> its its own type
<Keybuk> surely type depends on context?
<sadmac> not for tokens
<sadmac> not for the output of the lexer
<sadmac> you can create the hierarchy, but its a lot of text.
<sadmac> because each keyword is a different type. There's no way to apply the promotion to them categorically.
<sadmac> remember, when the lexer sees "start" it has to decide what type it is
<Keybuk> that sucks ;)
<sadmac> and the lexer doesn't maintain state other than file position. it has no idea what came before
<sadmac> Keybuk: it does... but then I could put that in and several other things and all this would still be less code than the old parse_job.c. AND there'd be no more nih_config
<Keybuk> what's the difference in resulting code though?
<Keybuk> and any difference in speed?
<sadmac> didn't look in difference in resulting code. speed seems uncanny. tests run faster than my terminal can write the results.
<sadmac> the resulting code isn't that interesting here, since you never read it. they put in all the #line macros so the errors are reported against the original .y
#upstart 2009-02-24
<sadmac> Keybuk: any other thoughts?
<Keybuk> not offhand
<sadmac> Keybuk: should I keep plowing on this or go back to fiddling with 0.10 features?
<Keybuk> which 0.10 features were you thinking of?
<sadmac> Keybuk: I started from the top. was ripping out start on and stop on in favor of just plain ol' on.
<sadmac> which got me thinking about this because changing the config file format was miserable.
<Keybuk> on is something quite specific though
<sadmac> its the biggest leap toward 0.10 though because its changes are most destructive. There's more bits coming off.
<Keybuk> I'd say that the most destructive will be reorganising the jobs/instances stuff
<sadmac> that's not really destructive as much as additive
<sadmac> if you remove start on/stop on you've removed the mechanism that automatically starts and stops jobs.
<sadmac> Then you just have to replace it.
<Keybuk> I don't agree
<Keybuk> I intend to change the very meaning of start and stop
<Keybuk> and since the ideas haven't been written down yet
<Keybuk> it's far too early to jump in and start recoding things
<sadmac> what are these changes?
<Keybuk> the idea that instances are created automatically
<Keybuk> based on the while condition and matching instances there
<Keybuk> start/stop simply change an existing instance - never create them
<sadmac> that's still not much change. All that means is "kill job_class_start"
<Keybuk> I think it's a fundamental change
<Keybuk> I know you're eager to get coding on things
<Keybuk> but right now, I can't honestly think of any particular bits that need changing ye
 * Keybuk prefers to write things down before starting
<sadmac> You English and your native tongue. I have no use for anything written down in such an overcomplicated language. C is a much better way of expressing ideas :)
<Keybuk> no, blasting in and rewriting things is a very good way to get yourself in a mess
<sadmac> the mess is leftovers from the early stages. that comes from not blasting hard enough :)
<Keybuk> ?
<sadmac> nothing wrong with blasting and rewriting if you commit.
<sadmac> don't get attached to the old code. and don't wait. don't let a function sit 5 minutes past its interface mildly annoying you.
<sadmac> Keybuk: do you leave 1 or 2 lines between functions? It seems to vary throughout the code
<Keybuk> depends on the relationship between the functions
<Keybuk> 1 line if the functions are realted
<Keybuk> 2 if not
<sadmac> ah
<hettar> Silly question but are the *buntus going to start adding more standard upstart events ?
<ion_> After Upstart 0.10
<hettar> for instance it would be nice if there were some like "suspend-started" or "resume-finished" etc
<hettar> hmm when is that ?
<ion_> As soon as itâs ready. ;-)
<hettar> will that be for koala or whatever it is called ?
<hettar> fair enough
<ion_> Dunno
<hettar> Whats happening for 0.10 that standard events need to wait for it ?
<ion_> It will implement enough functionality for the entire system to boot with native jobs. As soon as that point is reached, thereâs incentive to think of âstandard eventsâ.
<ion_> (and standard states)
<hettar> Sounds good. thanks for the info. I'll just keep implementing my own events until then :)
 * Keybuk has working daemon supervision now
<sadmac2> Keybuk: what'd you do?
<Keybuk> magic stuff
<sadmac2> Keybuk: its bad for your sceptum to do that stuff
<sadmac2> tracing a trace program is hard.
<keesj> keesj: the Linux Journal had a piece about you and the fork/ptrace stuff in the "wat's up on kernel front"
<sadmac2> keesj: stop talking to yourself.
<keesj> :p
<keesj> oops
<sadmac2> Keybuk: what kind of magic?
<ion_> O hai, ion_
<sadmac2> sadmac: greetings from your work self, home self!
 * sadmac2 heads to class
<Keybuk> sadmac2: dark magic
<Keybuk> keesj: got a link?
<keesj> searching..
<keesj> failed: scanning...
<keesj> Keybuk: http://box.mmapps.net/lm_100_upstart/ where 003 is the part I was talking about
#upstart 2009-02-25
<Keybuk> quest procwatch% sudo ./forkwatch
<Keybuk> 16484 -> 19420
<Keybuk> 19420 -> 19421
<Keybuk> 19421 -> 19422
<Keybuk> (daemonising process being watched)
<sadmac> Keybuk: how?
<Keybuk> darkest magic ;)
<sadmac> Keybuk: open source??
<Keybuk> obviously
<sadmac> Keybuk: url then?
<Keybuk> no url
<Keybuk> just on my machine
<sadmac> I don't believe you then X:(
<sadmac> whoa, I waay mistyped that smilie
<sadmac> he's gonna have to go to a special school
<Keybuk> which bit don't you believe? :p
<sadmac> You didn't do the forking! Code or GTFO!
<sadmac> </4chan>
<Keybuk> the code of forkwatch won't look that interesting to you
<Keybuk> it opens a netlink socket and listens on it
<Keybuk> reading the messages containing the parent and child pids
<sadmac> my lkml dump doesn't have anything interesting from you...
<sadmac> Keybuk: did you look into pjones' suggestion of just "write a utrace module?"
<Keybuk> yes
<Keybuk> I also looked into other people's suggestions as well of interesting ways to do it
<Keybuk> and when I got to the bit of the kernel which I had to modify
<Keybuk> found out that somebody had already got there before me
<sadmac> so this is already upstream?
<Keybuk> yes
 * sadmac pulls open the documentation folder in his git tree...
<Keybuk> since 2.6.14
<Keybuk> ah, see
<Keybuk> that's the rub
<Keybuk> it's almost completely undocumented
<Keybuk> what documentation there is was written by somebody with only a passing familiarity with English
<Keybuk> I had to pretty much figure it all out from first principles
<Keybuk> but now I have, I get messages when a process forks (or just calls clone)
<Keybuk> and when a process calls exit
<Keybuk> and when it calls exec
<sadmac> Keybuk: oh, KERNEL 2.6.14
<sadmac> Keybuk: I thought it was one of those weird british dates for a second
<Keybuk> you know you guys are unique in writing the date middle-endian, right?
<Keybuk> and that middle-endian is batshit insane whichever way you look at it?
<sadmac> what's wrong with bat shit?
<Keybuk> it leaves a bad taste in the mouth
<sadmac> you're doing it wrong. Put it on toast wedges, then melt cheese over them in a toaster oven, and sprinkle with cayanne
<Keybuk> you're American
<Keybuk> you don't even deserve to use the word "Cheese"
<sadmac> Keybuk: http://www.ratemyeverything.net/post/2277/The_Typical_Mac_User.aspx
<Keybuk> hey, you started it :p
<sadmac> noted
<sadmac> Keybuk: I clicked on a female friend's blog in my feed reader yesterday, thinking it was yours. After reading 2 paragraphs of her feminist critique of a novel she read there was a full 15 seconds when I thought you were a transexual and had neglected to mention :)
<Keybuk> I'm sure you would have noticed
<sadmac> Keybuk: I'm slow at 3am, and my feed reader is text only so no visual cues. But yeah, it sounded nothing like you.
<keesj> Keybuk: how to you do most development, do you use a virtual machine?
<keesj> also would this new tracing core posibly make it possible to have sub inits possibly running as user process
<Keybuk> keesj: most development I just use the test suite
<Keybuk> otherwise I replace the running init on my system ;)
<Keybuk> or use vmware
<sadmac2> Keybuk: what? no kvm?
<Keybuk> no
<Keybuk> I hate freedom
<sadmac2> Keybuk: Hitler would have used vmware.
<Keybuk> and Hitler would have preferred a nation of Blond haired, Blue eyed boys
#upstart 2009-02-27
<sadmac2> notting: bodhi pinged me again about those upstart rpms rotting in old-testing. Have you looked at them yet?
<notting> no. if you want, go ahead and push them
<sadmac2> ok
#upstart 2010-03-01
<crankharder> hey folks
<crankharder> trying to track down a change that happened sometime between ubuntu 8.10 and 9.10
<crankharder> on this 8.10 box I think all the upstart scripts are stored in /etc/event.d
<crankharder> but the upstart docs say they should be in /etc/init -- but i dont see that on a 9.10 box
<fsckroot> hello
<fsckroot> could anybody direct me to some concise documentation about the boot process of upstart?
<fsckroot> it seems to be sorely lacking everywhere I've looked
<Keybuk> what would you like to know?
<fsckroot> something like "this file is run first" --> which runs this one
<fsckroot> etc. etc.
<fsckroot> a tree or anything
<Keybuk> the whole point of Upstart is that there is no documentation like that
<fsckroot> just so I can get my head around the whole process
<Keybuk> an Upstart boot process is designed so that the set of jobs run during boot can be completely flexible
<fsckroot> I know
<Keybuk> and can be run in different orders without problem
<fsckroot> I gather that
<fsckroot> kinda weird coming from an Arch / Slackware background
<fsckroot> BSD init and such
<Keybuk> right, it's quite difference
<Keybuk> fsckroot: I guess the issue is that there's no real documentation on that
<Keybuk> I have an idea that Upstart could log a boot sequence and give you output at the end saying what happened this time
<Keybuk> "the startup event happened, so I started mountall"
<Keybuk> "that service gave me a filesystem event, so I started udev"
<Keybuk> etc.
<JanC> Keybuk: such a log would certainly be useful for debugging boot/startup problems
<Keybuk> yeah
<Keybuk> I think I'd also like a kind of interactive boot
<Keybuk> e.g. on a console
<Keybuk> Received startup event, shall I start mountall [y/n] ?
<sadmac2> Keybuk: if we do the enable/disable thing I talked about, we could tie it to that
<Keybuk> precisely
<sadmac2> Keybuk: "enabling service foo. is this ok?"
<Keybuk> certainly related anyway
<plundra> 5
<plundra> Oops
<Keybuk> plundra: that's exactly what I was going to say
<plundra> In my defense; I was on my cellphone and intended to use Backspace. But Enter is next to it :P
<plundra> So, anyone got any tips on redirecting stdout in a way that the respawn-functionality still works? 
<plundra> This is on 0.3.9(? Or whatever, old anyway)
<plundra> I added some hack last year, which logs start/stops and the output. 
<Keybuk> no idea, respawn in 0.3.x was a bit hacky
<plundra> I'll give you an idea of what I have, hold on. (Don't mock me!)
<plundra> http://pastie.org/private/3urfpp4pdirtmnbnflkvaw
<plundra> I hope I'll be able to upgrade to the next Ubuntu LTS some time this year, then I'll probably get some fancy new upstart :)
<Keybuk> I don't know what you mean by "redirecting stdout in a way that the respawn-functionality still works"
<plundra> Keybuk: It supervises the wrong pid.
<plundra> So with the hack I pasted above, the loop-protection of respawn doesn't work.
<Keybuk> does it matter which it does?
<Keybuk> both will be in the same process group
<Keybuk> and when one dies, the other should get SIGPIPE and exit no?
<plundra> What matters is, if shit goes bad now, it'll loop and give send hundereds of mail.
<Keybuk> maybe
<Keybuk> not sure there's a proper way to do that with 0.5 either
<sadmac2> *0.6 ?
<Keybuk> right
<plundra> Isn't there built in stuff for logging the output? I might be wrong though, havn't looked at the project at all for a while.
<Keybuk> still relies on supervising a pid
<Keybuk> no
<plundra> "console" was the option I had in mind, but ok, no changes there?
<Keybuk> none yet
<mbiebl> hi Keybuk
<mbiebl> could you apply this tiny patch for upstart, please: http://paste.debian.net/62034/
<Keybuk> mbiebl: could you file that as a bug please?
<Keybuk> (with the issue the patch fixes)
<mbiebl> hm, well ok
<mbiebl> I thought it was a no-brainer
<Keybuk> I can't remember why that breaks
<Keybuk> because it WFM
<mbiebl> Keybuk: https://bugs.launchpad.net/upstart/+bug/530385
<Keybuk> s/upstart/libnih/ *face palm*
<Keybuk> oh, no, that is upstart
<Keybuk> sorry
<Keybuk> the weird thing is that I *don't* get that error
<mbiebl> Keybuk: I have a lucid chroot
<mbiebl> lemme try it there
<Keybuk> works on karmic too
<mbiebl> nope, fails exactly the same way for me
<mbiebl> Keybuk: I used the 0.6.5 upstart and 1.0.1 libnih tarballs
<Keybuk> koooky
<Keybuk> works every time for me
<mbiebl> Keybuk: could you try a clean chroot?
<Keybuk> not sure how a chroot would change anything
<Keybuk> the patch is clearly right
<Keybuk> but just odd that it doesn't affect me
<Keybuk> it looks like libtool is doing the dequoting
<mbiebl> Keybuk: I guess it's a local modification on your system
<Keybuk> don't see why
<Keybuk> I don't *have* local modifications on my system
<Keybuk> if I want to change something, I change the package and upload it <g>
<mbiebl> This is weird indeed
<mbiebl> as said, I can also perfectly reproduce it on the lucid chroot
<Keybuk> oh
<Keybuk> wait
<Keybuk> your paste doesn't run through libtool
<Keybuk> what configure args are you using?
<mbiebl> ./configure --with-local-libnih=libnih-1.0.1
<Keybuk> mbiebl: that's it?
<Keybuk> how weird
<Keybuk> wonder why it's not linking with libtool
#upstart 2010-03-02
<mbiebl> Keybuk: want a typescript?
<Keybuk> a whuh?
<mbiebl> man script
<Keybuk> not really ;)
<Keybuk> it's not interesting a bug
<Keybuk> unless it only fails on Tuesdays
<mbiebl> yeah, the only interesting aspect of this bug is, that you can't reproduce it :-)
<Keybuk> yeah, but meh, time-of-day
<Keybuk> there is some reason why libtool decides to get involved or not
<Keybuk> but I can't remember what it is
<Keybuk> and my PS3 has started working again now <g>
<ion> http://tissi.apina.biz/full/27135.png
<Keybuk> ion: I don't get it?
<Keybuk> oh, no, I do :)
<Keybuk> it's not dead
<Keybuk> it just had Monday off after a hard weekend
<ion> âSpace, the final frontierâ â (an inelegant, but somewhat accurate translation) âAvaruus, tuo kÃ¤ymÃ¤ttÃ¶mistÃ¤ korpimaista vihoviimeinenâ â (Google translate to English) âSpace, that unfermented wildcat from pestilentialâ
<Keybuk> argh
<Keybuk> my brain is too attuned to thinking about race conditions
 * Keybuk notices a race condition to do with writing pid files
<sadmac2> Keybuk: what's going into 0.7? I don't think we talked about it before and its on launchpad. Is it just a development release to lead into 0.10?
<sadmac2> a la 0.5->0.6
#upstart 2010-03-03
<plundra> Hmm!
<plundra> Am I right when I think upstart sets the process-title, to whatever is launched?
<plundra> Because, when I re-set the process title inside of my application; nothing gets "through"
<Keybuk> no, Upstart doesn't muck around with the process title of children
<Keybuk> exec() already takes care of that, after all
<Keybuk> and it's handy to see the brief period where the child is still "init"
<plundra> Hmm, so I should be able to change title?
<Keybuk> yes, don't see why not
<plundra> HMM! Can't recreate it with an example script :) I'll test some more. Thanks
<Keybuk> what are you using to set the process title of your application?
<plundra> It's python, I'm using setproctitle
<plundra> Worked fine when not launching via the upstart-job, but then I wrote a test which ONLY sets the title and sleeps, using the same routine, which worked just fine.
<Keybuk> I didn't think Linux implemented setproctitle() :p
<plundra> I'm pretty sure it uses a few hacks to get it working on different OSs.
<plundra> Since it works on Linux, OSX, BSD and even Windows.
<plundra> http://pypi.python.org/pypi/setproctitle/
<Keybuk> I'd point out here that you're saying it isn't working on Linux, that's all :p
<plundra> As I said, it do work outside of upstart with the application I initially wrote, which uses it. But not with upstart. Although, when writing a proof-of-concept, it does indeed work with upstart. Which puzzles me.
<Keybuk> I can't think of anything "odd" Upstart would do here
<plundra> Heh, my stupid processes are respawning, didn't see that :-P I wonder what I broke.
<Keybuk> after all, after the exec() it's a clean environment anyway
<plundra> Yeah, no, it's me of course :)
<astsmtl> Hi all!
<Keybuk> astsmtl: hi
<astsmtl> Question about upstart in LTS. :)
<astsmtl> I mean current LTS.
<astsmtl> Which is Hardy.
<Keybuk> sure
<Keybuk> actually, I think both dapper and hardy are technically LTS ;-)
<Keybuk> dapper doesn't EOL for server until 2011
<Keybuk> but since dapper didn't have Upstart ... I'm just digressing
<astsmtl> I have a simple job def. exec su xxxxxx -c "/usr/bin/Newd --daemon --pid-file=/var/run/Newd/Newd.pid --config-file=/etc/Newd/config.xml"
<astsmtl> It seems like upstart doesn't catch this daemon. After I start this job it's status is (stop) waiting, and daemon is running.
<astsmtl> So I can't stop it, respawn won't work...
<astsmtl> Upstart version is 0.3.9-2.
<astsmtl> So the question is: "Is it possible to lanch daemon like this in my Upstart?"
<astsmtl> Also, is it possible with more recent Upstart version?
<Keybuk> astsmtl: correct, Upstart 0.3.9-2 cannot do that
<Keybuk> more recent versions can
<plundra> Why would you want to launch a background deamon from upstart? (It's a real question, I might have missed some use-cases :P)
<plundra> ae*
<Keybuk> plundra: most daemons take great care to not daemonise until they're ready to receive connections
<Keybuk> (for example)
<Keybuk> so it's a good indication that it's "ready"
<plundra> Ah, yeah, ok :-) I get that.
<astsmtl> So, launching a background daemon is a normal use-case for Upstart?
<astsmtl> plundra: I'm a bit confused with your question. :)
<plundra> astsmtl: To me it sounds weird, I mean, from what I want out of upstart at least.
<plundra> I just want it to respawn our applications, if needed :-) Sure beats fire-and-forget from init.d, which was used before.
<Keybuk> astsmtl: it's supported with 0.6.x
<astsmtl> plundra: I started looking at upstart jobs because of respawn too. :)
<astsmtl> Keybuk: Thanks and sorry for my engrish. :)
<astsmtl> Keybuk: btw, You are Scott James Remnant it seems?
<Keybuk> yes
<Keybuk> it sometimes seems that way to me too
<plundra> I'm planning to try supervisord actually, to see if it's not worse then upstart for what we use it for. Because I like the built in stdout/stderr-logging capabilties, and mail notifications.
<plundra> Since I've added those two things with horrible hacks in my upstart-jobs :-P
<Keybuk> yeah
<Keybuk> ENOTIME ;-/
<astsmtl> Keybuk: Thanks for livef1. I even tried to rewrite it in python as a library, but didn't finish. :)
<sadmac2> after all the time I spent trying not to hack on libnih, its all I've been doing lately
<Keybuk> sadmac2:  ;)
<Keybuk> me too
<Keybuk> the third iteration of the epoll stuff is starting to look awesome
<DuckFault> does upstart provide a mechanism to get all events generated during early boot?
<Keybuk> DuckFault: not at the moment
<sadmac2> Keybuk: I still have most of that triggers stuff sitting in my dusty 0.6 tree. Not sure if it still merges even.
<DuckFault> Its very annoying debugging bootup with a read only root and having no syslog started and having issues with upstart.
<Keybuk> yeah, I think I want the ability to be able to ask upstart "so, what did you get up to today?"
<DuckFault> granted it was an embedded device with no video and no serial out, but those shouldn't be necessary
<Keybuk> and have a good event log
<Keybuk> not just what events happened, but what upstart did as a result
<DuckFault> you can't have a forever event log, but at least a last 5 minutes or something
<Keybuk> ie. "net-device-up eth0" => "started apache" etc.
<DuckFault> yes, that would be immensely beneficial
<Keybuk> it doesn't need to be "forever", a ring log would be fine
<DuckFault> but just an event list would work for me
<Keybuk> once you have a filesystem you could opt to log it there
<DuckFault> I figure if you're in the guts enough to need to know what events occurred and what their actions are, you know enough where to see what actions would get initiated by said events.
<Keybuk> actually, that's the thing
<Keybuk> often when debugging, it's assuming what does happen being different to what actually happened that's the bug
<Keybuk> so I usually need to know whether upstart actually *did* start a job
<Keybuk> and if not, why not, etc.
<sadmac2> Keybuk: a quick fix for a lot of these logging questions might be to do a 0.6.6 with some systemtap/perf/$footracer probe points shoved in.
<Keybuk> sadmac2: interesting
<Keybuk> what you call a quick fix I call "argh, hard!"
<Keybuk> suggestion systemtap as a quick fix for a lack of logging is like suggesting amputation as a quick fix for a splinter
<sadmac2> Keybuk: one or two plus the tracer stuff would do it. Then you just "probe upstart.event { printf("%s %s", $upstart_event, $upstart_args) }
<sadmac2> last I looked at them they were pretty easy to put in... maybe I should look again.
<ion> http://zi.fi/shots/clang.png
#upstart 2010-03-04
<Keybuk> hmm, looks like clang gained support for more gcc extensions
<Keybuk> still doesn't support local labels though ;'(
<sadmac2> Keybuk: ah. nothing like combining preprocessing and goto :)
<Keybuk> sadmac2: hmm?
<sadmac2> Keybuk: that's mostly what I use local labels for, when I use them.
<Keybuk> they're handy for autogenerated code
<sadmac2> that too
<Keybuk> where you have local "get out of here on error" code
<Keybuk> but you might have a nested loop inside with the same auto-generated code
<Keybuk> (which is exactly how they end up in Upstart - the D-Bus bindings code uses them)
<sadmac2> almost the same thing really. The preprocessor basically is a (really weak) autogenerator
<Keybuk> io.c:681:3: warning: expression result unused [-Wunused-value]
<Keybuk>                 NIH_ZERO (nih_io_message_add_control (message,
<Keybuk>                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<Keybuk> In file included from io.c:42:
<Keybuk> ../nih/macros.h:176:48: note: instantiated from:
<Keybuk>         ({ typeof (_e) __ret; while ((__ret = (_e))); __ret; })
<Keybuk>                                                       ^~~~~
<Keybuk> ..
<Keybuk> of course the other problem with clang/llvm at this point is the lack of documentation
<Keybuk> so I have no idea how to teach it that it's quite ok for that expression result to be unused
<sadmac2> Keybuk: does clang compile to native code or only to that llvm bytecode language?
<Keybuk> clang is an llvm frontend
<Keybuk> so clang produces bytecode
<Keybuk> llvm turns that into assembly
<Keybuk> this isn't much different from gcc
<sadmac2> ok. the llvm page seemed kind of confusing about that.
<Keybuk> llvm isn't purple enough
<sadmac2> Keybuk: purple?
<Keybuk> sadmac2: I've been dealing all day with minor changes to the splash screen
<Keybuk> wrong colour of purple, etc.
<sadmac2> Keybuk: purple? Isn't Ubuntu brown?
<Keybuk> apparently someone told the design team it was UI Freeze today, so they've been mass-landing the entire Ubuntu/Canonical rebranding in one go
<Keybuk> no, it's purple now
<sadmac2> gj
<sadmac2> the number of people for whom that is the primary Ubuntu complaint is...unfortunate.
<Keybuk> http://arstechnica.com/open-source/news/2010/03/ubuntu-dumps-the-brown-introduces-new-theme.ars
 * sadmac2 reminds himself to pull an Ubuntu pulseaudio package
<sadmac2> I've never heard Ubuntu user's complain about pulse, and I can't for the life of me imagine how you could have made it stop hemorraging failure and disappointment.
<Keybuk> oh god
<Keybuk> the best bit is that Lennart complains about our pulse packages, saying that they're broken and wrong
<Keybuk> and this is why all our users complain about how broken pulse audio is
<Keybuk> no, we say, pulse audio is a broken heap of shit
<sadmac2> Keybuk: I wanna replace it. Lets write an audio server this weekend
<sadmac2> No scratch that. Audio servers are wrong to begin with.
<sadmac2> Open source disasters: when the only person willing to do the work is the one least qualified.
<sadmac2> What was that quote about being careful around the man who is stupid and industrious?
<Keybuk> heh
<sadmac2> Wayland has less code than Pulse. its great :)
<sadmac2> Of course I think Wayland might have less code than rm
<sadmac2> its kind of scary how small that thing is.
<sadmac2> http://en.wikipedia.org/wiki/Kurt_von_Hammerstein-Equord
#upstart 2010-03-05
<cheako> Hello, I'm running Ubuntu and I don't have any getty.  I'm like them plz.
<cheako> *I'd*
<sadmac> cheako: this channel is for general upstart development discussion. Your question deals with ubuntu-specific configuration issues
<cheako> sadmac: So it's a known ubuntu configuration issue?
<sadmac> cheako: not necessarily, but its not on topic here :)
<cheako> I get no love from #ubuntu, who else uses upstart?
<sadmac> fedora, debian, and dozens upon dozens of embedded devices from the palm pre to obscure little microcontrollers nobody will ever hear of.
<cheako> I'll try #debien then, thatnk you.
<cheako> The ppl in #debian were slightly more perceptive then the response I got here.  Still they won't support Ubuntu.  Is there any where to get support?
<ion> https://answers.launchpad.net/ubuntu/+source/upstart
<cheako> Hay, runlevel returned unknowen.  so I ran telinit 2 and my system came up.  Would that mean something happened?
<ion> Are you running lucid? Is your system up to date?
<cheako> The ppl in #debian threatened to silance me.  So don't ever tell any one thjat Debian uses upstart... they don't.
<cheako> Yes, it's upto date... however I can't find lucid.
<cheako> perhaps it a version and not an applicaion
<Keybuk> cheako: edit /etc/init/rc-sysinit.conf and remove "and net-device-up IFACE=lo" from the "start on" line
<cheako> I'm running this karmic thing, Keybuk I'll try that.  Thank you.
<cheako> Sounds like a winner.
 * Keybuk has got quite used to the whole ".conf" thing now
<Keybuk> I thought I'd never like it, but somehow it seems better
<cheako> With any luck, I wont be back.
#upstart 2010-03-06
<Caesar> # service autofs status
<Caesar> autofs stop/killed, process 3690
<Caesar> # pgrep automount
<Caesar> 3687
<Caesar> I think Upstart is getting very confused :-(
<Caesar> # service autofs stop
<Caesar> stop: Job has already been stopped: autofs
<Caesar> http://paste.ubuntu.com/389279/ has my Upstart job definition, which I'm trying to test
<Caesar> (on Ubuntu 10.04)
<Keybuk> Caesar: bug #406397
<Caesar> Yarp
<Keybuk> probably got confused following the pid chain and ended up with something that isn't actually autofs
<Keybuk> like one of the fork parents
<Caesar> Yeah
<Caesar> "expect fork" after a clean boot fixed it
<Keybuk> sweet
<Keybuk> sorry about that one
<Keybuk> I have a fix for it ;)
<Keybuk> but it's a M one
<Caesar> Doh
<Caesar> It's pretty bad how busted things get in this situation
<Caesar> start and stop just hang
<Keybuk> yeah
<Keybuk> it's because it's not supposed to be able to happen :p
<Caesar> heh
<Caesar> So what's currently doing my head in is the timing between the legacy init scripts and the upstart jobs
<Caesar> Because a lot of the upstart jobs aren't runlevel dependent (maybe if I follow the dependency chain back I'll find that they are)
<Keybuk> they're not supposed to be
<Keybuk> there's a vague wishy-washy attempt to make runlevels go away :p
<Caesar> heh
<Keybuk> btw are you coming to the-woods-outside-Brussels?
<Caesar> Sadly not, as my wife is due on May 24
<Caesar> And I'm transferring off Goobuntu after my paternity leave, so I won't have a justification for coming to future UDSes
<Keybuk> aww :-(  where are you transferring to?
<Caesar> The security team
<Keybuk> before you go, I'd really appreciate it if I could get a kind of "what Google would like from Upstart" mail
<Keybuk> what you've found difficult about it
<Keybuk> problems you've had
<Keybuk> what you wish it did
<Keybuk> what you wish it did better
<Keybuk> etc.
<Caesar> I can do that, particularly after we've deployed 10.04
<Caesar> Right now I'm just having a hell of a time debugging the boot process. That's due to a combination of factors though
<Keybuk> yeah, as I think I've talked to you before, I want Upstart to keep an event log
<Keybuk> so after a boot you can get a log like
<Keybuk> "the foo event happened, so I started apache, but I couldn't start squid yet because it was still waiting on apache"
<Keybuk> "the started apache happened, so I started squid"
<Caesar> That sounds perfect
<Keybuk> and want that to be hooked up in a way that on a hung system, you can have upstart squirt it out to netconsole
<Keybuk> "dump my brain"
<Caesar> The startup event is the root of everything isn't it?
<Keybuk> yes
<Keybuk> though in later versions you may be able to do "on system starting" and "on system started"
<Keybuk> as two separate bits
<Caesar> Okay, so startup -> mountall -> (local-filesystems) -> (run level 2) -> rc 2
<Caesar> Meanwhile, (local-filesystems) -> networking
<Caesar> So it sounds like the rc 2 legacy init scripts are going to run in parallel with the network coming up
<Caesar> Keybuk: something my cubemate was just lamenting is how restart isn't "restart or start"
<Keybuk> Caesar: that's deliberate ;-)
<Caesar> I thought as much
<Caesar> Is there a "start or restart" equivalent?
<Keybuk> I really hate how "/etc/init.d/foo restart" can start a service that wasn't running to begin with
<Keybuk> stop foo ; start foo
<Caesar> Right
<Caesar> A bit more typing
<sadmac> Keybuk: I thought there was a restart. moreover I thought it was slightly different than stop;start
<sadmac> or was that for 1.0
<Keybuk> there is a restart
<Keybuk> and it is slightly different ;)
<Keybuk> Caesar had just asked whether there was an alternative to it that wasn't slightly different to stop;start ;)
<sadmac> Keybuk: I'd think the preference would be restart foo || start foo
<Keybuk> that'd work too ;)
<sadmac> Keybuk: I have an ubuntu user who says he would like to "bitch slap ubuntu for making it look like a friggin mac" and would like me to direct him to your art department. Might you be of assistance?
<Keybuk> sadmac: if we want to be better than a Mac, first we have to catch up with them ;)
<alphainu> ~_~
<ion> I *wish* Ubuntu looked like MacOSX (except for the even more blurry fonts and a dock that takes up a huge amount of screen real estate). :-P They have very stylish things going on, such as no left/bottom/right borders in windows, as the shadows are enough to differentiate a window of a certain color from another similar one. I love that.
<sadmac> much as I liked making brown jokes in the past, I don't much care what ubuntu looks like in the end.
#upstart 2011-02-28
<ion> jhunt: FWIW, my desktop system booted fine with Upstart from https://launchpad.net/~jamesodhunt/+archive/upstart-testing
<jhunt> ion: awesome, thanks for testing!
<jhunt> ion: I'll be updating the ppa in the next few days with the visualisation feature (just finishing off now) so look out for more of an announcement then...
<ion> Alright, iâll notice it at the latest when running safe-upgrade. :-)
<ion> How to use user jobs, btw? I didnât notice mention of them in init(5).
<ion> (Might as well look at the source.)
<jhunt> The man page still needs to be updated for sessions, chroot, etc. This will come in the next few days...
<jhunt> ion: feel free :)
<ion> Note to self: talk to Keybuk about the method Erlang uses to elegantly and robustly implement runtime code upgrades with passing state to new versions, along with some rough ideas of how to implement the equivalent in C.
<Zed`> can someone point me to some example upstart scripts? I need to start a shell script on startup and run a different one on shutdown - my google foo is failing me and I am the worst scritper on the planet
<Keybuk> there is no such thing as Upstart scripts
<Keybuk> the code within the script..end script block is Shell
<Zed`> hrm, I have some shell scripts that a user will maintain - so I need to call a script - not maintain the script code in upstart format - that make sense?
<Keybuk> sure
<Keybuk> so use exec
<Zed`> that much is obvious - what is not obvious is how /exactly/ to do that - hence the request for some examples
<Zed`> not obvious to me*
<Keybuk> Zed`: did you read the manpages?
<Zed`> and the web site and google and scores of the files in /etc/init
<Keybuk> and it's still not obvious?
<Zed`> correct
<Keybuk> well, if you've read all the files in /etc/init\
<Keybuk> then you've read all the examples
<Zed`> none of them do what I want
<Keybuk> are you sure?
<Keybuk> perhaps they all do what you want, and you can't recognise that?
<Zed`> that is a distinct possibility
<Keybuk> /etc/init/failsafe-x.conf
<Keybuk> for example runs a shell script on a given event (gdm being stopped with a bad exit status)
<JanC> if a user needs to be able to change a script that will be run as root, you should probably give them root access...   ;)
<Keybuk> if a user can change a script that will be run as root, you *have* given them root access ;-)
<JanC> maybe Zed` should explain what exactly they need...
<Zed`> they are not root but they are /trusted/
<Zed`> and I just need to startup teracatta on boot and make sure it is shut down cleanonly on shutdown or restart
<Keybuk> almost every single .conf file in /etc/init does that
<Zed`> You must have missed the part where I said I don't grok the scripts
<Keybuk> no, I did
<Keybuk> I just don't think there'
<Keybuk> s any way I can help you
<Keybuk> if you don't understand shell, that's probably a good place to start
<JanC> Zed`: do you mean the scripts that your users write or the upstart jobs?
<Zed`> perhaps if I put up a pastebin you could tell me if I have it right?
<Zed`> JanC: upstart
<JanC> well, those aren't called "scripts" but "job configurations" normally (but they can contain shell scripts or run them)
<JanC> and putting you job description on a pastebin might be useful, but we might need more info still...
<Zed`> http://zed.pastebin.com/XqbSfpEz
<Zed`> these jobs run automatically simply because they are in /etc/init/ ?
<JanC> that will start the script once the filesystem is up
<Zed`> indeed
<JanC> the job configurations don't "run", but they describe when jobs have to run or have to be stopped
<Zed`> I get that :)
<Zed`> sorry if my momenclatures are lacking
<JanC> and all *.conf files in that directory are read
<Zed`> question is: is that the best way do do what I want
<JanC> well, you say your users can change that script?
<Zed`> only one user that is trusted
<JanC> you do know that you give that user root access that way?
<Zed`> I understand the implications
<Zed`> they are the only user of the box
<JanC> so, doesn't it do what you need?
<Zed`> what I pasted?
<JanC> yes
 * Zed`  laughs
<Zed`> that is what I am seekign an opinion on
<Zed`> seeking*
<JanC> eh?
<Zed`> It seems to me that what I pasted will do what I need - however I am not qualified to know if it is correct - that is why I asked
<JanC> it's easier to try, it might work, but that depends on what the script does, and as you don't control what happens in it, you're at the mercy of your user...
 * Zed`  sighs
<Zed`> I already explained that I am not worried about that
<Zed`> the box exists for the user to run this script
<Zed`> I know you are trying to help me help myuself and that is laudable and all
<Zed`> I just have a simpel question: given the usecase I have explaied is what I pasted correct
<Zed`> for example
<Zed`> might I use a better/differet start on command
<Zed`> if I could down the box indiscriminately I could test it on the blind
<JanC> you don't understand, whether the job description works or not depends on such things as the script not starting anything that forks and returns to the script immediately
<Zed`> but I can't
<JanC> and whether "start on filesystem" is the best depends on what is going to be run (what it needs etc.)
<Zed`> are there docs start ?
<JanC> ?
<Zed`> I don't know the difference between 'start on filesystem' and 'start on startup' for example
<Zed`> or of there are other start on parameters I can use
<JanC> both have manpages
<Zed`> start does?
<JanC> no, both events, 'start' is documenten in init(5)
<Zed`> thanks much for the help - you are right, my shortcutting through the process is a mistake
<Zed`> JanC: Keybuk thanks again
<Delemas> I'm trying to convert an old style init.d script to upstart. It nicely hangs on initctl start service and initctl stop service. What did I do wrong? http://pastebin.com/eaxunfHj
<ion> You probably told Upstart to expect a certain behavior wrt. forking from the main process and the process behaved differently. The fork tracking code in the current release is easy to confuse with an incorrect âexpectâ stanza. A future release will fix that. If initctl status jobname prints a PID which doesnât actually exist, thatâs whatâs going on. Either reboot or use the nasty kluge at http://heh.fi/tmp/workaround-upstart-snafu
<ion> (âsudo ./workaround-upstart-snafu 12345â where 12345 is the pid reported by âstatus jobnameâ).
<ion> If youâre not absolutely sure of how the main process daemonizes itâs better not to use âexpectâ and tell the main process not to daemonize at all for now.
<Delemas> The script is a bit weird in that it sometimes will just exit and other times it will daemonize and we want to respawn it if it dies in that case....
<Delemas> I get this from status: bmc-watchdog stop/killed, process 20574
<Delemas> hmm that ruby script certainly did something. After running it service bmc-watchdog start always gives: start: Unknown job: bmc-watchdog
<ion> Thereâs probably a parse error in the job definition. Look at syslog for the error message.
<Delemas> heh brilliant I was tailing /var/log/debug and the output was in /var/log/syslog... One of those days...
<Delemas> Thanks for the help btw...
<Delemas> Cool it works :) ttyl
#upstart 2011-03-01
<munderwo> Hi all.. If i have a set of commands to start a service, and a different set of commands to stop one, how do I do that?
<SpamapS> munderwo: post-stop and pre-start
<munderwo> so instead of having something in script... I put the stuff to start in pre-start and the stuff to stop in post-stop?
<SpamapS> yes.. though that will probably mean you can't use reload or respawn.
<munderwo> right... so what about it I put the shutdown in the post-stop and the startup in the normal section?
<munderwo> can I use reload just like start and stop?
<SpamapS> ww
#upstart 2011-03-02
<ralfgro> morning!
<ralfgro> I'm still looking for a solution to start a script when tty1 is in state "starting" 
<ralfgro> _and_ if installed/active when gdm/kdm is in state starting
<ralfgro> but I would like do add only a new upstart script, and not modify other scripts
<ralfgro> I have a condition that depends on tty and gdm/kdm, but if kdm/gdm is not running this is not working
<ralfgro> my script should run before a user can login
<ralfgro> and we have systems with *dm and without
<SpamapS> ralfgro: start on starting tty1 or gdm doesn't work?
<SpamapS> ralfgro: oh you need to run *after* those? 
<david506> I wrote my upstart script, it starts up fine. It shuts down my services fine but it hangs after it shuts down my program
<david506> http://pastebin.com/aUg5ssm5
<david506> The script actually starts 3 threads. Please help
<ion> Do not use âexpectâ if youâre not absolutely sure of the forking behavior of the main process. Youâll confuse Upstart.
<david506> ok
<david506> The service script that is called calls three different scripts with & at the end to fork them. Is that why upstart is confused ?
<ion> That definitely doesnât match what âexpect daemonâ means.
<david506> oh ok
<ion> keybuk: Do you know how Erlang implements trivially easy and robust runtime code upgrades? Iâve thought a bit of how something similar could be done in C.
<ion> In fact, iâll try to get around to writing an email to the Upstart mailing list, trying to articulate my general idea.
<Keybuk> I don't know much about Erlang
* Keybuk changed the topic of #upstart to: Upstart 1.0 "This is a fertile land, and we will thrive" | http://upstart.at/
<ion> Woot, that was quick. Is that with proc connector goodness?
<ion> Ah, the release message doesnât seem to say so.
<Keybuk> no, that's me declaring that the version that's been stable for years is 1.0 ;-)
#upstart 2011-03-03
<ion> Man, this email is getting longer than i thought.
<twb> As at lucid, "kill -SEGV 1" results in a kernel oops.  Is that the intended behaviour?
<ion> What else should happen?
<twb> Well, the kernel appears to discard "kill -15 1" and "kill -9 1"
<twb> I'm OK with it doing that, I was just wondering if it wasn't *supposed* to
<ralfgro> SpamapS: I need more a condition like start on starting tty1 and (ifstarting kdm or gdm)
<ralfgro> I would like some feedback on my first shot http://pastebin.com/XxTYPrzS
<ralfgro> the goal is to start a script before a user can login
<twb> There's something that deletes /etc/nologin
<ralfgro> this script has some user interaction, basicially it asks the user if updates can be installed.
<twb> Work out what it is, hook into that
<ralfgro> the user should not even has a login screen
<twb> Then you're probably screwed
<twb> But you might be able to do whatever fsck does
<ralfgro> neither console nor gdm/kdm
<ralfgro> the  3 upstart script I have now do work, at lease in my limited setup
<ralfgro> but the way I do it seems not be very clean
<SpamapS> twb: right, I think SIGSEGV is important to deliver to even pid 1 so it can be debugged.. despite that it may oops the kernel.
<SpamapS> twb: that is a kernel issue... sysvinit also oopses on SIGSEGV
<twb> Okey dokey
<twb> Actually I am... abusing it to tell LXC that my container's setup script failed :-)
<twb> I happened to run the script by accident on a non-container, and it oopsed
<SpamapS> setup script? you're not using cloud-init ?
<twb> I'm using LXC
<SpamapS> you should. It has a local metadata tuype. :)
<SpamapS> which would have the nice side effect that your LXC container could be booted identical to a cloud node. :)
<twb> LXC containers don't "boot"; they don't have a kernel.
<twb> That's rather the point
<SpamapS> booting starts processes under the container
<twb> Bah
<SpamapS> just depends on what you need
<twb> I should also clarify that by "setup script" I mean the script that takes my company-specific LXC template and applies container-specific changes, like installing apache2 and git cloning a web app into /var/www/.
<foresto> Hi there.  I'm hoping someone here can help me.  I have upstart launching my daemon using a pretty simple config file with "start on filesystem", but my daemon complains that the nfs-mounted directory it needs does not exist when upstart launches it.  I wish I knew how to make it depend on the filesystem that contains the necessary directory. Any suggestions?
#upstart 2012-02-28
<fish_> hi
<fish_> i've wrote a upstart job, pretty simple. with 'start on filesystem' and a script block creating some directories
<fish_> but it doesn't get started. I already tried to run initctl emit filesystem but this seems not to start it either
<fish_> uhm looks like its more or less the same job as the rsyslog job. and that job works (-> it get started when emitting 'filesystem' event)
<fish_> looks like I can't start the job manually either.. according to strace it seems like it's stopping right after the first != 0 return code is found
<fish_> ok fixed that issue and then fixed another issues and lerned about tasks vs services. now it's a task but another job depending on that task doesn't start
<JanC> fish_: http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<JanC> all script sections are run with "/bin/sh -e", which indeed makes the shell exit after the first non-zero return code
<fish_> JanC: thanks!
<notwaffles> I'm trying to put together an upstart job to run browsermob-proxy but the stop command doesn't seem to work, does anyone have any experience with this?
#upstart 2012-02-29
<sveinse> Is there a way to stop a service from starting? E.g. during boot and within a job's script I want to stop another future job from starting. I can't control the other job's stanzas and it starts on runlevel
<sveinse> Can I do that? This is on Ubuntu Natty, so its an older version of upstart
<dkogan> anybody around to aid in defining an upstart .conf file?
<SpamapS> dkogan: where are you stuck?
<dkogan> SpamapS: Wrangling with basic of upstart's event-orientation instead of state-orientation
<dkogan> I'd like my job to run when a particular USB device is plugged in AND when a network device is up
<dkogan> either one is simple. but when I 'start on aaa and bbb', it doesn't work for post-boot USB insertions/removals
<dkogan> so at boot it get the USB-inserted and network-up events, and runs the job
<dkogan> then I pull the USB cable; upstart sees this and stops the job
<dkogan> then I re-insert the cable. Upstart sees the usb-inserted event, but NO network-up event and doesn't start my job again
<dkogan> this is really by design, since the network-up event is long-gone at that point. I essentially want a 'network-up' state and not a 'network-up' event. Is there a common idiom for this?
<dkogan> Thanks
<SpamapS> dkogan: right, basically you have a special case (at boot) and then hot-plug ..
<SpamapS> dkogan: simplest thing to do is probably to just wait in pre-start until the network is available in the way you need it
<dkogan> ok. I see
<dkogan> thanks
<SpamapS> dkogan: there are ways to make upstart coordinate it exactly.. but I think they'd complicate things more than simply testing that your desired network configuration is available
<SpamapS> dkogan: another option is to work a bit like mountall.. just start up and wait for a signal, then send the signal to the daemon whenever new network interfaces come up.
<dkogan> I'm ok with extra complexity if it makes things work "right". Let me look at mountall
<SpamapS> dkogan: the basic method it uses is to always try to mount everything... and then re-try whenever it gets SIGUSR1
<SpamapS> dkogan: so for NFS volumes, it just tries every time a network interface comes up.
<dkogan> ok. but here "it" is mountall, NOT upstart, right?
<dkogan> seems like this is something upstart should be able to do itself
<dkogan> I think I'll change all my conditions to 'or' instead of 'and' and simply re-check them before running the daemon. so upstart will trigger multiple times, but my "exec" stanza will make sure that everything is up that needs to be
<SpamapS> dkogan: right
<dkogan> while you're here, another semi-related question
<dkogan> I'm seeing that the usb-device-added event isn't triggered at bootup reliably
<dkogan> works about 80% of the time, but not 100%
<dkogan> I set the loglevel to debug and it's clearly not there when it doesn't work
<SpamapS> dkogan: even right after a udevadm settle ?
<dkogan> maybe....
<dkogan> this would be in the log?
<SpamapS> dkogan: well it happens early in boot right after udev is started
<dkogan> looking at the log, usb-device-added appears when it works and does not appear when it doesn't; "udevadm" never appears in either case
<dkogan> this with --verbose
<SpamapS> dkogan: I don't know that anything eill be logged
<dkogan> also, older upstart; 0.6.5 (from ubuntu lucid). Tried up to 0.9.something and it was still broken 20% of the time
<SpamapS> dkogan: this is a udev issue, not an upstart issue
<dkogan> ok. any debugging tips?
<dkogan> even when upstart doesn't see the device at boot, udev does
<dkogan> the device is there and works fine
<SpamapS> dkogan: not really.. USB is outside my server-centric realm
<dkogan> ok. thanks for listening :)
<SpamapS> dkogan: so upstart's udev bridge starts *before* udev.. so if udev sees it and emits the event, then so shall upstart, in theory.
<dkogan> udev definitely sees it. I have a udev rule set up to make symlinks to the device, and those are there always
<dkogan> another interesting data point is that the boot takes about twice as long when it doesn't work...
<SpamapS> dkogan: interesting indeed
#upstart 2012-03-01
<norc> http://pastie.org/3492862  << `service openvpn start' hangs when I try to start that simplistic job.
<norc> (it's still reading from stdin, but that's it). the actual command is never executed
<norc> The status is `openvpn start/killed, process 839'
<norc> (By itself that command works just fine)
<norc> oh wow.
<norc> reading is hard.
<norc> http://upstart.ubuntu.com/cookbook/ 6.11.5 says that expect fork without a fork will cause start to hang!
<ion> A nonexistent process Upstart thinks itâs still tracking and you canât get it out of that state? http://heh.fi/tmp/workaround-upstart-snafu
<ion> Oh, he already left.
<SpamapS> ion: somebody should really write a 'forget-process' subcommand for initctl so we can at least work around that silliness.
<ion> I kind of agree with Keybukâs sentiment about it: the fork tracking should be fixed instead of adding inelegant, nasty workarounds.
<SpamapS> ion: nobody has proposed a good solution to the problem though, so I reject that very true, but overly idealistic solution.
<ion> Keybuk already had a prototype. I wonder what happened wrt. it?
<wankdanker> I'm working on an upstart config and I want the process to start when /dev/ttyS0 is ready. Anyone have any ideas?
<ion> Do you have upstart-udev-bridge?
<wankdanker> yes, i think i do
<ion> I have the following to start when a 3G modem is ready:
<ion> start on tty-device-added ID_VENDOR_ID=12d1 ID_MODEL_ID=1001 ID_IFACE=00
<ion> stop on runlevel [06] or tty-device-removed ID_VENDOR_ID=12d1 ID_MODEL_ID=1001 ID_IFACE=00
<ion> Those events are sent by upstart-udev-bridge.
<wankdanker> awesome. that is so helpful. thank you!!
<ion> (I also refer to the device as /dev/serial/by-id/usb-HUAWEI_Technology_HUAWEI_Mobile-if00-port0 but thatâs not relevant here.)
<ion> See udevadm info --export-db for values you can use to match the device with.
<wankdanker> great. thank you very much.
<wankdanker> ion++
<wankdanker> no beers for ion. :(
#upstart 2012-03-04
<sveinse> Hi any activity here now? I have a natty armel system which hangs during boot. When I got around to start it in verbose and to start a serial terminal very early, I see that mountall, plymouth and udevd is running. I can't find out why the boot is stalling.
<JanC> sveinse: it's not fsck'ing or something like that?
<sveinse> JanC, no nothing
<sveinse> I'm not ruling out a faulty kernel or HW at this point. udev should trigger a series of events (*-device-*), could this be depended upon to be able to continue the boot?
<sveinse> Except dmesg shows nothing suspicious
<sveinse> But I trace this back to no rc-sysinit, hence no "filesystem" event being emitted, hence mountall which stalls
<JanC> you can probably look at /var/log/udev to see if those events were triggered
<JanC> if you can access the filesystem
<sveinse> janC, no, root isn't mounted as rw yet
<sveinse> Do you know if I can --verbose on mountall ?
<JanC> well, I don't know if you can boot a known working system from SD or USB with your ARM system, and then access the normal root filesystem from that?
<sveinse> I can take out the sdcard and insert it into my desktop machine, yes
<sveinse> This is how I got --verbose on upstart and an early serial console in the first place
<sveinse> So I can modify anything
<JanC> and read the udev log file?
<JanC> hm, but it probably didn't write anything, right
<JanC> seems like mountall does have a --verbose setting
<JanC> so in theory you can edit its upstart job config?
<sveinse> jup
<sveinse> doing it now
<JanC> --dev-wait-time=... might be useful too, for some problems
<sveinse> hmm. --verbose logs to stdout/err which is logged into /var/log/boot-something.log
<sveinse> Which isn't writeable yet. I'll have to modify the kernel params and enable rw I think
<JanC> can't you redirect it to your serial console?
<sveinse> JanC, yes I just did and now mountall continues like nothings ever happened.
<sveinse> JanC, but I have to leave. Thanks for your help. I got some pointers of where to look.
#upstart 2013-02-25
<jodh> xnox/stgraber: http://people.canonical.com/~jhunt/upstart/gui/upstart-monitor.py
<xnox> =) nice. Will try that in a bit.
<xnox> jodh: are you ok if I cherry-pick and upload the reboot command commit into ubuntu raring?
 * xnox notes to procenv compate upstart and normal sessions.
<xnox> s/compate/compare/
<jodh> xnox: as long as it's tested, sure :)
<xnox> it totally works on nexus tablets.
<xnox> no evident breakage on !armhf
<pabelanger> Anybody able to point to an example of having upstart 'start on' a service that _may_ not be installed?
<SpamapS> pabelanger: we've talked about this before. :)
<SpamapS> haven't we?
<SpamapS> perhaps that was somebody else
<SpamapS> pabelanger: anyway, if a service can be on the box and optional, it can also be on another box, right?
<SpamapS> pabelanger: thus, your program should handle it not being ready yet, in case you have started the two boxes in the wrong order.
<SpamapS> pabelanger: if, however, its something else, like your service supports the other one (like nmbd supports winbind), then you should use wait-for-state in pre-start...
<SpamapS> pabelanger: as in  'if [ -e /etc/init/$otherjob.conf ] ; then start wait-for-state WAIT_FOR=otherjob WAITER=$UPSTART_JOB ; fi
 * xnox likes checking `status $otherjob` as the job configuration file can be in multiple source directories or not on disk at all (in case of e.g. user session upstart and/or stateful re-exec)
<SpamapS> xnox: *good* point
<SpamapS> I believe actually wait-for-state will usually return immediately if the job doesn't exist because it does fail the start
<pabelanger> SpamapS, great, let me check the documentation bout that not
<pabelanger> now*
<soso> hello all
<soso> is someone from here interested into bugs with init 5 command, halt command and with services which don't running correctly when I am using halt command?
<soso> in ubuntu 12.04 LTS exactly
<JanC> soso: I think it's best if you say what your problems are and then hang around until somebody sees it (which might be tomorrow...)
<xnox> soso: also filing bug reports on launchpad either against upstart (ubuntu package) or upstart (upstream projects) is also an option.
<xnox> soren: some of the developers are in night timezone already though.
<xnox> soren: but yeah, go ahead =) what are you experiencing?
<xnox> we are currently working on improving shutdown.
<soso> So I am running Ubuntu 12.04 LTS and there is an  issue is with init 5 command which switch me to run lvl 5 but this command is not able to kill applications which are not part of OS. I am not sure whether init 5 is using only command kill or also kill -9. I didn't read init 5 script. Anyway, after when I am typing command halt system is freezing (hanging). The only chance how to bring system up is with reset button on my PC. But... when I am po
<soso> wer-cycle system I have a issue with services, exactly any network services (it looks like problem with services, but I don't know how to check it. I am new on Ubuntu). I am able to get network, but I have realy slow response on internet. When I am rebooting system again all services are going up normaly and everything is working correctly. I can send you some outputs if you will need.
<soso> if you need*
<soso> sorry for my English :P but I am sure that you are understand :D
<xnox> soso: upstart kills jobs that it manages (almost everything in /etc/init/*) but than later on sendsigs /etc/init.d/sendsigs actually kills the rest of things.
<xnox> but it gets interesting as one cannot kill things that are needed to unmount the root filesystem, so if for example you have networked storaged attached there are configuration where one can get stuck.
<xnox> (e.g. not being able to shutdown cleanly)
<xnox> soso: I'd recommend you file a bug against upstart and describe your setup and attach any logs that help (e.g. increase boot / shutdown verbosity)
<xnox> and hopefully some of upstart developers will be able to investigate further.
<soso> It is not about NAS or SAN. I am talking about slow response from Ethernet connection
<xnox> interesting.
<soso> yea. I am not experienced in Ubuntu or networking. so you can write me anytime that I don't know what I am talking about :D
<JanC> it might still be useful to report a bug
<JanC> and add/attach as much info as you can
<soso> yes, I am still here because I need to know which attached information can be usefull for this case. or from which commands I can get best information before I will report it
<soso> ok. so ps -ef can be usefull to check which processes are not able to shut down after init 5
<soso> any another idea what can be usefull?
<soso> useful*, sorry
<xnox> /var/log/syslog /var/log/upstart/*
<xnox> as well.
<xnox> nothing else spings to mind out....
<JanC> I think if anything else would be useful, it would depend on specific things in those you already named
#upstart 2013-02-26
<afournier> it happens that when i do a start job or stop job, upstart is waiting for something (it does not give back the shell), the job is in "start/starting" "stop/starting"
<afournier> is there a way to "debug" this behavior ?
<phroddon> afournier: increase the debug level (initctl -q log-priority debug, if I recall correctly)
<phroddon> afournier: I like to strace the upstart job also, it can help a lot
<phroddon> (for example, put a sleep at the very beginning of the job to have the time to strace it ;)
<afournier> like this "strace --someargs start job"
<afournier> ?
<afournier> ha you attach to the pid ?
<phroddon> yup 
<afournier> k
<afournier> i found something when "stracing" initctl 
<afournier> after the connect to dbus, and negotiation, it gets a recvmsg(3, 0xbf837c3c, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
<afournier> and then it waits forever in poll()
<afournier> any idea ?
<afournier> i am starting to think that upstart was not a good choice at all
<jodh> afournier: http://upstart.ubuntu.com/cookbook/#establish-blocking-job
<afournier> thanks jodh, i really thought initctl was buggy
<afournier> a warning would be a good idea, dunno if it's possible
<afournier> i will try this script right now
<jodh> afournier: it doesn't make sense to show a warning in this scenario as upstart is working correctly - it's simply blocking waiting for the remaining events in your jobs 'start on' to be emitted. If you don't want initctl to block itself (just the job), use 'initctl -n emit ...'
<afournier> that's what i was thinking in the first place, but using "start job" and waiting for ever is not natural, because when someone says "start job" it expects the job to start, not to wait for ever
<xnox> afournier: that depends, currently one is guaranteed that when `start job` exits with 0 you can rely  on the service be available & hence start using it immediately.
<afournier> the problem was on start, not at exit
<afournier> i was thinking that calling a job with the start command would force it to start, but from what i understood, if the job as something like "start on started other_job" job will wait until other_job has started
<afournier> to me start was implicit "manual" but it's not
<afournier> another option would be to print a warning/notice on CTRL+C, to say job was not started because this condition was not met
<SpamapS> afournier: start on and stop on are not evaluated when you do an explicit start or stop of a job
<afournier> so it's like having "manual"
<SpamapS> afournier: what you're blocking on is *other* jobs that 'start on starting yourjob and xxxxx' .. where xxxxx is something that happens only during boot most likely
<afournier> ah ok
<SpamapS> afournier: so I would look for other things that mention your job in their start on
<SpamapS> or stop on
<SpamapS> afournier: Those other things are most likely "doing it wrong"
<afournier> i get it
<afournier> thanks SpamapS
<SpamapS> afournier: as far as initctl blocking forever.. I am troubled by it too, and have oft thought that if 'initctl --verbose start foo' could say something like 'emitted starting foo\nstarting foo blocked by job bar [start on starting foo and net-device-up]' that would be great
<SpamapS> afournier: when you have log-priority set to debug, you can see that in syslog.. but.. yeah.. thats a bit disconnected from your terminal
#upstart 2013-02-27
<geekbri> Is there a way to run a command inside an upstart script as the root user if you are using setuid to run the process as a different user?
<geekbri> I need to ensure the existence of a pid directory, and the user running the process doesn't have permissions to create the dir
<SpamapS> geekbri: unfortunately no, its a known deficiency of setuid/setgid :(
<SpamapS> geekbri: for that, you'll want to remove the setuid/setgid and use start-stop-daemon to run the end-command as the user.
<geekbri> SpamapS: That stink :(.  I want to use setuid and setgid so i can use "limit" to set the ulimits 
<SpamapS> geekbri: http://upstart.ubuntu.com/cookbook/#changing-user
<SpamapS> geekbri: you can make a second job, that is 'start on starting foo' that does the directory bit
<geekbri> SpamapS: yeah, I was hoping to avoid that :-\
<SpamapS> geekbri: the idea I had is to have the pre-start/exec/script/etc. keywords take optional setuid/setgid args
<SpamapS> geekbri: nobody has had time to implement it though
<geekbri> Yeah, it would be nice if you could force a particular script stanza to run as a different user
<geekbri> that would solve my problem, and makes perfect sense :)
<SpamapS> geekbri: "patches accepted"
<geekbri> Yeah, I haven't looked at the upstart code base at all.  I might be able to whip something up and submit a patch
<geekbri> Ah, wish it was using git :)
<geekbri> Well thanks for the help.  Not sure how i'll end up dealing with this as i need to set the limits as well and thats a shell built in so can't be called with sudo.  Either way appreciate it
<xnox> jodh: does libnih also need malloc removal?
<jodh> yeah
<jodh> xnox: want to volunteer? ;)
<xnox> *sigh*
<afournier1> woglind, when it returns 1, opkg marks the package as "install user unpacked" instead of "install user installed" that means the postinst failed, that means it will try to launch the postinst everytime opkg configure is launched
<afournier1> oops wrong channel
<Guest-jeremy> Hi guys! I googled my query but can't find any answers. I would like to wait a specific amount of time between each respawn of my process. Could upstart even capable of that? 
<phroddon>  http://upstart.ubuntu.com/wiki/Stanzas#respawn_limit
<phroddon> Guest-jeremy: ^ should do what you want
<jodh> Guest-jeremy: ... or to actually delay the respawn itself, you could do something like 'post-stop exec sleep 7'.
<Guest-jeremy> thx guys !
<Guest-jeremy> I think it answer perfectly my issue
<geekbri> ok so if expect fork expects the thing to fork 1, and expect daemon expects it to fork twice, what do i do for a piece of software i have that forks 3 damn times :)
<xnox> geekbri: it's bad software. Why does it do that? =))))
<geekbri> xnox: I don't know, but its sure not making life easy is it :)
<xnox> geekbri: the best solution is to make it run in foreground and not fork at all.
<geekbri> Yeah, i was hoping to avoid doing that, but I think that is what i will do
<xnox> geekbri: stdout & stderr will be logged into /var/log/upstart/$job.log
<xnox> geekbri: it's actually for the best & most reliable way.
<xnox> geekbri: in autofs5 i patched out pointless forks by moving daemonisation first and made all other forks it performs to be done once it has daemonised already.
<xnox> that way the first fork was the right one to track all all others appeared & disappeared.
<xnox> what is it doing in those three forks?!
<geekbri> xnox: I discovered the issue actually.  I'm running the daemon via sudo, so I guess thats causing it to fork an extra time.  I have to do this as I can't use setuid and setgid because I need to create a directory in the startup script, but if i setgid it doesn't have persm to create the directory
<xnox> geekbri: yes sudo adds an extra pointless fork, don't do that.
<geekbri> how will i run it as a different user then if i can't use setuid because I need to run commands as a privileged user in the upstart script?
<xnox> geekbri: what directories are you creating? can the be shipped by a package? Also directories can be created in a separate job with stanza task which you can depend on.
<xnox> and later you can start/stop/restart your main daemon without worrying about directories, cause they will be there.
<geekbri> xnox: Was hoping to avoid creating 2 upstart jobs for 1 daemon as that seems like a hacky work around.  I need to ensure the pid directories exist, or else it explodes why trying to run
<geekbri> Life would be so much easier if you could just specify only certain stanzas to run under setuid :)
<xnox> geekbri: but if you are running it in foreground it shouldn't need any pid directories.....
<geekbri> right, but, ok the issue here is
<SpamapS> geekbri: start-stop-daemon can exec, rather than fork+exec. Why are you using sudo?
<geekbri> Im working on writing a recipe esentially that runs on multiple platforms and supports multiple job control types, EG upstart / init.d etc
<xnox> geekbri: I am not sure but doesn't setuid only affect script/exec or do they affect pre-start as well?!
<geekbri> So I was trying to create an upstart script that would cause the least amount of configuration file changes in the daemon itself
<geekbri> xnox: setuid and setgid effect everything in the upstart job
<xnox> ok.
<SpamapS> xnox: setuid is global
<geekbri> if you call setuid, no matter if you have something before or after it, the whole script is running as that user
<SpamapS> xnox: we've talked about having overrides per execution stanza
<xnox> geekbri: I still want to know which dir you are creating though =)
<geekbri> im creating a directory in /var/run for the daemon
<geekbri> yes i know if i run it in the foreground it shouldn't need a pid, so i may have to do all of that
<geekbri> I was just looking for ways to avoid it, as its going to cause a bunch of adding complexity and logic in the configuration file due to upstart
<geekbri> it looks like, unfortunately, I don't have a choice
<geekbri> the pid stanza is to tell upstart where it should store a pid file, not where the pidfile to read would be located correct?
<xnox> upstart and pid stanza ?!
<geekbri> http://upstart.ubuntu.com/wiki/Stanzas#pid
<xnox> geekbri: this is obsolete.
<xnox> geekbri: http://upstart.ubuntu.com/cookbook/
<xnox> there is no pid stanza any more.
<xnox> as far as I know.
<geekbri> ah ok, must have been deprecated.  That's unfortunate
<xnox> esentially none of the software write out pids correctly (together with clearing stales once and when dieing)
<xnox> geekbri: please read the new cookbook I am sure you will be enlighten on how to potentially solve your use case better.
<geekbri> Sounds like the solution is, modify the configuration file when upstart is the job control type so that it does not daemonize
<geekbri> which is what i was trying to avoid, but thats ok.
<SpamapS> geekbri: why would running in foreground cause complexity?
<SpamapS> geekbri: ahh, it doesn't have a cli option to specify that?
<SpamapS> which .. most things do
<geekbri> SpamapS: the complexity doesn't lie within configuring this thing to run with upstart so much as I am writing somethign that allows selection of the job control type (EG, upstart / initd / runit / monit) 
<geekbri> so I was attempting to try and keep the majority of the configuration changes necessary for that in the startup scripts themselves, and out of the configuraiton of the daemon itself
<SpamapS> yeah, thats what cli options are for
<geekbri> yeah, and I could move them out from the conf file to the CLI
<SpamapS> exec yourthing --foreground is pretty darn clear and simple
<geekbri> im not sure if the cli options override was in the config file, thats a good question, lets find out.
<SpamapS> always should
<SpamapS> defaults -> conffile -> cli -> runtime .. that should be how things are set
<geekbri> how things should work and how they do work, well
<geekbri> not always 1:1
<SpamapS> aye
<geekbri> Ok, one last question here.
<geekbri> oh nevermind maybe i solved it
#upstart 2013-02-28
<stgraber> jodh: hi, I noticed one pretty bad bug with the session init re-exec
<stgraber> jodh: after the re-exec, it doesn't accept dbus connections on the private bus (though according to netstat, it still listens on the socket)
<stgraber> jodh: and IIRC I was getting a "No such file or directory" error related to the re-exec in .xsession_errors
<stgraber> jodh: that was when using: dbus-send --type=method_call --print-reply --address=$UPSTART_SESSION /com/ubuntu/Upstart com.ubuntu.Upstart0_6.Restart
<jodh> stgraber: hmm. thanks. Session Init re-exec is still a TODO for me :)
<stgraber> jodh: I'm happy to take a look at it as IIRC we actually saw that one working at some point... shouldn't be too difficult to fix
<jodh> stgraber: that'd be great, thanks.
<stgraber> (I already have the upstart job to trigger the re-exec of the session init and will push it as soon as it actually works)
<jodh> any thoughts on the logrotate job?
<stgraber> jodh: looks reasonable, can't find anything obviously wrong with it
<jodh> stgraber: yeah, it's just ugly :)
<stgraber> jodh: execve("init", ["init", "--user", "--state-fd", "25", "--debug", "--restart"], [/* 34 vars */]) = -1 ENOENT (No such file or directory)
<jodh> stgraber: awesome :) better make that execvp then ;)
<stgraber> jodh: yep, just surprised that it works for pid1 ;)
<jodh> stgraber: the kernel hard-codes the path and you have to specify the full path using init=
<stgraber> jodh: ok, trying to replace execv by execvp in state.c, hopefully that'll do the trick
<jodh> stgraber: either that, or specify the full path in 59upstart.
<stgraber> jodh: we try not to do that usually (I think there's something in the Debian policy saying you're not supposed to)
<stgraber> jodh: worked!
<stgraber> jodh: will send a MP
<jodh> stgraber: great! thanks.
<stgraber> 1-char diff ;)
<jodh> stgraber: the simplest are always the best ;)
<stgraber> jodh: https://code.launchpad.net/~stgraber/upstart/upstart-fix-reexec/+merge/151050
<mayhew> Is there a cleaner way than `su` of specifying the user of the process?
<xnox> mayhew: setuid stanza, see http://upstart.ubuntu.com/cookbook/ 
<mayhew> thanks!
#upstart 2013-03-01
<stgraber> jodh: thanks!
<jodh> stgraber: thank you!!
<jodh> xnox/stgraber: any thoughts on a pithy/witty release name?
<xnox> jodh: probably the most virtual release ever
<jodh> xnox: hee hee :)
<xnox> jodh: or something more light "upstart your day!"
<jodh> xnox: haha! you should work in marketing :)
<dan2003> Is there some way to get upstart to reload its scripts? Im trying to debug a script and the only way i can get it to acknowledge changes is doing a full reboot 
<jodh> dan2003: it reloads them automatically using inotify. what does 'init-checkconf /etc/init/foo.conf' show?
<dan2003> X11 connection rejected because of wrong authentication.! ?? 
<dan2003> But i think that explains whats happening
<dan2003> this is on a system where the rootfs is nomrlaly mounted readonly and has a unionfs. as such im editing the files under /ro/etc/init
<dan2003> whilst the cahgnes are reflected under /etc/init i wonder if this breaks the inotify bit
<jodh> dan2003: it may well be. overlayfs is known to be broken wrt inotify (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/882147). However, you can always 'initctl reload-configuration' each time you change your configs.
<dan2003> ah brilliant - thanks
#upstart 2014-02-26
<deanclkclk> hello
<deanclkclk> is anyone around? :S
<deanclkclk> I need help plz
#upstart 2014-02-27
<mreynolds__> Hey all, upstart newb here trying to debug running Java
<mreynolds> Try that again, sorry.  Basically, I'm running this : script
<mreynolds>   exec /home/hub/hub/bin/start-MSR.sh
<mreynolds> end script
<mreynolds> But it doesn't seem to kick-off the script.  I'm not using nohup for the java process.
<mreynolds> This is on 12.04, so upstart 1.5
<mreynolds> pre-start and post-start work just fine
<mreynolds> (doing a simple "touch" to make sure it executes)
<mreynolds> Figured it out.  We made it too hard.  Removing shell control crap fixed ti.
<tseliot> xnox: hi, would something like this cause lightdm to wait for the service to complete? http://paste.ubuntu.com/7004530/
<tseliot> or would it just make sure that the job starts before lightdm without blocking the latter?
<tseliot> xnox: ok, it seems to block the latter: http://manpages.ubuntu.com/manpages/trusty/en/man7/starting.7.html
<gx> if you were to run an exec script inside an upstart daemon without an expect stanza, could that result in the process being abandoned and not run even though it says it is start/running still?
<gx> we're having an issue where we have a lot of daemons that are used to run a php file that polls an external API
<gx> we used to run the script using wget
<gx> but recently we switched to running the script using php itself
<gx> and since then, it seems as though the daemons are just dying, but initctl list says theyre still running
<gx> http://privatepaste.com/5ff87c1bdb
<xnox> gx: upstart will track the first exec, thus the first exec of php.
<xnox> gx: can you change exec to "exec bash -c /var/www/ok_market_history.sh" ?
<gx> i can, what does that do exactly?
<xnox> gx: what you should achieve is for: status ok_market_history, to give you the pid of your top-level bash. process.
<gx> ahh
<gx> so instead of only tracking the first php pid
<gx> that will track the bash process, and at the very least tell me when it fails?
<xnox> gx: it adds an extra exec, such that the chain is: bash -> bash -> (loop; exec php)
<xnox> gx: and upstart should then track the (middle) bash, which should be your shell script.
<xnox> gx: correct.
<gx> thanks, i'll give it a shot
<gx> as far as the daemon failing
<gx> i apologize for not understanding it well enough at this point- but is there some kind of error log?
<relisys> xnox: should we be using "expect daemon" and "respawn" stances to run the above posted script as a service daemon
<relisys> before exec
<relisys> ?
<xnox> relisys: no, not really.
<relisys> ok, tks
<gx> i guess i'm just trying to figure out why the daemon would be "failing" or stopping on its own, at all
<xnox> relisys: check the pids thought, "status" should match what you see in "ps" and it should track your bash script.
<gx> when we were doing wget instead of php -f, none of the daemons ever quit on their own, as far as i can remember
<gx> unless relisys begs to differ
<relisys> i don't remember it happening prior to that
<gx> this has strictly been happening since we started executing the php files directly as opposed to wgetting the url
<gx> thats why i'm a little confused
<xnox> relisys: gx: it all looks weird. you are best to have job just calling the php command.
<xnox> relisys: gx: and have a cron job to do "start foo" every 20seconds.
<gx> hmm
<xnox> relisys: gx: that way you only have one instance at the time, every 20seconds.
<gx> well we have it built into the script to detect if it's running or not
<xnox> relisys: gx: if that php command runs.... and eventually exits. that your job should declare "task" stanza.
<gx> if the script is active, it just exits
<xnox> relisys: gx: see upstart cookbook.
<xnox> gx: if you have it built into the script, why bother with an upstart job?!
<xnox> gx: it looks like you only need cron to kick it off || true, every 20seconds.
<gx> well for a few reasons
<relisys> we used to have it that way
<gx> #1 thats what everyone ive spoken with who's knowledgeable on the subject said we should do
<gx> #2 we're able to better monitor everything with daemons, or so we were told
<gx> #3 it's easier to start/stop using daemons as opposed to editing crontab, i guess.
<gx> feel free to argue any of those points
<gx> i'm still learning
<gx> ohh right
<gx> and a big #0 - crons only have resolution of 1 minute
<relisys> we alos wanted it to run right away again
<relisys> yeah
<relisys> xnox seems to have implied otherwise tho...
<gx> as opposed to running the script multiple times within a php loop, which would cause a whole other headache of problems
<gx> but regardless we had 0 problems with the way we were doing it, when we were calling wget
<gx> so i'm trying to understand why executing php directly would all of a sudden cause tehse issues
<gx> and as far as i can tell, the only benefit we gained is less apache2 processes used
<xnox> gx: apart from you don't have a daemon. you have a one-shot task, which you want to be periodic.
<gx> right, it's not something that's opening a socket and listening or anything like that
<gx> it's a php script that pulls from an api, normalizes some data, and inserts into db
<gx> but we want it to run every 20 seconds
<gx> and we have it built in so that if by chance it takes > 20 seconds, it detects that it's actively running, and quits, and will be run at the next free instance
<xnox> gx: so, three cron jobs exec every minute: sleep 1 && yourscript.   sleep 21 && yourscript. sleep 41 && yourscript.
<gx> xnox i understand we can do that, and we just might- but it still doesnt help me understand why the daemon would be quitting in the first place, after switching from wget to php
<gx> im more after that information than anything, for my own understanding
<gx> but yeah it's sounding like we might want to go back to cron jobs
<xnox> gx: you can do it with two upstart jobs. First job, has script stanza and does the while loop, each time it does "initctl start --no-wait main-job".
<xnox> gx: and main-job is just straing exec to php, with task stanza.
<xnox> gx: and without any bash shell wrapper.
<xnox> gx: this way you have the 20s trigger/controller job, which starts at most one worker.
#upstart 2014-03-02
<danderson> Hi folks. I'm trying to write an upstart unit, and when I try to start it with `service starbound start`, all I get is "start: Job failed to start".
<danderson> How can I get more verbose information about what upstart doesn't like?
<danderson> I can't find any obviously useful logs in /var/log
<danderson> ah, seems like it's dropped in dmesg, instead of other logs.
#upstart 2015-02-24
<Ironlenny_> I have a process that forks more than 2 times. I am using this hack (https://bugs.launchpad.net/upstart/+bug/406397/comments/44) to track the process, but it's still reporting the job as  stop/waiting even though the process is still running.
<Ironlenny_> Has anyone run into this problem?
#upstart 2015-02-27
<guillev> hi, Iâm just an upstart newbie, Iâm trying to configure uwsgi on an ubuntu 14.04: https://gist.github.com/guglielmo/38ec5f1b83f44ba0eb86, 
<guillev> service uwsgi start works ok
<guillev> service uwsgi status, after that prints stop/waiting
<guillev> service uwsgi stop tells stop: Unknown instance: 
<guillev> I know Iâm missing something
<ging> i am trying to alter the post stop script on an upstart job, i've made the changes, run initcrl reload-configuration but still it won't pick up the changes
<ging> am i missing something i need to do?
<ging> i have done that with the job totally stopped
<ging> the changes i have been making are to a conf file in /etc/init/
<ging> can you have both a post-stop exec and  a post-stop script? or would the script fail to run?
<ging> ah think that was my problem, the script that claimed to be running never actually was
#upstart 2015-02-28
<memeka> hi; how can I "exec /path/prog" as a specific user?
#upstart 2016-02-29
<HeadAche> Hello, I have a lot of upstart "Start" commands going off on bootup, and some finish in miliseconds others can take like 4 seconds -- What could be causing this?
#upstart 2016-03-01
<amfc> hi! upstart seems to have hanged my server. it's been reading enormous amounts of data from the disk  according to atop the init process read 47.1G in 3 minutes (using 98% of the disk)
<amfc> I'm at loss trying to find out why
<amfc> it already stopped reading
<amfc> I didn't do anything in particular, though
<amfc> lsof should no unusual open files (just a small log)
#upstart 2016-03-02
<chequers> hi, I'm trying to set up a new upstart service, and I've gotten it into a weird state where running 'service foo start' hangs forever, but ^C and then re-running the command returns immediately 'start: Job is already running'
<chequers> the same happens with service foo stop
<chequers> what's causing this? And can I fix it?
<chequers> it looks like upstart is trying to kill a nonexistent pid
<chequers> if i run `service foo status` i get `foo stop/killed, process 23352`, which doesn't exist
<chequers> ok, I fixed it by using this script https://github.com/ion1/workaround-upstart-snafu
<chequers> surely there is a better way??
#upstart 2016-03-03
<BlackDex> Hello there. I have a zombie process which has been started via an upstart script. How can i let upstart forget that specific pid?
#upstart 2016-03-04
<supergonkas> Is it possible to install upstart on debian and still have init.d running?
<JanC> supergonkas: if you mean use scripts inside /etc/init.d/ to start/stop services (e.g. because they don't have a proper upstart job configuration yet), then yes
<cristian_c> hello
<cristian_c> JanC: hello
#upstart 2017-03-01
<xarvis> Hi all.
<xarvis> I am getting an error with status code 2, saying the instance is respawning too fast
<xarvis> the same was working fine before the amazon aws crash
<xarvis> and when I go manually and run the command to run the server, it works fine
<xarvis> can anyone please tell me, what might I be doing wrong here?
<xarvis> so apparently issue is it can't cd into the directory whre the app s
<xarvis> *is
#upstart 2018-03-04
<outoftime_92> I stopped firefox with "Force quit" on ubuntu. Not I have zombie processed attached to /sbin/upstart --user. How to get rid of them?
