#upstart 2007-05-21
<quitte> #define HAVE_SYS_INOTIFY_H 1 is in config.h. I'm out of ideas. maybe you can see a problem in the patch here: http://bugs.uclibc.org/view.php?id=917 ?
<Keybuk> you need the functions in your uclibc as well as the headers
<quitte> the kernel headers are in place,too. 
<Keybuk> yeah, you still need the stub functions though
<Keybuk> the header declares the existance of the function, but not the function
<Keybuk> you can probably just copy the syscall stuff into a header and inline it
<Keybuk> like the nih/inotify.h thing does
<quitte> hmm. I hardly understood what you said. but I'll have a look at nih/inotify.h
<quitte> ok looking at it didn't give me any clue.
* Starting logfile irclogs/upstart.log
<|Lupin|> Hello, everybody
<|Lupin|> I am joinning the chan because it looks like upstart does not log the bot messages in /var/lob/boot, I am wondering why...
<Keybuk> |Lupin|: we had some last-minute issues with logd
<Keybuk> it turns out that when it isn't running, processes that try to output to stdout die
<Keybuk> ie. the shell running the shutdown scripts
<|Lupin|> so ?
<|Lupin|> Actually there is a file called /etc/event.d/logd
<|Lupin|> it contains a line saying 
<|Lupin|> console output
<|Lupin|> Does one have to change this line to have hte output redirected to a file rather than to the console ?
<|Lupin|> More in general, I can't find any documentation about the synta of the files under /etc/event.d
<Keybuk> the console X line does indeed set where the input/output of a job goes; you set jobs to "console logged" to have them use logd, except this is disabled in the code
<Keybuk> the lack of documentation is semi-deliberate, since the syntax isn't stable yet
<|Lupin|> ok
<|Lupin|> Keybuk: In fact what I would really like is to be able to have everything appearing on the screen at boot gathered in a file so that I can read it. Is this possible ?
<|Lupin|> Or perhaps would it be more simple to switch back to sysvinit ?
<Keybuk> there's various interesting ways to do that
<Keybuk> the logd trick is to set the console to a set of sockets that are intercepted by a daemon
<Keybuk> the disadvantage is obviously that without the daemon, the trick doesn't work
<Keybuk> an alternate trick is to use TIOCCONS to capture "console output"
<Keybuk> the disadvantage to that is that you don't know which service is doing the output
<|Lupin|> Keybuk: oh indeed the daemon is not installed...
<Keybuk> (the other disadvantage to the logd trick is that with ordinary sockets, you don't have a tty, which can adjust the behaviour)
<|Lupin|> Keybuk: I think I don't mind loosing the name of the service, as a temporary solution. But how can this solution be implemented, concretely, please ?
<Keybuk> there's not an easy answer available right now
<|Lupin|> Hmm...
<Keybuk> it turns out to be a more difficult problem
<|Lupin|> If the system remains in text mode, will I be able to rean the console with shift-pagep / shift-page-down ?
<Keybuk> yes
<Keybuk> you're obviously relying on the kernel ring-buffer size there
<|Lupin|> yes
<|Lupin|> I am wondering how I can keep the system in text mode.. ?
<|Lupin|> is it a matter of runlevel ?
<|Lupin|> I believed so, but runlevels 2, 3, 4 and 5 seem to run gdm... 
<Keybuk> remove gdm symlinks from one of the runlevels
<|Lupin|> is it all I have to do ? okay.
<|Lupin|> it worked, thantks
<|Lupin|> bye every body
<|Lupin|> thanks a lot for your assistance
<quitte> hi. is it possible that my problems compiling upstart using uclibc are related to the kernel being 2.6.13? that's the release that inotify was introduced.
<AlexExtreme> quitte, yes, you need a recent kernel
<quitte> :( ok. so it'S impossible to use it on a fritzbox without loosing support for the proprietary modules
<Keybuk> Upstart works best when you have the most event support from the kernel
<Keybuk> since if you're interested in an event-based init daemon, you're kinda inherently interested in the events to base it off
<Keybuk> the kernel's uevent interface didn't reach maturity until about 2.6.17
<AlexExtreme> yeah, it's better to have the uevent support for udev which was introduced in .17 IIRC
<quitte> ok i see. so i'd best stick with busybox init for now. maybe the vendor will update the kernel version someday, but i doubt it.
* Starting logfile irclogs/upstart.log
#upstart 2007-05-22
<__keybuk> heh
<__keybuk> NM is broken today
<AlexExtreme> nm being the program nm or NetworkManager?
<__keybuk> Network Manager
<__keybuk> it amuses me no end that X-Chat is failing to render Md's quit message correctly
<AlexExtreme> it works for me, after much charset setting changing ;)
<__keybuk> heh
<__keybuk> it gets it right, as long as you don't highlight it
<__keybuk> I prefer the chinese, anyway
<__keybuk> 
<AlexExtreme> ah, i see what you mean, that's kinda weird :p
<__keybuk> it must be a bug in the X-Chat text view widget
<__keybuk> since the GTK+ standard one does it just fine if you paste it
<AlexExtreme> yeah
<ion_> It probably doesnt view combining characters correctly. vte has the same problem.
<__keybuk> oh well
<__keybuk> today I mostly trying to define the upstart state description machine/language
<__keybuk>  *  W  - Weak until:  has to hold until  holds. The difference with U is that there is no guarantee that  will ever be verified. The W operator is sometimes called "unless".
* __keybuk goes cross-eyed at linear temporarl logic
<__keybuk> fundamentally I think we need the basic operators:
<__keybuk>   a AND b     - both a and b are true
<__keybuk>   a OR b      - either a or b are true
<__keybuk>   NOT a       - a is false
<__keybuk> and
<__keybuk>   a UNTIL b   - a is true and b is false; a resets b, b resets a
<__keybuk> it's the "reset" bit that's causing me headaches
<AlexExtreme> yes, i think those will be the only needed ones. it'd be possible to double up some operators like AND and OR, right? so i could do "a AND b AND c", where all 3 are true, and "a OR b OR c" where either one is true
<__keybuk> sure
<__keybuk> so given a primitive Event operand ("has the event happened?"), UNTIL is easy
<__keybuk> since it can reset the value on either side
<__keybuk> so   some-event UNTIL other-event
<__keybuk> when some-event happens, we "forget" other-event has happened, until it happens again
<__keybuk> at which point we "forget" that some-event happened
<AlexExtreme> yes
<__keybuk> so what happens with
<__keybuk> NOT some-event UNTIL other-event
<__keybuk> (NOT some-event) UNTIL other-event
<__keybuk> to make that clearer
<AlexExtreme> ick, that does cause headaches
<AlexExtreme> hmm
<AlexExtreme> so that's basically "run on any event that isn't 'some-event' until 'other-event' occurs"?
<__keybuk> "NOT event" would mean "event has not happened"
<AlexExtreme> ah
<__keybuk> so it means "run from when 'some-event' has not happened until 'other-event' has happened"
<__keybuk> it doesn't make any logical sense, does it? :p
<__keybuk> likewise
<AlexExtreme> absolutely non at all
<__keybuk> a UNTIL b UNTIL c
<__keybuk> makes no sense
<AlexExtreme> *none
<__keybuk> "run from a until b, until c happens; at which point a must happen again"
<__keybuk> I think it's equivalent to "a UNTIL (b OR c)"
* ion_ tries to concentrate but fails miserably.
<ion_> Whats the difference to the current complex-event-config implementation?
<__keybuk> ion_: none, that's the problem I can't work out how to move on from
<__keybuk> the other option I can see would be to do something like:
<__keybuk> have "on" be Event and AND or OR
<__keybuk> and have an additional "from" operator that's Event UNTIL Event and AND/OR on until only
<__keybuk> on foo or bar
<__keybuk> from a until b
<__keybuk> I think it's definitely worth having the concepts partially seperate
<__keybuk> e.g. the following primitives
<__keybuk> Event - has this event been seen? yes/no
<__keybuk> EventCombination - have {both of, either of} two events been seen
<ion_> Has this event been seen? true/false/filenotfound
<__keybuk> why filenotfound?
<ion_> http://worsethanfailure.com/Articles/What_Is_Truth_0x3f_.aspx
<__keybuk> that's ternary logic
<__keybuk> databases tend to use it
<__keybuk> TRUE, FALSE and NULL
<ion_> You do know the worsethanfailure website, dont you? :-) It used to be called the Daily WTF.
<__keybuk> no
<ion_> http://worsethanfailure.com/Articles/Classics-Week-How-Not-to-Parse-Command-Line-Arguments.aspx
<ion_> It contains real-life examples of code WTFs submitted by readers. :-)
<__keybuk> what's wrong with that? :p
<__keybuk> quite a cunning way to do it
<__keybuk> a lot of GTK+ uses that trick (though it wraps it with something called GQuark)
<ion_> Hehe
* AlexExtreme hates GQuark with a passion
<__keybuk> State - defines a period between two EventCombinations
<ion_> For daily laughs, i recommend subscribing to the wtf feed. :-)
<__keybuk> and then
<__keybuk> StateCombination - are we in {both of, either of} two states
<__keybuk> this doesn't seem that elegant to me
<AlexExtreme> http://en.opensuse.org/Boot_time << /me somehow thinks that that is completely unrealistic...
<AlexExtreme> they want to get the boot time down to 5 seconds
<AlexExtreme> i just don't see how that is possible
<__keybuk> heh, that seems to be getting reported a lot this week
<__keybuk> the page is over a year old!
<AlexExtreme> it is?
<AlexExtreme> hmm
<AlexExtreme> it is
<AlexExtreme> then i wonder why distrowatch are reporting it...
<__keybuk> *shrug*
#upstart 2007-05-23
<Keybuk> heh
<Keybuk> so I explained the c-e-c problem to a friend, and it broke him
<AlexExtreme> :)
<Keybuk> though he was a sufficient teddy bear for me to figure out two interesting things
<Keybuk> 1)
<Keybuk> states are more interesting than just discreet
<Keybuk> e.g. if you define a state for tty-added...tty-removed for a common NAME, then there are several questions you can answer
<Keybuk> a) does tty1 exist?
<Keybuk> b) does any tty exist?
<Keybuk> c) what is the list of ttys that exist?
<Keybuk> it turns out that all of these are interesting
<Keybuk> getty is run for each tty that exists
<Keybuk> but something requiring a network is running if any non-lo network interface is up
<ion_> Perhaps upstart should grow a scheme interpreter after all. ;-)
<Keybuk> and the fhs filesystem question can be answers with list-of-mounted-paths is a superset of list-of-required-paths
<ion_> make states scheme procedures, with a nice API for common things. :-)
<Keybuk> this really does make states first class again
<Keybuk> so a job would end up having event predicates and state predicates
<Keybuk> 2)
<Keybuk> states don't need to behave like jobs
<Keybuk> "pre-start"/"post-stop" scripts for states are all very well and pretty
<Keybuk> but in reality, they're not needed
<Keybuk> since you can just tie a job to the state, and define the scripts there
<ion_> True...
<ion_> But having them in the same file is nice.
<ion_> OTOH, you could make them separate, implicitly creating an anonymous job for each state, to which the scripts are added.
<Keybuk> I think it makes it more difficult if they're conceptually the same thing
<ion_> Perhaps add an expr stanza for scheme expressions, which could be used by any job. State would be just a job with no process; there would be no distinction from the codes point of view.
<Keybuk> the interesting thing about states is the operations on them
<Keybuk> state-is-true state args...
<Keybuk> any-state-is-true state
<Keybuk> stats-that-are-true state is-subset-of other list
<Keybuk> etc,
<Keybuk> ho-hum
<kylem> ?
<Keybuk> brain hurts
<kylem> stop poking at it
<Keybuk> heh
<Keybuk> trying to define an elegant language (and internal combustion) for when jobs should be running
<ion_> How about this? /etc/event.d/tty on tty-added $TTY ... tty-removed $TTY; instance would define a job, which also functions as a state. Other jobs/states could query whether tty is running, but they could also query whether an instance (with a certain $TTY) is running.
<ion_> In the tty-added $TTY ... tty-removed $TTY expression, the first $TTY (before ...) would be an assignment and the second $TTY (after ...) would be a comparison.
<Keybuk> a job with
<Keybuk> instance
<Keybuk> start on tty-added
<Keybuk> stop on tty-removed $TTY
<Keybuk> would be equivalent
<ion_> True. :-)
<Keybuk> so you'd end up with two basic stanzas
<Keybuk> start on/stop on, which define an event or combination of events that start or stop the job
<Keybuk> start on tty-added or serial-port-added
<Keybuk> etc.
<ion_> Anyway, that would answer to a) does tty1 exist? b) does any tty exist? c) what is the list of ttys that exist?, wouldnt it?
<Keybuk> you'd also need a second "when" stanza, that defined the other states that must be true
<Keybuk> (or maybe while)
<Keybuk> e.g.
<Keybuk> instance
<Keybuk> start on tty-added tty[1-6] 
<Keybuk> stop on tty-removed $TTY
<Keybuk> while user-can-login
<Keybuk> where there's a seperate /etc/?/user-can-login
<ion_> /etc/job /etc/state? /etc/job.d /etc/state.d?
<Keybuk> the reason this doesn't feel right to me is that you can't have different pairs of start/stop
<Keybuk> like the tty or serial-port combo
<Keybuk> you can't match the stops to the starts
<Keybuk> :-/
<ion_> on tty-added tty[1-6]  until tty-removed \1 or serial-port-added * until serial-port-removed \1
<ion_> Or $1
<Keybuk> the problem there is how do you stop them doing:
<Keybuk> foo until bar until baz
<ion_> Change
<ion_>     | cmplx_expr 'until' cmplx_expr
<ion_> to
<ion_>     | event 'until' event
<Keybuk> but then you can't do (event or event) until event
<Keybuk> which might be useful
<Keybuk> and how do you define:
<Keybuk>   any (tty-added until tty-removed $TTY)
<ion_> expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : expr_no_until | expr_no_until 'until' expr_no_until ;
<ion_> Correction:
<ion_> expr_no_until : event | expr_no_until 'and' expr_no_until | expr_no_until 'or' expr_no_until | '(' expr_no_until ')' ; expr : event | expr 'and' expr | expr 'or' expr | '(' expr ')' | expr_no_until 'until' expr_no_until ;
<ion_> For any (tty-added * until tty-removed $1), create job (state) instance; on tty-added * until tty-removed $1 and check whether it is running.
<Keybuk> whether any instance is running?
<ion_> Yes.
<Keybuk> that gets quite expensive if used a lot, no?
<ion_> Disconnect state names from the filenames, and make it possible to assign a number of state expressions to variables in a single file?
<ion_> state tty-exists = any (tty-added tty[1-6]  until tty-removed $1)
<ion_> state foo = tty-exists and writable-filesystem
#upstart 2007-05-24
<dAndy> is there a way to make up start drop privileges to a non-root user before starting the process?
<Amaranth> dAndy: that should be up to the process
<Amaranth> doesn't start-stop-daemon do that for you, btw?
<dAndy> i was under the impression that upstart made it so you dont need to use start-stop-daemon
<dAndy> but that answers my question
<ion_> This is a Unix system. I know this.
<Keybuk> :)
<Keybuk> damn, there's no event when a user is added to the system <g>
<ion_> keybuk: echo '/sbin/initctl emit user-added "$1" -eUSERNAME="$1" -eUID="$2" -eGID="$3" -eHOMEDIR="$4"' >>/usr/local/sbin/adduser.local
<Keybuk> lol
<Keybuk> I was thinking from the point of view of detecting new users and watching their ~/.? directory
<Keybuk> though I'm starting to think the /var/spool/? method might be needed
<ion_> So the users would edit their personal upstart stuff via something like crontab(1) and access control would be implemented via something like /etc/cron.{allow,deny}?
<Keybuk> dunno
* Starting logfile irclogs/upstart.log
<Keybuk> AlexExtreme: after complex-event-config
<Keybuk> which has a timeline of despair
<AlexExtreme> hmm ok
<Keybuk> since I want to get that out of the way, as it's the most important piece of the missing puzzle
<AlexExtreme> sure
<Keybuk> and still haven't reached a happy idea with that yet
<ion_> We must add some Enterprise and XML.
<ion_> And regular expressions, those will fix everything.
<Keybuk> Write it in mono!
* AlexExtreme grabs his heart and falls over :P
<Keybuk> we could use RSS to define states
#upstart 2007-05-25
<ion_> (offtopic) Yay, http://turre.com/blog/?p=102
#upstart 2007-05-26
<astro73_> how can I get upstart to reread event.d?
#upstart 2007-05-27
* Keybuk had an interesting idea last night
<AlexExtreme> oh?
<Keybuk> concerning how Status and Job interact
<Keybuk> so let's say we have a service that uses this:
<Keybuk>   while interface-up until interface-down $IFACE
<Keybuk> that defines a simple state period between an interface coming up and going down again
<Keybuk> the state would keep a record of ALL interface-up events
<Keybuk> and ALL of them would have to be cancelled before the interface could go down
<Keybuk> ie. that defines a service running while any network interface is up
<Keybuk> a simple modification:
<Keybuk>   while interface-up until interface-down $IFACE
<Keybuk>   instance
<Keybuk> this job behaves differently; now each time an interface comes up, a new instance of the job is spawned, and that instance runs until the interface it was spawned for goes down
<Keybuk> since states can be canned (and for other reasons) you'll want to be able to restrict which interfaces this is true for
<Keybuk> so you'd allow something like
<Keybuk>   state interface-is-up
<Keybuk>     while interface-up until interface-down $IFACE
<Keybuk>   end state
<Keybuk> --
<Keybuk>   while interface-is-up ~lo
<Keybuk> the other change to make is to Event
<Keybuk> I'm going to get rid of different positional and name-based variables
<Keybuk> instead it's going to have just name-based ones, but in a particular order
<Keybuk> so an event might be
<Keybuk> stopping JOB=apache RESULT=failed FAILED_PROCESS=main
<Keybuk> and for matching in job definitions, you can omit the names in order until you give the first name
<Keybuk> but the scripts won't receive any arguments, just them as environment variables
<AlexExtreme> so we won't be able do have events like "interface-up eth0", instead it would be "interface up IFACE=eth0" ?
<Keybuk> you cam omit the name provided eth0 is the first event in the list
<Keybuk> (which it would be)
<Keybuk> in effect, they become like python method calls
<Keybuk> this makes figuring out what to pass to the jobs MUCH easier ;)
<Keybuk> since there's no worry about which gets $1, $2, etc. they all get arguments by name!
<Keybuk> likewise
<Keybuk> interface-up until interface-down $IFACE
<Keybuk> is more obvious than
<Keybuk> interface-up until interface-down $1
<AlexExtreme> yes
<ion_> Sounds good.
<Keybuk> ion_: does the state/instance stuff make sense?
<ion_> In what situations would counting the number of up events and waiting for the number of down events to match is necessary?
<ion_> How about adding a new state to a running system  it would have no knowledge of recently emitted events it needs to track.
<ion_> Oh, i misunderstood the intent. Ignore the In what situations... line.
<Keybuk> not so much counting, but matching pairs
<Keybuk> and keeping track of which interfaces are still up
<ion_> Yeah, i realized that. :-)
<Keybuk> it makes a lot of sense to have a service running while at least one network interface is up
<ion_> Regarding the interface-is-up alias, id like the syntax to be more like: while interface-is-up IFACE=~lo until interface-down $IFACE, where the first part would be a fnmatch-ish match against the variable and the second part would match against the stored value.
<ion_> Something like...
<ion_> while interface-is-up IFACE=* until interface-down $IFACE
<ion_> would be equivalent to
<ion_> while interface-is-up IFACE until interface-down $IFACE
<ion_> The difference to
<ion_> while interface-is-up IFACE until interface-down IFACE
<ion_> would be that any interface-is-up ... interface-down pair would match, since the IFACE value isnt compared to anything.
<ion_> interface-down $IFACE would point to the value implicitly stored by interface-is-up IFACE
<Keybuk> I'm not sure I follow
<Keybuk> you mean interface-up (an event) not interface-is-up?
<ion_> Ah, sorry. I meant interface-up
<Keybuk> ah, you mean name the variables on the left you intend to use on the right?
<Keybuk> interface-up IFACE until interface-down $IFACE
<Keybuk> not
<ion_> Yes.
<ion_> That would allow more complex matches, such as:
<Keybuk> interface-up until interface-down $IFACE
<ion_> while interface-up ADDR=10.0.0.* IFACE until interface-down $IFACE
<Keybuk> I don't see why the IFACE bit is needed?
<Keybuk> that would work
<Keybuk> while interface-up ADDR=10.0.0.* until interface-down $IFACE
<Keybuk> ?
<ion_> True. Just store all the variables by default, so that any of them could be matched against in the until part.
<ion_> So IFACE would need to be mentioned in the first part *only* if its matched against something.
<ion_> while interface-up IFACE=~lo until interface-down $IFACE
<ion_> while interface-up until interface-down $IFACE
<ion_> while interface-up ADDR=10.0.0.* until interface-down $IFACE
<ion_> for example
<ion_> Perhaps IFACE!=lo instead?
<Keybuk> yeah, either works doesn't it
<Keybuk> actually, I prefer !=
<ion_> ADDR!=10.*
<ion_> Anyway, that would remove the need to define a named alias just to be able to give patterns. Of course, aliases might be very useful for other purposes.
<Keybuk> the named alias would be for complex things like "user-can-login"
<ion_> Yeah
<Keybuk> if state allows spawning like this, then we could have structures like for loops in there
<Keybuk> for PATH in `getmntent -fD` path-mounted $PATH until path-unmounted $PATH
<Keybuk> :p
<ion_> NEat.
<ion_> Perhaps make it block-like
<ion_> for PATH in $(getmntent -fD)
<ion_>   while path-mounted $PATH until path-unmounted $PATH
<ion_> end for
<Keybuk> that could work too
<ion_> Another idea that accomplishes the same thing a bit differently: assign the output of getmntent -fD to an array variable, and do a single while expression that matches PATH to the array.
<ion_> Also, an interface-up event might have multiple ADDR variables. It should be possible to match against any of them, or all of them.
<Keybuk> how would you define/match that?
<ion_> interface-up any(ADDR or(ADDR=127.* ADDR=::1)), where any would loop through ADDR variables and return true if any of the expressions return true. That syntax is ugly, though, but it can be improved. :-)
<ion_> (any? ADDR (or ((match? ADDR "127.*") (match? ADDR "::1")))) ;-)
<ion_> (all? ADDR (match? ADDR "*:*")) IPv6-only interface
<ion_> Just like for foo in ADDR, do something with foo, but simplified to for ADDR, do something with ADDR, where inside the loop, ADDR is the value currently being iterated.
<ion_> (blah ((mountpoints "getmntent -fD")) (any? mountpoints (eq? mountpoints PATH)))
<ion_> Im definitely not saying thats what the syntax should be, just formulating ideas about how things could be matched.
<Keybuk> I've found lisp/scheme-like syntax easier to work things out in too
<Keybuk> simply because it's already in the same shape as the necessary syntax tree to evaluate it
<Keybuk> rather than the latter
<Keybuk> uh, rather than the humanish way of putting it
<Keybuk> what does the mountpoints thing do?
<ion_> Um, just assigns the output of the command to an array variable. Then the arrays compared to the PATH variable.
<ion_> mountpoints.any? {|dir| env[:PATH]  == dir }  # Ruby syntax :-)
* penguin42 yawns
<penguin42> I fancy adding a --host to the reboot/shutdown/halt utilities to check that the host you specify is the one you think you are trying to shut down
<penguin42> I was also considering requiring it if it's run from a tty - anyone have strong views?
<Keybuk> heh
<Keybuk> interesting patch ;)
<penguin42> one too many halts of the wrong machine :-)
<penguin42> I can't think of anything shorter than --host that would work on all of reboot/shutdown/halt
<Keybuk> you'd need to give the hostname
<Keybuk> shutdown -h quest
<penguin42> yeh exactly
<penguin42> except shutdown already has a -h for example
* penguin42 will put something together - where is a good  place to send the patch?
<AlexExtreme> the bug tracker at launchpad probably
<penguin42> oh ok, I hadn't realised people used launchpad for patch stuff as well
<Keybuk> penguin42: upstart-devel@lists.ubuntu.com
<Keybuk> or launchpad, yeah
<Keybuk> if you prefer, make a bzr branch of upstart and upload your branch to LP
<penguin42> ok, I'll probably launchpad it since I've already got a launchpad account; probably just a patch for the moment unless I fancy figuring out the branch stuff
<Keybuk> :)
* AlexExtreme loves bzr :P
<Keybuk> yeah, it's not terrible
<penguin42> is bzr yet-another-source-code-control thing?
<AlexExtreme> yep
<penguin42> Why does 'reboot' scan only ide discs to power them down?
<Keybuk> penguin42: it doesn't even need to do that
<Keybuk> originally it was because the code was copied from sysvinit, and only ide disks existed then
<AlexExtreme> now the kernel automatically does it
<penguin42> ah ok
<penguin42> reboot does seem to have a small random selection of clean up things in it
<Keybuk> yeah
<Keybuk> our goal is to eliminate both
<penguin42> anyone good with man macros; .BR -m, --host \fI  HOST     doesn't seem to want to render a space before HOST
<Keybuk> I tend to just quote things
<penguin42> that's still getting me  -m,--hostHOST
<Keybuk> .BR -m ", " --host \fIHOST
<Keybuk> ?
<penguin42> yeh but it's the space after '--host' I can't get to happen
<penguin42> let me try a " "
<Keybuk> "--host " ? :p
<penguin42> yeh that's done it
<penguin42> typesetter being too smart for its own good :-)
<penguin42> ok, #117215 
<ion_> I learned a new word from Futurama: oughtnt :-D
<cortana> i learned "unpossible".... i don't think that's a real word tho
<Keybuk> heh
#upstart 2008-05-19
<sadmac> Keybuk: just sent an email to our dbus maintainer to get those patches in rawhide
<Keybuk> who's that?
<sadmac> David Zeuthen
<Keybuk> lol
<Keybuk> I'll nag him tomorrow ;)
<sadmac> very nice
<sadmac> He's in westford too :)
<sadmac> I'll have to bring one of those paper fans.
<sadmac2> Keybuk: good morning
<Keybuk> afternoon
<sadmac2> well, you're closer to GMT, so we'll use your clock
<sadmac2> restarting dbus on a running system = epic fail
<Keybuk> yes
<sadmac2> Keybuk: that reminds me, if I SIGTERM or otherwise force upstart to re-exec, will it transfer job state to the new instance?
<ion_> s/(?:restarting | on a running system)//g
<sadmac2> ion_: ORLY?
<ion_> YA
<sadmac2> Keybuk: the test case make targets don't seem to run the dbus code generator as a dependency
<suihkulokki> sadmac2: dbus should do that.. dammit if it is possible to transfer the irc server connections when upgrading irssi, bloody well something as critical as dbus should do that as well
<sadmac2> Keybuk: and yes, your patches seem to fix things.
<sadmac2> your dbus patches that is
<sadmac2> Keybuk: wb. Just added another patch to my branch
<sadmac2> rearranged some conditional logic in job_class_reconsider
<sadmac2> Keybuk: I see the foo ? TRUE : FALSE; construct in a lot of places. Is Upstart code so sensitive to precise values of TRUE that this is necessary?
<EvanR> hey i just got upstart working on my system, many services are started using the existing sysv scripts... however my scripts print messages during startup like 'samba started.... [OK]', and these get messed up with upstart
<sadmac2> EvanR: what platform?
<EvanR> linux
<sadmac2> EvanR: what distro rather
<EvanR> its mostly blfs
<EvanR> with upstart it will be a lot less like blfs
<EvanR> i am about to start moving all the stuff in /etc/rc.d/init.d to event.d scripts
<EvanR> is there a best practice for printing out status messages like that ?
<EvanR> or is it all automatic
<sadmac2> no practice for printing out messages from job defs
<sadmac2> dunno why the ones in init.d wouldn't work right. something to do with the FD upstart is passing to the job
<EvanR> does upstart do things in sequential order, or is multi-thread-like stuff going to affect the messages ordering
<sadmac2> upstart is paralell, but when it is emulating sysv (at least, with the standard jobset which does this) it runs the sysv jobs in serial
<EvanR> i have the example jobs which do rc* compatability
<sadmac2> yes. those will use your /etc/rc script to run the sysv jobs.
<EvanR> lets say that i convert all my stuff to event.d ... is there a common / best / popular way to implement the runs levels, or is the recommended strategy something different in the upstart worl
<EvanR> like... x-mode text-mode single-user mode events or something
<sadmac2> upstart does not, by default, use runlevels
<EvanR> is the concept of runlevels a purely sysv init thing or what
<sadmac2> the replacement for them is kind of up in the air with 0.3.9
<sadmac2> 0.5 should see some better mechanisms to deal with different modes.
<EvanR> does it take a specific kernel parameter as input
<EvanR> how would i get to single user mode in emergency
<sadmac2> Kernel parameters can be gotten at any time from anywhere by reading and parsing a certain proc file. you can do it yourself in a shell script with sed
<EvanR> ok so theres no standard
<sadmac2> you can have a single job starting on startup that parses kernel parameters from /proc and then triggers another event depending on the result
<sadmac2> that would do it.
<EvanR> what does ubuntu do at the moment
<sadmac2> I believe ubuntu is still largely in sysv-compatible mode.
<sadmac2> though theres a couple community projects that make it use more of upstart's functionality
<EvanR> so back to the issue of bootup status messages, you say its all parallel, whats a good strategy to get those message shown
<sadmac2> echo from within the scripts has worked for me. I don't know why you would have issues.
<EvanR> ok ill try to get deeper into what is going wrong
<EvanR> trying to write a job for samba. script /usr/sbin/smbd; /usr/sbin/nmbd; end script starts, but immediately stops (leaving the daemons running). what am i doing wrong
<EvanR> /usr/sbin/smbd -D; /usr/sbin/nmbd -F; leaves the job running but sort of hangs the start command, and then stop kills nmbd but not smbd
<EvanR> perhaps i should have smbd and nmbd in two separate jobs
<sadmac2> EvanR: you need the "respawn" or "service" stanza in your job definition.
<sadmac2> and you don't want any of your services to daemonize
<sadmac2> so --nodaemons all around
<EvanR> ok so i should do
<EvanR> /usr/sbin/smbd -F &
<sadmac2> no &
<sadmac2> if you use respawn, then start won't hang
<EvanR> i would rather have these two servers controlled by one job
<sadmac2> No. They should be separate
<EvanR> hmmmm
<EvanR> so i have jobs smbd and nmbd, i would like to be able to say # start samba, stop samba
<sadmac2> # start smbd
<sadmac2> (nmbd then figures out it needs to be running and runs)
<EvanR> ok
<EvanR> respawn doesnt sound right
<sadmac2> you'll just add a "start on started smbd" line to the start of the nmbd job
<sadmac2> respawn means if it crashes upstart will bring it back. If you don't want that, then use "service" in stead.
<EvanR> oh, service and respawn are mututally exclusive?
<sadmac2> respawn implies service
<sadmac2> and actually, your job definition script should end in an exec
<sadmac2> so "exec /usr/sbin/smbd -F"
<EvanR> i have that
<EvanR> and for nmbd
<sadmac2> right
<EvanR> well service before that
<EvanR> and "start on started smbd" "exec /usr/sbin/nmbd -F"
<sadmac2> right
<EvanR> the start on stuff makes things automatic, but what if i want to start jobs conditionally, given what happens in the script of another job
<sadmac2> like when?
<EvanR> ...........dunno
<EvanR> :P
<EvanR> i cant think of a reason
<sadmac2> If there's no use case, there's probably no way to do it. If a use case appears, we'll probably think of a way to do it :P
<EvanR> to disable services at bootup, one would comment out the 'start on' stuff...
<bochecha> hi!
<sadmac2> yes
<EvanR> heh
<bochecha> just came to point a typo on the upstart main site: in the "know users" section, it's written "Fedora Rawhide". It should be "Fedora 9 and above" as Fedora 9 was released :)
<bochecha> not really important, but I saw it while searching for infos about upstart
<sadmac2> Yes it was :)
 * sadmac2 pats himself on the back
<bochecha> Anyway, upstart seems like a great project. Keep up the good work!
 * bochecha goes back to read some doc to understand better how it works
<EvanR> my dbus sysvinit stop script is testing the exit status of the killed daemon to determine whether it should remove a file
<EvanR> is that possible to do from the post-stop script
#upstart 2008-05-20
<EvanR> it doesnt seem that the commonly available dhcpcd dhcp client has an option for no daemonize
<EvanR> dhclient does, according to some online man pages, but i cant seem to get the source
<catsup> you can't find the source for dhclient?
<EvanR> no
<EvanR> is it on the first link on google to 'ISC DHCP', that doesnt work
<EvanR> debian seems to keep the other dhcp client packages
<catsup> http://packages.debian.org/source/etch/dhcp
<catsup> that builds the package dhcp-client that contains the dhclient that accepts -d not to daemonize
<catsup> (you don't have to build the package, the original tgz is there)
<catsup> iirc pump doesn't need to daemonize
<catsup> also
<EvanR> hmm.
<EvanR> by the way, when you see a .orig.tar.gz file at the debian site, is that the original source, or the source which is possibly changed before being built and packaged
<catsup> that's the original source
<catsup> from upstream
<catsup> all debian changes are in the .diff
<EvanR> ok. well it is hell to build :)
<catsup> is it?
<EvanR> and no way to direct the installation prefix
<EvanR> as far as the reame is concerned, at least
<EvanR> readme
<EvanR> i think im going to check out pump 
<EvanR> bah id hate to use non standard tools :(, stupid dhcpcd
<catsup> pump is nonstandard??
<catsup> ISC seems to consistently produce crap
<EvanR> is dhclient the standard on debian/ubuntu/mepis? because dhcpcd is on all of them, though on the bsd's it is a different dhcpcd i think
<catsup> i really don't understand how they continue to exist
<EvanR> dhcpcd on the other linux distros*
<catsup> well i think that all of debian's dhcp clients are named dhclient
<catsup> but the ISC one is the one on the netinst install cd
<catsup> at least for the last couple versions
<EvanR> actually, i think the dhcpcd in *bsd is the ISC one to....
<EvanR> or based on it
<catsup> well, ISC tools are very popular
<EvanR> hmm. interesting
<catsup> pump was made by redhat.  i used to use pump.  it works fine.  it's not like a dhcp client is a very complex thing.
<catsup> ISC has managed to fuck theirs up, though
<catsup> with their configure script
<EvanR> and whatever the normal one is, thats fucked up too, no --no-daemonize ?
<catsup> normal one?  eh?
<EvanR> the one i have, the one in the slackware distro, the one in the lfs book...
<catsup> by the way
<EvanR> dunno what mandrake had
<catsup> i just downloaded the ISC dhcp source
<catsup> edit Makefile.conf to configure it
<EvanR> have you tried to build it yet
<catsup> no
<EvanR> see if it crashes
<catsup> crashes??  you mean the binary?
<EvanR> no, the build process
<catsup> ok i built it
<catsup> what crashed?  gcc?  how?
<catsup> segv?
<EvanR> no, it didnt crash gcc, it just failed to compile
<EvanR> i have been fixing typos in code all week for some reason
<EvanR> if you built it, it might be a lack of dependencies
<catsup> it compiled fine for me
<catsup> what was your error?
<EvanR> a long line of errors, and i was so fed up with ISC i deleted the source dir and the package
<catsup> heh
<catsup> good for you
<catsup> read the pages about ISC BIND on djb's web site some time
<catsup> http://cr.yp.to
<EvanR> thats they one everyone uses right, bind9
<EvanR> with the reputation
<catsup> no
<catsup> not everyone uses it...
<catsup> but yeah it's very popular
<catsup> not apparently because of people making choices though, much less intelligent people making informed choices...
<EvanR> grrr. the openbsd dhcpcd server only comes as a binary, or as part of a 100M source distro
<EvanR> dhcp client*
 * EvanR smash furniture
<catsup> um
<catsup> try the other clients from debian
<EvanR> pump
<catsup> yeah pump is probably what you want.  pump was written by redhat.  i'm sure it doesn't suck.  i used to use it, although that was probably 5 years ago.
<EvanR> seems to require 'newt.h'
<catsup> what distro are you using?
<EvanR> uhm it produced a binary even with all those errors
<EvanR> seems to be working
<EvanR> its a custom distro
<catsup> i thought newt was an ncurses gui library
<catsup> pkgdesc="Not Erik's Windowing Toolkit - text mode windowing with slang"
<EvanR> i have ncurses, no newt.h
<EvanR> lol nice
<EvanR> that must be for an optional pump 'gui'
<EvanR> called 'netconfig'
<catsup> oh, i found a new section of djb's web site.  this guy is hilarious.  http://cr.yp.to/uic.html
<EvanR_> bah
<EvanR_> can pump not no-daemonize
<catsup> if you're building the source it shouldn't be hard to make the change
<catsup> just find the call to daemon
<EvanR_> thats what i was thinking
<EvanR_> except doing it for dhdpcd :)
<EvanR_> with suitable spelling fixes
<EvanR_> dammit, the isc dhcp site works in firefox, it was my ipv6 configuration :(
 * EvanR_ smashes furniture
<catsup> ha
#upstart 2009-05-19
<pwnguin> is there a list of known upstart events in ubuntu 9.04?
<ion_> http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot âAt debconf7 and FOSDEM 2008 (video link), Petter Reinholdtsen gave a talk about the dependency based boot system.â Not even a mention of Upstart. :-P
<Keybuk> that's Petter for you
<ion_> He mentioned that âLinux is becoming more and more event-based but the system startup is sequential, but thatâs an issue for another talkâ (paraphrased).
<Keybuk> :)
<ion_> Btw, how far along is Upstart 0.next? :-)
<Keybuk> the upstart bits are still pretty much untouched :p
<Keybuk> today I am mostly hating D-Bus
<sadmac> Keybuk: what did it do? Show us on the bear where glib touched you
<Keybuk> ;)
<Keybuk> just damned hard to do signals properly
<sadmac> yeah, they didn't look fun
 * sadmac has been thinking about thread-safe linked lists for libnih
<sadmac> I don't know why, we don't need them right now
<sadmac> but massively-concurrent linked lists are hard.
<Keybuk> indeed
<sadmac> and it makes the list heads bigger (need a semaphore). Might want the thread-safe ones to be a different type.
<Keybuk> put the mutex in the list head
<Keybuk> that's the usual pattern for locking linked list changes
<Keybuk> it's not record-level, but it's enough
<Keybuk> record-level, you're just asking for deadlocks
<sadmac> I can do nearly record level with no deadlocks
<sadmac> the trick is don't lock the nodes. Lock the links
<sadmac> each node has a lock that protects its next pointer and /the next node's prev pointer/
<sadmac> you only have to acquire two locks for each structural change. its juuust this side of safe
<sadmac> it only can lock if its possible to call remove() on the list head itself (dining philosophers). I think I can fix that.
<Plouj> hi
<Plouj> does upstart have the ability to log to syslog all of the boot messages instead of to the console?
<Plouj> well, not necessarily to syslog, but somewhere permanent and not initially user-visible
<pwnguin> is there a list of known upstart events in ubuntu 9.04?
<sadmac> pwnguin: Fedora has a manpage. I think its available on die.net
<pwnguin> hmm. no network event?
<sadmac> pwnguin: no. stuff like that should be emitted by other system services. you might want to look into having network manager do it.
<sadmac> anything that can call `initctl emit` can emit an event
<pwnguin> well, i really dont care if upstart itself emits an event versus given system service
<pwnguin> i will look into NetworkManager though
<sadmac> Plouj: there's nothing like that just yet. We've planned it though. Even tried it a few different ways. Its not as easy as it would seem to get right.
<sadmac> Keybuk: do you have any plans as to making logging work?
<Plouj> sadmac: can you tell me of some of the difficulties that you encountered?
<sadmac> Plouj: well, we didn't want init to funnel all of the text traffic from all the services for resource reasons (that was Keybuk's logic. He can explain that) so we had our own logging service to transfer the info. The problem was when that went down it ended up SIGPIPEing everything connected to it, resulting in a pretty spectacular system failure.
#upstart 2009-05-20
<anandology> does upstart writes info/error log some where?
#upstart 2009-05-21
<damjan> can I have a job that starts a program with another user-id and not 0/root?
<damjan> and I guess my question is about 0.3.9 since it's an Ubuntu JeOS instalation I must use
<damjan> or do I just use "su" ??
<damjan> can I make a job start when /dev/vc/8 appears?
 * JamesB192 make a stupid sugestion until someone smart talks, 'write a script to continuosly check for the device file and send and initctl emit when it arrives. or better listen to udev events and initctl as indicated.'
<JamesB192> note that I do not cuurently use upstart, nor have I ever learned to use it correctly.
 * sadmac2 didn't see the problem
<JamesB192> two questions how to run a task from upstart as another user and how to start a task on the appearance of a device. damjan asked those.
<sadmac2> damjan: 1) su 2) write a udev rule to run initctl emit
#upstart 2009-05-22
<MarcWeber> Which is correct shutdown behaviour? stop all jobs , sync and run halt? Or is there kind of special initctl shutdown all command?
<sadmac2> MarcWeber: no special command I know of 
#upstart 2009-05-23
<MarcWeber> sadmac2 man shutdown explains all. first the shutdown event is generated then (halt,power-off,reboot,..)
#upstart 2010-05-24
<mezcalero> Keybuk: seen my mail?
<mezcalero> Keybuk: do you have a patch for a poor little soul like mine?
<Keybuk> yup, just replied
<Keybuk> haven't got the patch to hand, but will send it across when I find it
<sadmac> damn. I always have something I need to say to Keybuk until he's around.
<Keybuk> no, you misunderstand
<Keybuk> I stay away from you when you have something to say to me :p
<ion> Hah
<sadmac> that too
<sadmac> Keybuk: so my ratty little C parser generator can parse a DSL implementation of itself and make a much nicer implementation of a parser generator. That can then parse that grammar again and make a nicer still implementation. The third time through I get a parser generator that doesn't work.
<sadmac> Keybuk: so I'm almost done debugging for the 3rd time.
<ion> Hehe
<Keybuk> which iteration gives you skynet? :p
<sadmac> Keybuk: well if the 3rd one doesn't manage to output its own source code verbatim we call it a bust.
<sadmac> the good news is if it compiles we can ship it. Full code coverage just by building it.
#upstart 2010-05-25
<hrw> hi
<Keybuk> hrw: hey, how's it going?
<hrw> moment, waiting for ogra
 * ogra_tb waves
<hrw> Keybuk: we want to add extra service to upstart
<hrw> Keybuk: http://marcin.juszkiewicz.com.pl/tmp/ogra/ogra.tar.bz2
<ogra_tb> Keybuk, though for upstream inclusion i'm recommending to not use root autologin indeed :)
<Keybuk> explain?
<hrw> Keybuk: it allows to start getty on serial console given by kernel cmdline. useful for ARM people mostly but I think that there will be other users too
<ogra_tb> Keybuk, it [arses console= and if it finds a serial definition it spawns a serial getty
<ogra_tb> *parses
<hrw> Keybuk: by default service is disabled and user can define which tool to run (so can be autorootlogin or normal getty/login combo)
<ogra_tb> so we dont need to manually add a ttyS*.conf file all the time
<Keybuk> you don't need to parse /proc/cmdline for that
<Keybuk> I think you can just put in "env console" and read $console
<ogra_tb> on arm you usually use multiple console args
<Keybuk> which one wins?
<ogra_tb> first console is usually serial, second is a tty
<hrw> "console=tty1 console=ttyS2" like
<ogra_tb> the second one
<Keybuk> I think that works with the environment variables too
<ogra_tb> as soon as the kernel has uncompressed it switches to the second console
<ogra_tb> so for debugging you usually need serial
<ogra_tb> for login you then get the second one ... if you also want a login prompt on the first defined console yu need to create an init .conf file
<ogra_tb> the code above avoids that
<Keybuk> unsure which one the kernel passes as $console to init
<ogra_tb> the second one i think
<hrw> but it also checks is there a service for console and exit if there is
<ogra_tb> root@touchbook:~# env |grep console
<ogra_tb> root@touchbook:~# 
<ogra_tb> hmm, where would that variable exist ?
<Keybuk> in pid 1's environment
<ogra_tb> ah
<Keybuk> unless it doesn't, of course
<ogra_tb> so apart from the parsing of cmdline, would you think such an addition would be possible upstream ?
<Keybuk> not in its current form, no
<ogra_tb> (/me disagrees with the way of calling an external binary though, i'd just use an upstart script/end script section here)
<Keybuk> it should be possible to do it without the script in /bin
<ogra_tb> heh
<Keybuk> and definitely without anything in /etc/default - which is a complete violation of Upstart policy ;-)
<ogra_tb> well, i want the serial detection 
<Keybuk> plus it doesn't take into account when the device is ready
<ogra_tb> the arm project guys want to additionally have a root autologin for their images
<ogra_tb> that caused the default file
<ogra_tb> i think the serial detection is a valid upstream addition while the rootlogin should be a project thing
<hrw> so I will check value of $console
<ogra_tb> init will likely only see the second one, but test it
<ogra_tb> Keybuk, the device has to be ready anyway, the kernel messaages go to the serial consolle 
<ogra_tb> -l
<hrw> even with one entry I got empty value for "echo $console >>/tmp/test" in /etc/init/auto-serial-console.conf
 * ogra_tb hates the touchbook kbd with passion
<Keybuk> ogra_tb: not necessarily
<ogra_tb> well, for our kernels at least we can rely on having serial console support built in
<Keybuk> sure, you can ship that in Ubuntu ;-)
<hrw> Keybuk: and we can add "[ ! -f /dev/$tty ] && exit"
<Keybuk> hrw: that would be a race condition
<hrw> ok
<ogra_tb> so with devtmpfs we can be sure the device exists from the start
<Keybuk> no you can't, the console device driver may not have been loaded yet
<hrw> Keybuk: unless it is in-kernel?
<ogra_tb> doesnt that get loaded as fisrt thing by the kernel ? 
<Keybuk> hrw: for something upstream, I can't rely on that guarantee
<Keybuk> the kernel will cause (via kmod) a char-major-x style probe the first console message that needs to be emitted
<Keybuk> it may be sometime before userspace responds to that
<ogra_tb> yeah, its far before userspace
<Keybuk> no it isn't
<ogra_tb> kernel messages are output right after uncompressing where would there be userspace ?
<Keybuk> what kernel messages?
<ogra_tb> all stuff that ends up in the ringbuffer
<ogra_tb> from line 1 on
<Keybuk> what stuff?
<ogra_tb> all kernel output
<Keybuk> there is no kernel output in Ubuntu by default ;)
<ogra_tb> /var/log/dmesg if you want it like that :)
<hrw> Keybuk: by default there are many things in other way
<ogra_tb> with queit its indeed quietened down, but the device should exist at that point regardless
<Keybuk> why should it exist?
<Keybuk> what will make it? :p
<ogra_tb> because there is output directed to it 
<ogra_tb> the kernel
<Keybuk> no it won't
<Keybuk> because the driver won't be available
<Keybuk> etc.
<ogra_tb> hmm
<ogra_tb> so what do you propose 
<ogra_tb> having a package with just one .conf file ?
<Keybuk> yes
<ogra_tb> hmm
<hrw> Keybuk: no chance to integrate it into upstart then?
<Keybuk> not in its current form, no
<hrw> so which suggestions for changes?
<Keybuk> needs to be a single upstart .conf file, with the desired console available to upstart itself so that the "start on" bit can reference it
<ogra_tb> i doubt you can change it in a way that would please Keybuk 
<ogra_tb> since you cant know if the device exists at the point you need to know it
<Keybuk> sure you can, there are events for that
<hrw> Keybuk: single conf file is easy. but on my beagleboard $console var is empty
<Keybuk> hrw: may require kernel and/or upstart patches to make it work
<hrw> week ago I used sysvinit
<hrw> and was happy with it ;D
<Keybuk> go use that then
<hrw> Keybuk: then this system will not be *buntu
 * ogra_tb doesnt want to add sysvinit stuff to ubuntu :)
<ogra_tb> andd i really want the automatic detection stuff 
<Keybuk> so stop whining then - if you want to do something properly, do it properly
<Keybuk> figure out why the kernel doesn't tell userspace which console it's created, etc.
<Keybuk> and fix that
<Keybuk> we have a kernel team, they'll help you get the patch upstream too
<Keybuk> so everyone can benefit
<ogra_tb> yeah
<hrw> mkey
<ogra_tb> just more time consuming
<Keybuk> yes, it takes time to do things properly
<Keybuk> that's not an excuse
<ogra_tb> i didnt mean to use it as one :)
<hrw> neither did I
<ogra_tb> though the arm project guys might have some time pressure
<Keybuk> we're trying to make the best *Operating System* that we can
<ogra_tb> not sure about their timelines
<Keybuk> so it's important to think about everything and do it the right way
<ogra_tb> indeed
<hrw> btw - /etc/init/tty1.conf autoassumes that /dev/tty1 exists?
<Keybuk> that job isn't shipped upstream ;)
<ogra_tb> oh, but its in our upstart package
<Keybuk> right
<Keybuk> we have patches to upstart ;)
 * ogra_tb wasnt aware you add patches :)
<Keybuk> but again, I think this is just something you should ship yourselves in your own packages for now
<ogra_tb> so once we have a reliable way to detect the device you would be willing to ship it too ?
<Keybuk> yup
<ogra_tb> ok
<Keybuk> once the "start on" can reference the detected console device, I'm happy
<ogra_tb> good
<ogra_tb> we'll hunt down the kernel team for it then 
<Keybuk> it may be fixed as part of the "pass all options to init" patch
<ogra_tb> though it will be tricky since we only want certain console devices
<ogra_tb> that patch reads the cmdline ?
<ogra_tb> or the kernel events 
<Keybuk> that patch is in the part of the kernel code that generates init's cmdline from its own
<ogra_tb> ah
<ogra_tb> yeah, then we should have $console ... the question is just which one we get :) 
<ogra_tb> at the pointinit starts the first console entry will be ignored already
<ion> keybuk: Howâs Upstart 10âs sysvrc loader going to know whether an init script is a task or a service, btw?
<ion> Just wait until the main process returns with zero and if it has left any children running, itâs a service?
<ion> I take it respawn wonât be used for that stuff?
<Keybuk> consider the start and stop bits equivalent to pre-start and post-stop
<Keybuk> so they always hold up running/stopped
<ion> So Upstart wonât track any child processes they left behind at all?
<Keybuk> yeah it will
<Keybuk> "equivalent to"
<ion> Ok :-)
<Keybuk> process tracking is a bit different in 0.10
<zer0c00l> How do i use upstart to restart a crashing application?
<zer0c00l> For example transmission-daemon
<JanC> respawn
<zer0c00l> ok
<zer0c00l> Read the docs
<zer0c00l> JanC: thanks 
<zer0c00l> JanC: I read http://code.alexreisner.com/articles/upstart.html
<JanC> in recent versions of upstart you have to put de .conf file in /etc/init/ and not /etc/event.d/ though
<zer0c00l> JanC: ok :)
<zer0c00l> JanC: I don't see /etc/init/ in my system
<zer0c00l> JanC: i am using Fedora 12, /etc/init.d/ is available
<JanC> zer0c00l: it depends on what version of upstart you use, older versions had /etc/event.d, newer have /etc/init, and I don't know which one Fedora 12 has
<zer0c00l> JanC: it has 0.3.11
<JanC> then it's still event.d
<zer0c00l> JanC: ok 
<zer0c00l> JanC: I  just followed that blog post , I am getting some issues, http://fpaste.org/JFC4/
<JanC> it needs a *.conf filename
<zer0c00l> JanC: works :)
<zer0c00l> Great Thanks
<zer0c00l> JanC: One doubt, whether it the process will be monitored an restarted after a reboot?
<zer0c00l> s/it/
<JanC> if you want to be sure, try it  âº
<zer0c00l> JanC: Ok ;)
#upstart 2010-05-26
<sadmac> Keybuk: I have this gdb python extension with a few odds and ends from debugging the parser. Where in libnih's directory structure should I put something like that?
<Keybuk> contrib or something?
<sadmac> Keybuk: done
<hazmat> is there a way to put upstart into verbose mode from a configuration file?
#upstart 2010-05-27
<tstone> hi, is there a way to get dbus signals as events in the upstart daemon?
<Keybuk> fairly trivially with some python
<tstone> this is for a embedded device and i don't have any python on that :-(
<tstone> i have seen there is s.t. like a upstart-udev-bridge under lucid, would this be a good template to get this 
<Keybuk> C?
<Keybuk> yeah, exactly
<tstone> functionality into dbus
<Keybuk> you connect to the bus, add a match on the signal, and when you get the signal, you make a method call to Upstart to emit the event
<tstone> so it might also be possible to use the upstart dbus interface to emit a new event?
<Keybuk> it is
<Keybuk> com.ubuntu.Upstart0_6.EmitEvent
<Keybuk> http://upstart.ubuntu.com/wiki/DBusInterface
<tstone> nice, i think i will use the dbus interface, thanks
<tstone> i have btw. integrated upstart into ptxdist.org which is a build system for embedded systems.
<tstone> i am planning to get the patches upstream.
<Keybuk> cool
<tstone> good bye
<Linicks> I would like to start the unicorn web server for my rails environment at stat startup as a specific user.  Can you point me in the right direction?
<Linicks> I have found docs for creating startup commands with exec, but nothing that specifies the user 
<ion> For now, use su.
<Linicks> ok, will give that a try. thx
<Linicks> created a configuration file ( http://pastie.org/980315) in /etc/init.  But I'm not sure how to test it.  I tried -- sudo start priver -- but get --- start: Unknown job: priver
<Linicks> per the docs here : http://upstart.ubuntu.com/getting-started.html
<Linicks> I'm sure I'm missing something simple.
<Linicks> ion: any ideas?
<ion> 0) Unicorn is a service, not a task. 1) Running su in a pre-start script has no effect on the exec. (Btw, you can use ; instead of && since the script is run with set -e.) 2) The specific problem that caused Upstart not to recognize the job at all is a syntax error (as youâll find in your syslog), namely that âpre-start blahâ is invalid syntax; youâd use âpre-start exec blahâ or a pre-start script.
<ion> exec su -c 'set -e; ...' username, or something like that
<Linicks> ion: Thanks! I will work on that and see if I get any further :)
<ion> exec su -c 'set -e; cd PATH; exec unicorn_rails blahblah' username, where the parameters for unicorn_rails make it not daemonize/fork.
<ion> Also, you probably donât want it to start on startup, but instead when thereâs a writeable filesystem etc.
<ion> âstart on filesystemâ may or may not suffice.
<Linicks> ion: Making some headway!  But when I run the job --> start priverpriver  I get --> start/running, process 4954, but the process isn't in the process list.  I've tested this --> set -e; cd /home/prweb/priver_002/; unicorn_rails -p 59504 directly on the command line and it works.
<ion> unicorn_rails probably forks then. Youâll need to make it not fork/daemonize. :-)
<Linicks> I think by design unicorn creates a fork(s).  Would it be better to use script instead of exec, if thats the case?
<ion> Thatâs not relevant.
<ion> Judging from http://unicorn.bogomips.org/unicorn_rails_1.html, it shouldnât daemonize without -D. Dunno why it does, then.
<Linicks> Ok, so that I understand this a little better, why can't it start as a daemon?
<ion> What does status priverpriver say?
<Linicks> status: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<ion> Your dbus service seems to be dead. Try sudo status priverpriver for now.
<Linicks> sudo status priver --> priver stop/waiting
<Linicks> Just as an FYI, I'm on a new Ubuntu 10.04 server install with all current updates.
<ion> If you run unicorn_rails -p 59504 from the command line, does it daemonize or stay in the foreground?
<Linicks> it stays in the foreground.
<Linicks> Here is the example output from my test server --> http://pastie.org/980495
<ion> Ok, so daemonizing is not the problem.
<ion> Please share your current job definition.
<Linicks> Here is my current def --> http://pastie.org/980518
<ion> (You may want to change â...; unicorn_rails ...â to â...; exec unicorn_rails ...â, but thatâs not the problem here, it just doesnât leave an extra shell process running that way.)
<ion> script
<ion>   exec >/home/prweb/priver_002/job.log 2>&1
<ion>   set -x
<ion>   exec su -c 'set -ex; cd /home/prweb/priver_002/; exec unicorn_rails -p 59504 --host 192.168.1.15' prweb
<ion> end script
<ion> Try that. Anything interesting in job.log?
<Linicks> This was in the log -- bash: line 0: exec: unicorn_rails: not found 
<Linicks> It doesn't seem to be getting the users environment ?
<ion> Ok, try /path/to/unicorn_rails
<Linicks> I tried it with the full path to unicorn_rails, and I'm getting the same results..
<Linicks> Of course everything works correctly when I execute the command directly from the shell.
<ion> It says âexec: /.../unicorn_rails: not foundâ?
<Linicks> Getting this in the log --> /home/prweb/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/site_ruby/1.9.1/rubygems.rb:779:in `report_activate_error': Could not find RubyGem unicorn (>= 0) (Gem::LoadError)
<ion> Ok, youâll need to insert a command to load the rvm environment before executing unicorn_rails.
<ion> exec su -c 'set -e; . /home/prweb/.rvm/scripts/rvm; exec ...' prweb
<ion> it seems
<Linicks> Excellent!!! That finally did the trick.. Couldn't have done this without you help.  Many, Many Thanks!!!   
<Imperion> um
<Imperion> I'm trying to boot up Linux on a USB stick with Upstart as the init daemon
<Imperion> but for some reason, it's not doing any jobs nor listening for ctrl-alt-del (it doesn't trigger a reboot)
<Imperion> it seems like it dies right after startup
<Imperion> any ideas?
#upstart 2010-05-28
<Imperion> question: why are all of my jobs dying with code 1 as soon as I create them? :S
#upstart 2011-05-23
<djszapi> How can I run an upstart script manually for testing purpose ?
<ion> Itâs not a script, and âstart jobnameâ.
<djszapi> ion: well, something is wrong :(
<djszapi> exec /usr/sbin/start-cupsd.sh -> I try to run this custom file from an upstart job
<djszapi> Which is intended to run this script: http://paste.kde.org/73711/
<djszapi> and 1) I do not see the created directory 2) cups daemon is not run at all
<djszapi> how could I debug the issue ?
<djszapi> http://paste.kde.org/73717/ -> this is my apps/cups.conf
<djszapi> When are the /etc/init/apps/ jobs run ?
<jhunt> djszapi: take a look at http://upstart.ubuntu.com/cookbook/#debugging
<SpamapS> Hrm.. so we're hitting the "state problem" again with network-manager. It needs to not stop until after a certain event has run. But right now it is 'stop on stopping dbus' .. so if I make it 'stop on stopping dbus and deconfiguring-networking' .. 'stop dbus' will hang. ... 
<SpamapS> so I almost have to make dbus have a dbus-shutdown.conf that works like portmap-boot.conf and identifies itself as specifically the dbus that stops on runlevel [06]
<SpamapS> s/almost/think I probably/
<SpamapS> hmm.. unless I just make dbus stop on my new event
#upstart 2011-05-24
<djszapi> I guess, if I us upstart, I do not need the /etc/init.d/cups any longer, just starting it from an upstart apps job, right ?
<toabctl> how can i source a file (from /etc/default) in a upstart "script" section?
<djszapi> Where can I find the debian/rules-like for ubuntu/cups ?
<djszapi> I would like to check out how they solve this package with upstart stuff.
<JanC> djszapi: do you have an ubuntu system?
<JanC> on an Ubuntu system you can do "apt-get source cups"
<JanC> if you don't have Ubuntu, the source package is available in http://archive.ubuntu.com/ubuntu/pool/main/c/cups/  (you probably want the original tarbal & the diff)
<djszapi> hi Keybuk 
<Keybuk> hey
<Keybuk> how's it going?
<djszapi> I have a small issue as usual :)
<djszapi> about upstart and deb packaging...
<djszapi> how about you ?
<Keybuk> I'm good
<djszapi> excellent =)
<Keybuk> I'm only my first cup of coffee, and I already know why CrOS comes up with "Unaccelerated graphics" after my CL
<Keybuk> today is going to be a good day, I can tell
<djszapi> cool, Keybuk, I do not understand one thing about upstart
<Keybuk> what is that one thing?
<djszapi> we use subfolders inside the /etc/init/ directory on maemo
<djszapi> and not just jobs inside /etc/init/ directly.
<Keybuk> sure
<djszapi> and debian/ubuntu developers keep telling me that it is odd
<djszapi> no idea why
<Keybuk> they're wrong
<djszapi> have you ever used cdbs style for debian package creation ?
<Keybuk> not purposefully
<Keybuk> I've had to patch packages that use it, and that was painful enough
<djszapi> mmh, my fresh debian-devel ml question is not online yet, but you can find it here: http://paste.kde.org/74185/
<Keybuk> right, debhelper
<Keybuk> dh_installinit isn't anything to do with cdbs, except that cdbs happens to use it
<Keybuk> it's certainly a valid debhelper patch to support installing to sub-directories of /etc/init
<Keybuk> you might have to be creative
<Keybuk> e.g. dh_installinit --name=apps!foo
<Keybuk> and have debian/cups.app!foo.upstart
<djszapi> nope read again
<djszapi> I tried to set the
<djszapi> "--onlyscripts" option
<djszapi> so it should not install any init script/job with that and i could make a workaround from the postinst script without changing the packaging style
<Keybuk> you don't want that option
<Keybuk> that still installs the scripts
<Keybuk> you want to not run dh_installinit
<djszapi>        -o, --onlyscripts
<djszapi>            Only modify postinst/postrm/prerm scripts, do not actually install any init script, default files, or upstart job.  May be useful if the init script or upstart job is shipped and/or installed by upstream in a
<djszapi>            way that doesn't make it easy to let dh_installinit find it.
<djszapi> Keybuk ^
<djszapi> from man dh_installinit
<Keybuk> the doc is wrong
<Keybuk> I think
<djszapi> can that happen ?
<Keybuk> can documentation be wrong?
<Keybuk> sure
<djszapi> well, it is worth to report it as soon as possible then.
<Keybuk> Debian is --> that way ;-)
<djszapi> what way ?
<Keybuk> --> that way
<djszapi> ??
<Keybuk> I just mean that the appropriate place to file that report is with Debian, not here
<djszapi> oh yeah, sure.
<djszapi> are you also at the meego summit in San Francisco ? :D:D
<Keybuk> I shouldn't imagine so
<Keybuk> I don't have any vacation time left this year
<djszapi> well, cdbs is buggy
<djszapi> DEB_DH_INSTALLINIT_ARGS = --name=nonexistent -> I have just tried out this advice, but I still get the /etc/init.d/cups and I do not know why
<Keybuk> no idea
<djszapi> seems there is no way to avoid the debhelper usage.
<SpamapS> djszapi: there's some planned work happening in Debian to make that you're struggling with a little easier.
<SpamapS> Keybuk is probably right.. you will have to manually put your upstart job and init.d script in place until dh_installinit is modified.
#upstart 2011-05-25
<mbiebl> <djszapi> seems there is no way to avoid the debhelper usage.
<mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
<mbiebl> not an upstart issue per se, as Keybuk already told you
<djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit -> disagree
<djszapi> better to avoud the cdbs usage. I will not develop a software because of a one time usage...
<mbiebl> got nothing to do with cdbs
<djszapi> but yeah...I know the developers like forcing others to contribute. However it will not happen this time :)
<mbiebl> and nobody forces you
<djszapi> you indeed do
<mbiebl> no
<djszapi> more people told more times, I should use debhelper, but you still keep repeating I should patch cdbs. Meanwhile I told /quite many times/ I will /not/. period.
<mbiebl> repeating to patch cdbs? You are confused
<djszapi> oh well
<djszapi> sorry, I will not patch cdbs, I will just use the debhelper.
<mbiebl> wtf
<mbiebl> I never said you should patch cdbs
<mbiebl> where the hell did you read that non-sense
<djszapi> not because of I am not involved in opensource leisure time and fulltime project, but I like working efficiently.
<djszapi> and this is not my current interest
<djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
<djszapi> no, indeed no.
<mbiebl> so?
<djszapi> 08:00 < djszapi> 02:41 < mbiebl> I think the better way is to provide a patch to support subdirs in dh_installinit
<djszapi> 07:59 < djszapi> sorry, I will not patch cdbs, I will just use the debhelper.
<mbiebl> djszapi: sorry Id did not repeat that
<mbiebl> and dh_installinit != cdbs
<mbiebl> seems your irc client is playing tricks with you 
<djszapi> sorry, I do not have time for this, back to work.
<djszapi> I clearly claimed I will use the debhelper, that is. There is not much to say over that.
<mbiebl> you still didn't understand it dh_installinit is part of debhelper
<mbiebl> hopefully you know what you are doing
<mbiebl> anyway, seems pointless talking to you
<djszapi> sure, none of us on the #debian-devel knows.
<djszapi> but you !!
<mbiebl> obviously you don't
<djszapi> ignore
<mbiebl> of course you can stay ignorant if you don't take any advice
<mbiebl> Keybuk: are you using Gentoo nowadays :-)
<djszapi> SpamapS: good to hear, is it already reported then ?
<djszapi> However I will not use that improvement since I need to port the packaging style to debhelper today and I would not like to "port" it back then :)
<djszapi> or change anything.
<djszapi> but there is a work ongoing, I think I am lucky. I do not even need then to report this feature request.
<djszapi> * if there is ..
<SpamapS> djszapi: no promises as to when it will be done. I wanted to work on it last Ubuntu cycle and it just got slammed to the bottom of my list. :-P
<djszapi> 'kay =p
<djszapi> I mean it is not important for me if I can use override_dh_installinit: for now.
<djszapi> SpamapS ping
<djszapi> SpamapS: I got the idea here: http://permalink.gmane.org/gmane.linux.debian.devel.general/162391 override_dh_installinit: $stuff_to_manually_install_to_etc_init_apps. But i do not know what it means :o
<djszapi> I do not see any good description for thsi override_dh_installinit here either: http://www.debian.org/doc/manuals/maint-guide/dother.en.html#initd
<SpamapS> djszapi: it means, at the time when you'd normally call dh_installinit, you'll run those commands
<SpamapS> djszapi: they don't go right after the:, but on the next line , preceded by a tab.
<djszapi> SpamapS: so if I would like to change the path for one file only, I can do that right ?
<djszapi> I do not need to "enumerate" all the files because the other files I do not overwrite here will be copied just fine, right ?
<SpamapS> djszapi: dh_installinit is pretty elaborate. You'll need to either call it with special arguments, or emulate everything it does.
<djszapi> well, I would like to modify one file install path, but it is really a big overhead to do the other 100-200 files manually....
<djszapi> that should not be touched at all....
<djszapi> just what needs modification.
<djszapi> otherwise, it is not really an intelligent system
<djszapi> SpamapS ^
<SpamapS> I need something that ends in a ?
<djszapi> pardon ?
<SpamapS> You made a lot of statements
<SpamapS> but if you want help, I'm not sure how to help you without a question
<djszapi> well, the question is that how I can overwrite the install path for *one* file.
<djszapi> without forcing me to install all the other 1000+ files manually.
<mbiebl> don't install it via dh_installinit but with dh_install
<mbiebl> i.e. don't name it *.init or *.upstart
<mbiebl> but you will lose all dh_installinit integration
<mbiebl> i.e. start/stop in the maintainer scripts etc
<mbiebl> you need to do that manually, if you need that
<djszapi> SpamapS ^
<SpamapS> mbiebl is right.
<SpamapS> and I am sleeeepppyy
<SpamapS> djszapi: good luck! I'm going to bed
<djszapi> Alright, he will remain ignored about his tone :)
<djszapi> I will ask the guy on the debian-devel mailing list who advised it to me.
<mbiebl> you are hilarious. do whatever you like
<mrvn> Moin. Can I write an upstart job that is run last during startup?
<toabctl> is upstart-udev-bridge available in debian stable (ustart 0.6) ?
<toabctl> jhunt, i want to execute a job after /dev/ttyS2 is available and use "start on tty-device-added" but nothing happen
<toabctl> jhunt, and i got the example from the cookbook you've written.
<mrvn> toabctl: you need to specify the instance you are waiting for I thin
<mrvn> k
<jhunt> toabctl: might be a bug in your .conf file. which example are you referring to? there is no example with tty-device-added in the cookbook.
<toabctl> jhunt, i used the example from section 9.2.3. "start on (graphics-device-added or drm-device-added)" and replaced this with "start on tty-device-added"
<jhunt> are you running natty?
<toabctl> jhunt, no. i use debian on arm
<toabctl> jhunt, my question is: can i use upstart-udev-bridge in upstart 0.6.6 or is this a new feature?
<toabctl> jhunt, have to go. i'll ask again tomorrow. thanks!
<Keybuk> mbiebl: CrOS is built from Gentoo/Portage
<mbiebl> Keybuk: interesting. didn't know that
<Keybuk> it's about the only distribution system out there that can cross-compile
<mbiebl> it's not that I really know much about this topic, but iirc one of multi-archs goals in Debian/Ubuntu is to make cross-compile easier
<Keybuk> yeah, and multi-arch has been about two years away
<Keybuk> for the past ten years ;-)
<mbiebl> hehe, true. At least there seems to be progress atm
<astory> if I want to run a job as late into shutdown as possible while the filesystem is still live, what event should I have it start on?
<mbiebl> astory: what do you want to do during shutdown?
<astory> just remove a file, I'm trying to track unsafe shutdowns
<mbiebl> astory: are you on ubuntu?
<astory> yes
<mbiebl> /etc/rc{0,6}/S60umountroot will mount / ro
<mbiebl> you want to remove the file before that
<astory> so how do I configure the script so that happens?
<mbiebl> start the sysv init script at S59
<astory> ah, thanks.
<mbiebl> unless you place your file on another partition
<mbiebl> then you need  to do it before S40umountfs
<astory> it's going to be in /var, so that should be on root on my systems
<mbiebl> astory: the shutdown/unmounting in Ubuntu is not really "upstartified"
<astory> mbiebl: so should I be using a regular init script, then?
<mbiebl> that's why a sysv init script is the simplest solution for your case
<mbiebl> yes
<astory> ok, thanks
<mbiebl> [00:38:35] <mbiebl> start the sysv init script at S59 (in rc6/rc0)
#upstart 2011-05-26
<webofunni> Hi All
<webofunni> I do have a doubt regarding upstart
<webofunni> When I am executing initctl list
<webofunni> I am getting blank output 
#upstart 2011-05-27
<BonkersLaptop> is there a way to clear all status for a job?
<BonkersLaptop> I've got a job that keeps hanging at start/stop no matter what I seem to do
<Keybuk> are you using 'expect' ?
<BonkersLaptop> I am, but I'm not sure that my expect is right
<Keybuk> right
<Keybuk> that's an upstart bug
<BonkersLaptop> it seems rebooting is good enough to clear things
<Keybuk> sadly
<BonkersLaptop> what is, if you get expect wrong, there's no way to proceed?
<BonkersLaptop> nginx does funny things, I'm not sure there's a way to get it to work normally under nginx
<BonkersLaptop> neither deamon nor fork grab the correct PID
<BonkersLaptop> pre-stop it is then
<Keybuk> right
<BonkersLaptop> the PID file looks like it would be very useful here, but the pid stanza seems like it has been removed, did something replace that?
<Keybuk> no
<BonkersLaptop> too bad
#upstart 2011-05-29
<uni4dfx> where can i find the latest ubuntu/debian builds?
<SpamapS> uni4dfx: https://launchpad.net/ubuntu/+source/upstart
<uni4dfx> ah but those are really outdated
<SpamapS> those are the latest *ubuntu* builds
<uni4dfx> well yeah, i was just hoping for v1.1
<SpamapS> So are we. :) The delta got a bit out of hand last cycle.. hopefully that will be resolved soon.
<uni4dfx> any clue whether they will be ready til june?
<uni4dfx> or at least IN june
<SpamapS> Not sure. I know that there's an ongoing effort to push the Ubuntu-only changes into the 1.x branches... but it has hit a number of roadblocks.
#upstart 2012-05-21
<muzzol> hi
<muzzol> is there any variable that holds the action that triggers it? (start, stop, restart)
<muzzol> i want to do something like this: http://pastebin.com/XFJJsceu
<muzzol> is that possible?
<lpapp> jodh: hey, I do not understand what upstart does, but when I run the command manually, the "daemon" works as expected unlike with an upstart job :(
<jodh> lpapp: where does $ACTION come from?
<jodh> lpapp: have you looked at http://upstart.ubuntu.com/cookbook/ ?
<jodh> lpapp: your job looks good aside from that variable which isn't being set, so the script will presumably fail. See also http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section
<djszapi> jodh: do you have a clue what can cause that ?
<djszapi> http://paste.kde.org/483674/ -> this is my upstart job
<doki_pen> what's the best way to kick off a proc as an unprivileged user?
<djszapi> init-checkconf /etc/init/foobar.conf
<djszapi> ERROR: failed to ask Upstart to check conf file
<djszapi> what is this, SpamapS ideas ?
<djszapi> slangasek: same issue again
<djszapi> the exec line works, if I run manually.
<djszapi> but if I use start foobar, it does not.
<slangasek> oh, really?
<slangasek> so even running 'start foobar' fails?
<djszapi> nope
<djszapi> funky thing is that, the ps aux
<djszapi> output shows the process execed :D
<djszapi> but the daemon does not work as expected.
<slangasek> djszapi: is the code for the daemon open?
<slangasek> also, can you try modifying the job to run /usr/bin/foobar under strace, and capture the syscall output?
<djszapi> slangasek: first step would be to get the daemon output logged into somewhere.
<djszapi> no, the daemon is a commercial stuff
<djszapi> cannot disclose, sorry.
<slangasek> ok
<djszapi> but that helps, if I know how to log the output.
<slangasek> daemon output logged> what version of Ubuntu are you running again?
<slangasek> the upstart from 12.04 has logging support
<djszapi> Linux linaro-ubuntu-desktop 3.1.1-26-linaro-lt-omap #26~lt~ci~20120325001352+1332635991~4f6ec49b-Ubuntu SMP PREEMPT  armv7l armv7l armv7l GNU/Linux
<djszapi> 1.3-0ubuntu12~linaro2
<slangasek> if you're using 12.04, or if you can upgrade upstart to that version, you'll get a /var/log/upstart/foobar.log containing all the output
<slangasek> otherwise, you can use shell redirection directly in the upstart job
<slangasek> exec /usr/bin/foobar receive /dev/ttyUSB0 38400 > /var/log/my-log 2>&1
<slangasek> ^^ should work
<slangasek> if it *doesn't* work, you just need to wrap the exec with a script / end script
<djszapi> let us see if that redirection works.
<djszapi> slangasek: foudn the issue. The log helped a lot, thanks.
<djszapi> it is now working :)
<slangasek> ok
<gchristensen> hi, my upstart script seems to fail to start when the system is starting, even though I've given it a very relaxed respawn limit, and even put a 3 second sleep in the script. here it is: https://gist.github.com/96512f0ef329d5b022e4
<slangasek> gchristensen: a) your start and stop conditions are identical, which is certainly an error; b) 'mysql' is not a standard upstart event, so unless you've written something that outputs it, you'll never satisfy the start condition
<gchristensen> I see
<slangasek> you probably want 'start on started mysql'
<slangasek> and 'stop on stopping mysql'
<JoeJulian> If an upstart script has to wait for the network to be started, what's the string it needs to WAIT_FOR?
<gchristensen> slangasek: that might do it. thank you for your help, I'll read the manual closer
<slangasek> your 'sleep 3' should be unnecessary, btw; the mysql upstart job should, like all upstart jobs, have already been written such that the mysql server is up and ready to receive queries before emitting 'started'
<gchristensen> slangasek: that was a last-ditch attempt
<slangasek> JoeJulian: unless there's a specific reason that your service needs to start earlier, best practice here is 'start on runlevel [2345]'
<JoeJulian> So the network should be started already at that point?
<slangasek> JoeJulian: definitely
<JoeJulian> The problem seems to be with semiosis' upstart scripts for glusterfs. One user has encountered an issue with resolving hostnames while glusterd is starting. I presumed this was due to the network not being started.
<slangasek> JoeJulian: the exception is if your network is controlled by network-manager, in which case there's no guaranteed synchronization event for the network being up
<JoeJulian> Does debian use network-manager? (not a debian user myself)
<slangasek> JoeJulian: Debian supports network-manager... it would not be used by default on a server, be it Debian or Ubuntu
<slangasek> and Debian also doesn't use upstart
<slangasek> (currently)
<JoeJulian> Ok. Thank you. I'm not very good at supporting non-rpm based distros. :D
<slangasek> :)
<slangasek> so are the upstart jobs that you're concerned about different than the ones in the glusterfs-server package shipped in Ubuntu?
<slangasek> (which does indeed show 'start on runlevel [...]'
<slangasek> )
<JoeJulian> I /think/ that those are, indeed, the ones that semiosis wrote.
<JoeJulian> And I got two users mixed up. It is ubuntu.
<slangasek> right - that's much more plausible :)
<slangasek> so yeah, if it was a server install, the existing job should already be correct
<slangasek> if someone's doing this on a desktop install, there could be problems, depending on the configuration of network-manager
<JoeJulian> This guy is a former windows admin. I think you're on to something with the networkmanager idea. 
<gchristensen> slangasek: what "start on" output should I be listening to for something that expects networking and a writable filesystem? ie: a generally usable machine
<slangasek> gchristensen: that's precisely the 'start on runlevel [2345]' I mentioned to JoeJulian 
<JoeJulian> Looks like you need a bot with an automatic notice. :D
<JoeJulian> hehe
<slangasek> if you look in /etc/init/rc-sysinit.conf, you'll see this defined in terms of 'filesystem and static-network-up'
<gchristensen> I see
<gchristensen> thank you
<JoeJulian> "Desktop 32bit. Stock image"! Thanks slangasek. Good catch.
<slangasek> ok
<slangasek> too bad that there's no upstart event to key on in that case
<slangasek> but yeah, if the user can switch to static network config via /etc/network/interfaces, it'll work around this problem
<JoeJulian> It's supposed to be a server anyway. I'll just make him reinstall.
<slangasek> :)
#upstart 2012-05-22
<louischatriot> Hello
<djszapi> slangasek ping
<djszapi> I have installed 12.04 on my pandaboard, and that comes with this upstart version: 1.5-0ubuntu5. This version seems to support the logging out of the box in /var/log/upstart/myjob.log
<slangasek> yep
<djszapi> handy, I can use "tail -f /var/log/upstart/myjob.log"
<slangasek> :)
<djszapi> slangasek: my job is not run after a reboot, I do not understand
<djszapi> upstart job: http://paste.kde.org/484466/
<djszapi> lol it started VERY late.
<djszapi> minutes after the boot
<slangasek> with the 'stopped udevtrigger' start condition?
<djszapi> I presume
<djszapi> btw, does the upstart job have rights to write this folder ? /root/.config/MyStuff/foobar.conf ?
<djszapi> the daemon works fine, if I run manually.
<djszapi> but not if it is run via the upstart stuff
<djszapi> the creation of that configuration does not happen in the latter case.
<djszapi> if I execute exactly the same command as root, then the daemon works fine
<djszapi> got a clue ?
<djszapi> slangasek: ^
<slangasek> an upstart job will run as root unless otherwise specified
<djszapi> but why is it not working then without the upstart invocation ? :o
<djszapi> it works fine manually...
<slangasek> dunno
<slangasek> seems like a case for strace
<djszapi> I have not clue how to read the strace output
<djszapi> I really see such a spammy output.
<slangasek> I could interpret, but since you mention this is proprietary code, that may leak details of the inner workings that you might not wish to share
<djszapi> exactly.
<slangasek> the main thing would be to scan the strace output for references to that file
<slangasek> and see what it's doing
<djszapi> are you usre ?
<djszapi> sure*
<slangasek> I'm sure that's how I would debug it in your place :)
<djszapi> exec strace ... ?
<djszapi> in the upstart job ?
<djszapi> slangasek: ^
<slangasek> yes
<slangasek> probably best to use 'exec strace -ff -o /var/log/debugging-my-app [...]'
<slangasek> so that upstart doesn't itself have to process all the spammy output
<djszapi> slangasek: damn
<djszapi> I found the issue
<djszapi> for some reason the stuff is not saved into ~/.config but into /.config (root fs, yes)
<djszapi> if I run the daemon explicitely, the place for saving those is ~/.config
<djszapi> slangasek: what does upstart do differently ?
<slangasek> does your program rely on $HOME being set?
<slangasek> because $HOME isn't set for upstart jobs
<djszapi> slangasek: why the heck is that not set ??
<slangasek> why *would* it be?
<slangasek> you're not running the job in a login session
<slangasek> it wouldn't be set for any init scripts started at boot time either
<djszapi> well, /.config is super weird location
<djszapi> it is the source of super maintenance waste of time
<djszapi> config files are usually saved into a $HOME directory.
<slangasek> not for system-level services, they aren't
<djszapi> ofc, I run the job in a login session.
<slangasek> and upstart jobs are system-level services
<slangasek> you can always do 'env HOME=/root' as part of the job
<djszapi> I know, but that is a hack.
<slangasek> nope
<slangasek> your assumption that $HOME should be set for you is incorrect
<djszapi> no
<djszapi> well
<djszapi> let us ask differently.
<djszapi> where are the system-level configs are stored ?
<djszapi> you cannot automate that.
<djszapi> perhaps directly in /etc/
<djszapi> as in: /etc/MyCompany/myapp.conf
<slangasek> system-level configs are stored in /etc, yes
<slangasek> and normally, system-level programs don't need to be told that
<slangasek> you appear to have a program which is normally run as a user and you're trying to run it as a system job
<aaronlevy> I'm having trouble getting an upstart service to start on boot (ec2). I tried start on "network-services" as well as "memcached" but it doesn't seem to be even trying. Any suggestions on next steps to debug? I don't see anything in syslog for the service or anything 'init' related. 
<aaronlevy> 1.5/precise fwiw
<djszapi> slangasek: I am running a program which has stuff to store
<djszapi> so I need to use a configuration file
<djszapi> no matter which user runs that, it is run
<slangasek> djszapi: fine, but that's a problem between your upstart job and the program itself
<slangasek> upstart should not be setting $HOME
<slangasek> aaronlevy: 'start on started memcached' may be what you're looking for
<aaronlevy> slangasek: Sorry, typo. I do have "start on started <foo>"
<slangasek> aaronlevy: is memcached an upstart job?
<slangasek> if it's an init script, this won't work
<aaronlevy> Yeah, it's init (or at least it doesn't have a .conf in /etc/init). Oddly that is the example they use in the cookbook
<slangasek> really?
<slangasek> so 'start on started memcached' will definitely fail; there are no upstart events generated for memcached in the current package
<slangasek> because it's an init script and not an upstart job
<slangasek> jodh: ^^ it might be a good idea to not use memcached as an example in the cookbook, for this reason?
<aaronlevy> Yeah that might help :)â¦ there are a handful of examples using it (task=, instances)
<aaronlevy> Hmm. What is the recommended event to chain to (with networking available)?
<slangasek> aaronlevy: what does the job you're trying to run actually do?  Does it have anything to do with memcached?
<slangasek> 'start on runlevel [2345]' is the generic "my network and filesystem are available" rule
<aaronlevy> slangasek: loosely. I was just using that as a separate test. I can do pre-start stuff to make sure what i need is runningâ¦ just need it to at least try and start itself :)
<aaronlevy> slangasek: fwiw, the cookbook also uses "network-services' as an abstract job example. But doesn't seem like that is an upstart job either. I guess I should have checked, but it does make things a little unclear
<aaronlevy> Thanks for your help
<slangasek> hmm, that's a rather unclear example, isn't it :/
<slangasek> (1, 2) This job is not actually available in Ubuntu yet, but is expected to be added early in the 11.10 development cycle.
<slangasek> oops
<aaronlevy> Hmm. using [2345] still nothing. 
<aaronlevy> wait. I messed up syntax. trying again
<aaronlevy> Yup, working. Thanks again.
<djszapi> slangasek: is there a way to run the daemon explicitely as root ?
<djszapi> from the upstart job, that is.
<djszapi> exec does not have a "-u" user switch
<djszapi> su - ... or how ?
<djszapi> that way, the HOME variable would be set
<slangasek> no, it wouldn't
<slangasek> if you want a HOME variable, set a HOME variable - I told you how :)
<slangasek> well, running with su would set it maybe, but that's bad form
<slangasek> because then you get a pam session as well, and you don't want that
<slangasek> your application requires $HOME to be set, so just add 'env HOME=/root' and be done with it
<slangasek> now, you *can* run upstart jobs as different users; there are 'setuid' and 'setgid' verbs.  But that has nothing to do with login shells and isn't going to set $HOME, and root is the default user
<djszapi> slangasek: I do not understand why upstart tries to use a "user" (root as default) without setting the HOME user variable.
<djszapi> that makes no sense.
<djszapi> then do not use the "root" user.
<slangasek> well, I'm sorry you don't understand, but this is how Unix *works*.
<slangasek> this is nothing new to upstart.
<djszapi> running stuff as a user has the consequency you *do* need to set the HOME variable.
<slangasek> you would have gotten the exact same behavior with an init script.
<djszapi> since the something that runs as a user would like to have a safe location for its stuff inside the home path...
<djszapi> it is not all the apps' responsibility to set the stuff explicitely.
<djszapi> slangasek: ^
<slangasek> djszapi: no, it's not the app's responsibility, it's the upstart *job's* responsibility
<slangasek> there's really no sense in arguing about this further; as I said, this is completely in line with how init scripts work, and it's not going to change
<djszapi> this is really a bad design
<slangasek> you're arguing with 30 years of history :)
<djszapi> so did wayland...
<djszapi> and won...
<qkslvrwolf> hello, all.  I'm fairly new to working with upstart.  Working with VMs using Opennebula using LVM.
<qkslvrwolf> I'm trying to get the contextualization to work.
<qkslvrwolf> using upstart
<qkslvrwolf> opennebula suggests updating /etc/init/networking.conf and /etc/init/network-interface.conf
<qkslvrwolf> and having both of them run the static network IP address script in the pre-start scripts of both those files.
<qkslvrwolf> I've done that, but I get "couldn't read /etc/network/interfaces" and "interface ethX declared allow-auto twice" in dmesg
<slangasek> qkslvrwolf: umm.  are these opennebula suggestions available online somewhere?  I'd like to read exactly what they're suggesting and why
<qkslvrwolf> yes
<qkslvrwolf> one sec...
<qkslvrwolf> http://dev.opennebula.org/projects/opennebula/repository/show/share/scripts
<qkslvrwolf> http://dev.opennebula.org/projects/opennebula/repository/revisions/master/show/share/scripts/ubuntu/net-vmcontext
<qkslvrwolf> the second one is the more direct link
<qkslvrwolf> the README file has the suggestions I'm following.
<slangasek> yuck
<slangasek> fwiw, I strongly advise against editing the stock upstart jobs
<qkslvrwolf> ok
<qkslvrwolf> Fair.  
<qkslvrwolf> Can you point me in the right direction for accomplishing a dynamic assignment of a static IP in a VM, then?
<qkslvrwolf> ie., assign a static IP based on a dynamically generated mac address?
<qkslvrwolf> at VM boot time?
<slangasek> so you could do something like this, as a *separate* upstart job: http://paste.ubuntu.com/1001688/
<slangasek> though honestly, I think this would make more sense as an upstart rule
<slangasek> sorry
<slangasek> udev rule
<qkslvrwolf> Would you mine letting me know why you feel that way? 
<qkslvrwolf> (learning purposes, not disagreement)
<slangasek> because it's part of setting up the attributes on the device itself
<slangasek> that's absolutely something that udev rules are for
<qkslvrwolf> even though it's for the IP address?
<qkslvrwolf> not the mac address?
<slangasek> oh, I misunderstood the goal, sorry
<qkslvrwolf> No, I'm sure I wasn't clear.
<slangasek> in that case, yeah, it can be done as an upstart job
<qkslvrwolf> ok
<qkslvrwolf> And I'm guessing it makes most sense as a system job in /etc/init?
<slangasek> if you're doing it as an upstart job, definitely
<slangasek> btw, how does this upstream script know which interface it's being called for?
<qkslvrwolf> the upstream script (if I used it unmodified) just does an ifconfig -a and takes steps for any interfaces it finds that aren't loopback.
<qkslvrwolf> which is basically generating a stanza for /etc/network/interfaces
<qkslvrwolf> based on the mac address it finds.
<qkslvrwolf> which it did correctl...after boot I was able to ifup my interfaces and they came up fine
<qkslvrwolf> during boot i got errors.
<qkslvrwolf> but I didn't change anything
<slangasek> ah, right
<slangasek> so the problem is that it generates it once for /etc/init/networking.conf, and again for /etc/init/network-interface.conf, since *both* jobs are guaranteed to fire :)
<qkslvrwolf> right.
<qkslvrwolf> i wondered about that.
<slangasek> and the upstream script doesn't clean up after itself
<qkslvrwolf> So if I just chose one of them, it would probably work better?
<slangasek> yeah
<qkslvrwolf> is there one I should prefer?
<slangasek> preferably /etc/init/network-interface.conf
<qkslvrwolf> ok.  But won't that fire for each interface?
<qkslvrwolf> the script handles them all at once...but then I guess networking starts on local-filesystems which probably doesn't guarantee the interfaces are up?
<slangasek> correct, /etc/init/networking.conf isn't guaranteed to happen after all interfaces are up
<slangasek> so if you have more than one interface... yeah, it'll still fire more than once :/
<qkslvrwolf> Ok.  I actually just tested... I went ahead and kept it in networking.conf and removed form network-interface and it worked.  If it gives me problems I'll re-evaluage
 * slangasek nods
<qkslvrwolf> thank you so very much for your time...i appreciate the help.
<slangasek> sure thing :)
<djszapi> slangasek: anyway, I would personally change how qt works
<djszapi> my dependency handling the configuration stuff, but the maintainer does not appreciate that :D
<djszapi> so if both sides are stubborn, I need to work around both limitations :D
<djszapi> of course everybody using a daemon with that framework has to do the same
<slangasek> it's just a one-line fix-up in the upstart job ;)
<djszapi> for /everybody/
<djszapi> using a daemon with this framework at least
<slangasek> well, yes
<djszapi> perhaps even with others having the same design
<slangasek> though I don't think qt is a particularly common framework for daemons
<djszapi> it should be solved like I said
<djszapi> no separate framework attentions should be made.
<djszapi> or perhaps attention there would also be good for robustness
<djszapi> why not ?
<djszapi> qtcore is a total cool fit for daemons
<slangasek> except for the bit where it cares about $HOME, which daemons should not ;)
<slangasek> this is *not* a standard part of a daemon's environment
<djszapi> like I said
<djszapi> I proposed the change there as well
<djszapi> if not set, do not use /.config
<djszapi> but some sensible.
<djszapi> but the bare minimum is a /big/ and /fat/ warning
<djszapi> slangasek: thank you for your help anyway
<slangasek> sure thing
<djszapi> though env HOME=/root will not work
<djszapi> slangasek: or is that an upstart specific syntax ? I thought that runs bash
<djszapi> s/env/export/ might work
<slangasek> that's an upstart-specific verb
<slangasek> you set it outside your script
<slangasek> so:
<djszapi> I do not have script...
<slangasek> env HOME=/root
<slangasek> exec $foo
<slangasek> the init(5) manpage explains this verb
<djszapi> slangasek: right
#upstart 2012-05-23
<djszapi> slangasek: ping
<djszapi> what is the recommended way with upstart to run more binaries ?
<djszapi> in the same exec line, separate, or something else ?
<asvin> hello everybody, I'am pretty new to upstart and trying to write a script. Actually I got stuck whenever i want to start the service. I get the following message: start: Job is already running whereas the job isn't running at all. Any idea how i can debug it?
<djszapi> asvin: which version of upstart are you using ?
<djszapi> try stop yourjob and then start yourjob
<asvin> djszapi: i'am using 0.6.5-8
<asvin> let me try that
<djszapi> 0.6.5 really ?
<djszapi> please make sure
<djszapi> that would be very old
<asvin> when stopping i get this: stop: Unknown instance:
<djszapi> then it is not running
<djszapi> what if you now try to start that ?
<asvin> ok wait
<asvin> ah weird, it works now ;)
<asvin> i guess the stop did something
<djszapi> nope
<djszapi> since it was already stopped
<djszapi> make sure you start your job for the right condition
<asvin> djszapi also i'am looking for some help. actually i have a daemon written in PHP and i wanted to use upstart to start it. The daemon creates a pid file
<asvin> here's my conf, can u let me know if i'am doing the right thing?
<asvin> http://pastebin.com/cfzBnr2i
<djszapi> sorry, I do not have enough knowledge about this
<asvin> oh ok np
<asvin> but do you know how i can debug it? is there any log?
<djszapi> your upstart version is utterly odd
<djszapi> so it does not support the logging by default
<djszapi> but you can for sure make a redirection
<djszapi> but that is just about your program
<asvin> ah ok
<djszapi> I am not sure why you have two respawn lines
<asvin> yeah seeing that now, just removed it and it seems everything is working fine now ;)
<djszapi> cool =]
<asvin> thanks man
<slangasek> djszapi: "more binaries" - either separate jobs, or a wrapper script called from upstart; since upstart only tracks one process per job, if you have multiple processes in a job you have to make one of these be the parent process of the others
<djszapi> slangasek: problem is that if I use pulseaudio in my daemon running from an upstart job, I would need to run a pulseaudio server with --system
<djszapi> slangasek: if I make a pulseaudio upstart job, that makes the system a bit confusing since
<djszapi> 1) Does that come from pulseaudio ?
<djszapi> 2) What if others would also like to run that
<slangasek> seems like you want a separate pulseaudio upstart job and have dependencies between them
<djszapi> you ignored 1) and 2) :)
<qkslvrwolf> hello again!
<qkslvrwolf> I am, for no good reason, attempting to start selenium2 via an upstart job
<qkslvrwolf> here's what I have:  http://paste.ubuntu.com/1003268/
<qkslvrwolf> I'm still a bit fuzzy about how to try and debug this stuff.
<qkslvrwolf> so if there's any chance someone could point me in the right direction...
<djszapi> why respawn twice ?
<qkslvrwolf> oh...thought that was necessary...guess I read that wrong
<qkslvrwolf> I kinda copied that from the ssh.conf file.
<qkslvrwolf> corollary...if I'm trying to troubleshoot, does initctl read the .conf file every time, or does it read it when I run initctl reload-configuration, or do I need to do somethign else to make a change and then try the change.
<qkslvrwolf> also..should I be just runnign start on the service, or should I be attempting to emit desktop-session-start?
<qkslvrwolf> oh, jeez, I'm an idiot
<qkslvrwolf> ok, figured some out...but my variables aren't being expanded like I'd hoped...
<qkslvrwolf> ok
<qkslvrwolf> I don't understand teh way the variable expasnion is working here.
<qkslvrwolf> in my original, from teh pastebin, I was getting output from `set` like SELENIUM_EXEC='java -jar $SELENIUM_JAR'
<qkslvrwolf> so, I noticed that some (not all) of the examples from the cookbook wrap variables in single quotes, so i tried
<qkslvrwolf> SELENIUM_EXEC="java -jar '$SELENIUM_JAR'"
<qkslvrwolf> and now I get
<qkslvrwolf> SELENIUM_EXEC='java -jar '"'"'$SELENIUM_JAR'"'" in my output file...
<rotham> hey.. here is my upstart script:  http://pastebin.com/X8PkZct8  ... 'start supervisor' appears to work, but 'stop supervisor' gives me an error about unknown instance.  Also when I examine the processid of the running supervisord process it is _different_ than the id that the 'start supervisor' commad tells me it is running under.
<rotham> any ideas what could be wrong with it?
<qkslvrwolf> does supervisor fork?
<qkslvrwolf> 'cause that sounds like it's forking a process.
<rotham> hm it was, but i just added a line to the command to stop it from forking.  Now it runs with the right process id, but 'stop supervisor' still gives the same error.
<rotham> supervisord lets me set the pid file in supervisord.conf.  does upstart expect a certain pid file?
<rotham> or expect it to be in a certain location..?
<qkslvrwolf> IANAE (I came here for help myself), but I think upstart expects to control the pid.  It logs it itself.
<qkslvrwolf> I haven't used that at all, though, so I'm not sure where it tracks it.
<qkslvrwolf> if you need it elsewhere, and it's accurate, you could always get it from initctl status supervisor, though
<qkslvrwolf> in shell, anyway
<rotham> ah k
<qkslvrwolf> there is probably a file or something, I just don't know where it is.
<qkslvrwolf> also, if you want to let it fork, you can look at the expect commands
<qkslvrwolf> for upstart
#upstart 2012-05-24
<flowerpot> Am I correct in understanding that pidfiles are not necessary when using upstart?
<qkslvrwolf> hello, all
<qkslvrwolf> I'm still having trouble getting my upstart job to work when I need it to.
<qkslvrwolf> http://paste.ubuntu.com/1004781
<qkslvrwolf> I'm trying to make sure that my context script runs BEFORE the network interfaces come up
<qkslvrwolf> I know this is running
<qkslvrwolf> but it runs after something has read /etc/network/interfaces and brought up eth1
<qkslvrwolf> and I can't find out what.
<qkslvrwolf> wait...prestart scripts run before emitting starting, don't they?
<qkslvrwolf> nevermind, got it to work.  not as cleanly as I would've liked, but it works.
<djszapi> slangasek: ping
<slangasek> hi there
<djszapi> slangasek: how can I make sure the sleep 60 in my upstart job is not executed for an install ?
<djszapi> I mean for package install
<djszapi> if I would like to stop the currently running instance and start
<djszapi> since the system is up anyway
<djszapi> and it is just annoyingly slowing down the reinstall of a new version
<djszapi> it should only be considered for a boot
<slangasek> you could key on the $UPSTART_EVENTS variable
<slangasek> this will be empty when started manually (as from a package maintainer script)
<djszapi> is that a hack or the right approach ?
<djszapi> not that sleep is already a right approach, but we have not found better way.
<djszapi> slangasek: ^
<slangasek> that's the right approach for distinguishing between a manual start and a boot-time start, yes
<djszapi> slangasek: what is the exact syntax ?
<slangasek> you're just checking for an environment variable; see /etc/init/lightdm.conf for an example usage
<djszapi> I do not have lightdm on the pandaboard.
<djszapi> if [ -n "${UPSTART_STOP_EVENTS}" ]
<djszapi> oh
<djszapi> slangasek: what is the opposite of -n ?
<slangasek> if ! [ -n "$UPSTART_EVENTS" ] ?
<slangasek> you want UPSTART_EVENTS, not UPSTART_STOP_EVENTS; sorry, lightdm.conf uses both
<djszapi> I know which one we want.
<djszapi> I did not know the syntax for negation
<djszapi> no, lightdm.conf is simply not available
<djszapi> that was a bad example
<djszapi> slangasek: http://paste.kde.org/486188/ this one ?
<slangasek> you don't want to negate it
<slangasek> you want if [ -n "$UPSTART_EVENTS" ]; then sleep 60; fi
<slangasek> UPSTART_EVENTS is empty in the package install case, non-empty at boot
<djszapi> doesn't -n mean null ?
<djszapi> as in zero ?
<djszapi> it means not zero ?
<djszapi> very weird syntax then...
<djszapi> slangasek: http://paste.kde.org/486194/ this one ?
<slangasek> yep
<djszapi> slangasek: can I use comment anywhere in that file ?
<djszapi> even right before the check ?
<djszapi> just for making a note about this since it is not a usual case...
<slangasek> yes
<slangasek> upstart uses the same comment character as the shell (#), so comments are safe anywhere
<slangasek> (provided you put them on a line by themselves)
#upstart 2012-05-25
<drockna> why cant i reload?
<djszapi> slangasek: hey
<djszapi> slangasek: how can this happen ? http://paste.kde.org/486998/
<slangasek> djszapi: what part?
<djszapi> slangasek: grep finds no running daemons
<slangasek> mmm
<slangasek> the job may have exited shortly after starting?
<slangasek> the process may be named differently?
<djszapi> not called differently.
<djszapi> exited shortly might be.
<slangasek> right, so if it's exiting prematurely, there should be something in the upstart logs again (/var/log/upstart)
#upstart 2012-05-26
<drockna1> What Signal is sent to the workers on a restart
#upstart 2013-05-20
<Laney> Hello upstart friends! I'm after some help writing a user-session job for monkeysphere-validation-agent. It's usually run from Xsession.d in the usual manner taking another program to spawn, but can also run in the foreground, in which case it outputs some shell to be evaluated (setting the important env variable).
<Laney> Not really sure how to deal with this
<jodh> Laney: I think stgraber was looking at that at the client sprint. We had a similar headache with dbus but circumvented the problem with dbus-launch by calling dbus-daemon directly after first setting the required env var (see /usr/share/upstart/sessions/dbus.conf)
<jodh> Laney: problem is that you need the env var to be exported to the Session Init environment using 'initctl set-env', but you can't do that if the program is in the foreground (unless the value of that env-var is fully predictable? *shudder*)
<Laney> correct, and it is of course not predictable (or settable AFAICT)
<Laney> all I can think of is somehow reinventing parts of the STARTUP mechanism in jobs
<Laney> hmm, or having some helper script which does the work (msva-perl my-cool-script)
<jodh> Laney: that sounds workable - just have it call 'initctl set-env' and sleep forever.
<Laney> jodh: yeah, let me try that
<Laney> funny how thinking out loud makes these things turn up
<jodh> Laney: yeah :)
<stgraber> Laney: sounds like you're doing the same thing I did at the client sprint (go through all packages shipping something in /etc/X11/Xsession.d and fixing those that break under upstart)
<Laney> yeah
<Laney> plus I happen to use this one so it seems like a good place to start :-)
<stgraber> Laney: FWIW when I did that at the client sprint, I only noticed gpg-agent (which I fixed) and monkeysphere-validation-agent which I chose to ignore
<stgraber> ah, so people actually use this thing? good to know ;)
<stgraber> I chose to ignore it on the basis that nobody in the foundations room knew what it was, the code wasn't terribly readable and it wasn't easy at all to figure out how to run that thing on my machine for testing ;)
<Laney> heh
<Laney> it probably requires some time investment to set it up
<Laney> initctl set-env from the script doesn't work though
<Laney> hmm, it /is/ in list-env, but not in my session's environment
<Laney> ah, so if I block in post-start until it's set then I get it there
<Laney> stgraber: jodh: how would you do that?
<stgraber> Laney: hmm, so I'm not completely clear on what's the problem you're having
<Laney> soooooooo I call a script as an argument of the main program which does initctl set-env --global foo=bar and then sleeps indefinitely
<Laney> but I need to block the job from completing until the set-env has finished, otherwise the env var isn't set in the session
<Laney> One option would presumably be to use an event to signal when it's ready
<stgraber> ah, I suppose that's because monkeysphere-validation-agent actually exits when the wrapped software returns and there's no way to have it not do that?
<Laney> correct
<stgraber> so I think the way I'd do it is with a job having only a pre-start and post-stop section (similar to ssh-agent.conf). In pre-start you'd call monkeysphere-validation-agent with a script which prints the environment variables. You'd pipe that output into (while read line; do ...; done) so you can parse the output and when done, just leave the process running in the background
<stgraber> similarly to ssh-agent.conf, you'll want to set an environment variable containing the PID of monkeysphere-validation-agent so that you can kill it in post-stop and then unset all the variables
<stgraber> though the cleanest way to solve this may be to patch monkeysphere-validation-agent to support just printing the environment variables and then forking into the background (similar to what gpg-agent and ssh-agent do)
<Laney> mmm, I'll try that out tomorrow and see what it's like, thanks
<stgraber> not sure how active upstream is, but I don't think it'd be unreasonable for them to merge a --print-env or similar function that implements a behaviour similar to gpg-agent/ssh-agent, that'd definitely be my preference
<Laney> pretty sure he's fairly active
<Laney> you could then basically do the same as the *-agent jobs
#upstart 2013-05-21
<Laney> jodh: http://people.canonical.com/~laney/patch-dump/msva-upstart.debdiff WDYT?
<Laney> seems to work here
<stgraber> Laney: you don't appear to have a way to stop the msva
<Laney> hmm? 'stop' works
<SpamapS> Laney: +description "Job which does nothing other than block the session start until monkeysphere-validation-agent is finished" .. that is going to appear in a log...
<Laney> ah, didn't know that
<Laney> it can easily be condensed, of course
<SpamapS> should be
<SpamapS> its meant for user display
<SpamapS> document weirdness in comments :)
<Laney> don't think I've ever seen those in logs
<Laney> otherwise I would have known
<SpamapS> Laney: for system jobs they appear in the console.
<SpamapS> Laney: I have to believe at some point the same desire for visibility will seep into user sessions that seeped into the boot
<Laney> SpamapS: Do you think the rest of it looks alright?
<SpamapS> Laney: I have almost zero idea how xsession-init works (and almost zero care.. ;)  .. so I can't evaluate 'start on starting xsession-init' beyond "this will block xsession-init from starting" ..
<Laney> heh
<Laney> well, it all seems to work here
<Laney> might JFDI
<SpamapS> Laney: is there no need for a stop on in user sessions?
<Laney> I guess they all get torn down when the session ends - there is a session-end signal though
<SpamapS> Laney: so, I think its a bit over-engineered..
<Laney> In /usr/share/upstart/sessions/ most of the jobs don't have a stop on
<SpamapS> Laney: how does monkeysphere-validation-agent use that first argument?
<SpamapS> Laney: is that meant to be "fork and exec this when you are ready to serve user needs?"
<Laney> Spawns it, with MONKEYSPHERE_VALIDATION_AGENT_SOCKET in its environment and exits when it does
<SpamapS> +initctl set-env --global MONKEYSPHERE_VALIDATION_AGENT_SOCKET=$MONKEYSPHERE_VALIDATION_AGENT_SOCKET
<SpamapS> and set-env --global is appropriate ?
<SpamapS> Laney: because IIRC, not using --global, xsession-init will still get it..
<SpamapS> hm maybe not
<SpamapS> Ok yeah you need --global
<Laney> yeah I think so too
<SpamapS> Laney: my very untrained eye says it is all fine.
<Laney> possibly the weirdest unexplained part is the pre-start script, but that's robbed from the old Xsession.d script :-)
<Laney> thanks for the review
#upstart 2013-05-22
<Laney> slangasek: Do you plan on uploading an upstart with user sessions to unstable (soon)? I'm wondering whether to forward stuff and/or trying to have some kind of discussion about adding support to pkg-gnome packages.
<vanguarde9> Hello guys , i have a question
<vanguarde9> http://pastebin.com/XrXXv3Ue
<vanguarde9> I have this upstart scripts
<vanguarde9> In pre-start stanza Im reading simple config file
<vanguarde9> to get content of one shell variable
<vanguarde9> but when i try to echo this variable in script stanza
<vanguarde9> its empty
<vanguarde9> can somebody tell me what im doing wrong ?
<vanguarde9> why this variable is not propagated later ?
<jodh> vanguarde9: http://upstart.ubuntu.com/cookbook/#pass-state-between-job-processes
<vanguarde9> thanks for hint
<xnox> jodh: note debian-devel & debian-bsd w.r.t. kfreebsd upstart porting =)))))
<jodh> xnox: interesting :)
<joaojeronimo> so, I have a process that forks 4 times, and upstart is only changing the uid for the father. The children end up not having enough permissions to do stuff on the file system
<joaojeronimo> how do I correctly setuid for all the children ?
<jodh> joaojeronimo: upstart requires that processes only fork up to 2 times (since that is the maximum number of forks required to fully daemonize). I'd suggest either running your app in the foreground if it provides an option to do. Alternatively, 'expect stop' might be an option for you? (http://upstart.ubuntu.com/cookbook/#expect-stop)
<joaojeronimo> jodh: 'expect stop' doesn't seem to fix this problem about the file permissions of the children
<joaojeronimo> jodh, the problem is I'm running an app that uses leveldb, and leveldb is making 4 forks that need to read and write to the OS. Even using setuid on upstart, apparently the children end up not having correct permissions
<jodh> joaojeronimo: upstart only sets the initial processes uid - sounds like your app is changing it again somehow.
<joaojeronimo> jodh: I don't know how this works exactly but it sounds like it starts the process, the process forks, and then upstart changes the uid for the initial process ?
<jodh> joaojeronimo: correct.
<jodh> joaojeronimo: well, upstart forks, changes to the user you specify, then runs your app. whatever happens next wrt uids is the apps responsibility.
<joaojeronimo> interesting... ok got it..
<joaojeronimo> well it's a node.js app, I even tried process.setuid('correctusername') but apparently the children still don't get the correct uid
<jodh> joaojeronimo: try running your job replacing the node.js bit with procenv to show what environment upstart gives it (see http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in)
<dottedmag> I am trying to run a daemon (which does not have an option to stay in foreground). I use 'expect daemon' and everything works fine, except
<dottedmag> if this daemon detects configuration problem up launch and exits, and then upstart fails to detect that daemon exited before fork.
<dottedmag> So upstart continues to report status as start/running (no pid) until I explicitly 'stop' it.
<dottedmag> Is that expected?
<dottedmag> It's pretty simple to reproduce. The following job description will stay in 'start/running' state after start: http://pastebin.com/ypdmTPAS
<jodh> dottedmag: Please read the cookbook. This is correct behaviour because upstart is attempting to run your failing job repeatedly as you have specified 'respawn'.
<jodh> dottedmag: see: http://upstart.ubuntu.com/cookbook/#expect, http://upstart.ubuntu.com/cookbook/#respawn, http://upstart.ubuntu.com/cookbook/#implications-of-misspecifying-expect.
<jodh> dottedmag: note the big warning which covers your scenario at the start of the respawn section.
<dottedmag> I see, thanks.
<dottedmag> Hmm. But the job does not get respawned. Log file only shows single attempt to run it.
<SpamapS> jodh: why doesn't init-checkconf ever work?
<SpamapS> jodh: I say that as it now works for me. But the other day, it didn't.
<SpamapS> jodh: n/m ;)
<jodh> SpamapS: sorry, without more details I don't know. Can you raise a bug if you can recreate?
<dottedmag> Where do the upstart log messages go? I have started it with --verbose, but the only place I see those messages is /var/log/dmesg and only up to DM start moment.
 * dottedmag slaps his forehead
<dottedmag> dmesg :)
<slangasek> Laney: updating upstart in unstable is on my List, but not a top priority currently
<Laney> k
<dottedmag> I've got a situation when daemon fails on startup and upstart does not cause it to be restarted: http://pastebin.com/ePciMNWw
<dottedmag> zabbix_agent fails and (trivial fork/fork/exit) daemon-exit does not.
<dottedmag> zabbix_agent does not do anything weird on startup: http://pastebin.com/0mkKvg1d
 * xnox thought it needs to start to be respawned....
<xnox> e.g. respawned if it segfaults / killed / etc. not when it gracefully exits.
<dottedmag> It exits with exit code 255
<dottedmag> Also, if I just run /bin/false, it gets respawned to matter what.
<dottedmag> And zabbix_agent gets stuck in start/running state.
<jodh> dottedmag: are you aware that zabbix-agent has already been packaged for Upstart in Ubuntu? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/zabbix/saucy/view/head:/debian/zabbix-agent.upstart
<dottedmag> jodh: I am aware of it, but have a look at bugtracker.
<dottedmag> Also, I need 2.2 (not yet released one).
<dottedmag> Anyway, now I can reproduce the error without zabbix_agent.
<dottedmag> Please have a look: https://bugs.launchpad.net/upstart/+bug/1182943 -- this one is distilled to bare minimum.
<jodh> dottedmag: this is not a bug in upstart so much as an incorrect .conf file - /bin/false does *not* fork twice, but you've told upstart it does...
<dottedmag> jodh: Yes. But it's upstart's job to handle failing daemons properly.
<jodh> ...which it does perfectly well when provided with a valid .conf file.
<dottedmag> Uhm.
<jodh> dottedmag: upstart cannot "guess" how your app works I'm afraid, hence "expect".
<dottedmag> zabbix_agent checks the configuration and exits if it is incorrect. Otherwise it forks twice and runs.
<dottedmag> How should I write a .conf in this case?
<jodh> dottedmag: does zabbix have an option to "just check its config file and exit"? If so, put that call in a pre-start section which will stop the main job process starting in case of an invalid config file.
<dottedmag> jodh: just had a look. Nope, it does not.
<dottedmag> Hum-hum. I think I can abuse one of the options for this check.
<dottedmag> Still.
<dottedmag> If you look at log file, upstart correctly saw abrupt termination of daemon (and proper PID), so it seems to be just a matter of event ordering.
<dottedmag> jodh: thanks for suggestion.
<jodh> dottedmag: yes, "-t" is ripe for abuse fwics.
<dottedmag> I still feel it's kind of shaky to rely on daemons always reaching their intended number of forks and not failing before.
<dottedmag> I'll have a look, might be it is not hard to fix
<jodh> dottedmag: the problem is the "respawn" - upstart  cannot restart an app until that app has fully started (and then exited).
<jodh> dottedmag: in your case, another consideration is how the config file became invalid in the first place.
<jodh> dottedmag: the zabbix one that is.
<dottedmag> jodh: that's just a syntax error, and I am not really worried about it.
<dottedmag> jodh: I am worried about job being in start/running state, while no service is actually running.
<dottedmag> Uhm, -t does not check config. Wonderful.
<jodh> dottedmag: you might be able to use a "post-start" stanza to sniff around and determine if the agent started or not and just call "stop" if it isn't to tell upstart that it has died.
<dottedmag> jodh: I will probably just add no-fork option to agent, seems much simpler.
<jodh> dottedmag: frankly, most daemons provide such an option. And one to check any config file they use.
<dottedmag> Yes, zabbix seems to be a bit... antique.
<jodh> dottedmag: I was going to say "unique", but yeah ;)
#upstart 2013-05-23
<vanguarde9> Hello does anybody have experience with upstart and red hat based distros ? Is it posible to start automaticaly upstart service after start of systemV service , without addig any code (etc. initctl emit sometnig) into systemV script ?
<vanguarde9> I mean for example Centos as Red Hat based linux distro
<jgornick> Hey guys, I'm running Ubuntu 12.04 and for some reason, I can't get initctl to recognize my job conf file I've created in /etc/init. Thoughts?
<xnox> jgornick:  init-checkconf /etc/init/myjob.conf ?
<xnox> does that say anything useful?
<jgornick> xnox: ERROR: failed to ask Upstart to check conf file
<jgornick> xnox: sudo?
<jgornick> Nope :)
<jodh> jgornick: are you running at the console? If so, you'll need to start a dbus-daemon for init-checkconf to work.
<jodh> jgornick: dbus autostart changed its behaviour. newer init-checkconf versions handle this.
<jgornick> jodh: Yes, it's a headless server. How do I start the dbus-daemon?
<jgornick> jodh: To be specific it's the 12.04 Amazone AMI.
<jgornick> s/Amazone/Amazon
<jodh> jgornick:  eval `dbus-launch --sh-syntax`
<jgornick> The program 'dbus-launch' is currently not installed.  You can install it by typing: sudo apt-get install dbus-x11
<jgornick> Shall I do that?
<jodh> jgornick: if you are able to. if not, just pastebin your job so we can see it
<jodh> jgornick: ... or copy the job to a desktop system and run init-checkconf there of course :)
<jgornick> jodh: I'll get a copy of the conf file.
<jgornick> jodh: https://gist.github.com/jgornick/32e8e17c75d64cbacc37
<jodh> jgornick: the job is valid. I wonder if /etc is on some sort of overlay filesystem maybe?
<jgornick> jodh: I can't imagine. It is the basic Ubuntu 12.04 Server instance offered from Amazon with official support from Canonical.
<jodh> jgornick: 'mount|grep overlay' ?
<jgornick> Nothing echo'd/
<jodh> jgornick: hmm. when you say initctl does not recognise the job, what do you mean exactly?
<jgornick> jodh: sudo initctl status bulkqr initctl: Unknown job: bulkqr
<jgornick> jodh: That's after I do a sudo initctl reload-configuration
<jgornick> Just to make sure it's loading in the conf file.
<jodh> jgornick: try "sudo initctl log-priority debug; touch /etc/init/yourjob.conf" and look at dmesg / /var/log/syslog to see what upstart messages you get relating to that job.
<jodh> jgornick: that'd be "sudo touch" :)
<jgornick> jodh: We're getting somewhere: https://gist.github.com/jgornick/32e8e17c75d64cbacc37#file-gistfile2-txt
<jodh> jgornick: odd. it's complaining about line 24 and the file only has 23 lines. Have you got some stray extended characters in that job file maybe? \r rather than \n? if not, try commenting out each stanza/block and seeing where the problem lies.
<jgornick> jodh: That was it.
<jgornick> jodh: Some bad character or whatever. Probably a copy paste through terminal that made it happen.
<jgornick> jodh: Thanks for helping debug that.
#upstart 2014-05-20
<funhouse> Hi there, is it a bad idea to use upstart on centos?
<funhouse> Hello?
<deserted> hey all, got an issue trying to create a custom upstart job that I'm hoping is me missing something obvious
<deserted> have tried using both exec and script to call a command that is passed an option of another file to launch, no short or long opts form before it, but get the result of "no such file or directory" despite both referenced files being present
<deserted> job can be seen at https://gist.github.com/deserted/704c1ca5e0a2bbc40cd6 along with the output error
<deserted> any help would be greatly appreciated :)
<detrout> deserted: the error message in your gist looks like its coming from a sysv init script
<detrout> line 24 in the upstart init script is the respawn limit
<deserted> detrout, ahh thanks, think you're spot on, as there's a /etc/init.d/casualbookings initscript as well :S
<detrout> you probably need a guard condition in the init script
<deserted> detrout, just tried removing the casualbookings sysv script, which flagged that casual-bookings.conf doesn't seem to be recognised as a service
<deserted> ~# service casual-bookings
<deserted> casual-bookings: unrecognized service
<detrout> initctl reload-configuration?
<deserted> done right before the paste sorry
<detrout> (warning i don't know that much about upstart
<detrout> i came here because I had a bug in someone elses upstart init script
<deserted> no prob lol, you've already fixed one issue for me :)
<detrout> :)
<detrout> I think initctl is the control utility for upstart
<detrout> there's probably something in its man page that's useful
<detrout> for your situation
<deserted> yeah it is, but initctl check-config isn't flagging any issues with the job config
<deserted> so little confused as to why not wworking lol
<detrout> my guess is that the system started with the sysv version and I was thinking maybe its still expecting to use the sysv version?
<deserted> all good, cheers for the help, sysv version hasn't been used at all, was also only installed this boot, but i'm trying to replace it rather then go live with the old functionality
<detrout> ah ok
<deserted> even though tab-complete not working, querying as full string is, so I'll keep going from here :)
<deserted> # service casual-bookings status
<deserted> casual-bookings stop/waiting
<deserted> looks like may be getting the same issue as the sysv though, where it's treating the cmd + options as a single cmd string
<detrout> hm thats weird
<detrout>  the docs seem to think thats ok
<deserted> detrout, got it sorted in the end, thanks to debug logging
<deserted> setuid won't accept an env variable
<Joel> Thoughts on why this starts my script five times? I presume because of the respawn line, but what do I need to do to get this thing to realize it already started the script? https://gist.github.com/jjshoe/1d795c7169be2cb30388
<ion> Why do you use start-stop-daemon?
<ion> Instead of the script block, try: exec /usr/bin/monitor.rb
<ion> You should have the output in /var/log/upstart/{jobname}.log automatically.
<ion> Also, remove the instance line.
<Joel> ion, same bahvior.
<Joel> I wind up with six pid's.
<ion> Does monitor.rb daemonize?
<ion> Can you make it not daemonize?
<Joel> ion, nope, runs in a while loop.
<ion> Do you see errors in syslog or /var/log/upstart/{jobname}.log?
<Joel> ion, no file is created there.
<ion> Please pastebin the current job definition
<Joel> https://gist.github.com/jjshoe/982cf227aae470234f6b
<Joel> calling monitor.rb as root causes it to work correctly, it happily loops away.
<Joel> ion, any thoughts?
<ion> Is there some output regarding the job in syslog?
<Neozonz> Having some issues starting a jar daemon, service xxx start seems to just hang (process starts but doesn't go back to cmdline)
<Neozonz> Using as a template http://blog.jineshmk.in/2013/09/running-jar-as-service-using-upstart.html
<xnox> refactoring is fun, when one has a fully passing test-suite \o/ =)
#upstart 2014-05-22
<danieleB> why this does startup my application?
<danieleB> http://pastebin.centos.org/9686/
<danieleB> why this does NOT startup my application? (I meant)
<danieleB> sorry, I mean on reboot
<danieleB> I say it again :-)
<danieleB> why this doesn't startup my application after reboot?
<danieleB> http://pastebin.centos.org/9686/
<awolf2> Hi folks.  I can't seem to run anything in upstart as another user using su, sudo, or start-stop-daemon.
<awolf2> Hi folks--I cannot run su inside of upstart.
<awolf2> I get an error that su needs a terminal.
<awolf2> I'm on ubuntu 13.10.
#upstart 2014-05-24
<mikedevita> holy hell my snapshots are taking up 73% of my pools space >_>
<mikedevita> 2,366 snapshots o.O
#upstart 2015-05-23
<rray> hi
<rray> i had a question
<rray> i exec a bashcript in my upstart script but all of its children don't get killed when i stop it
<rray> how do i do this?
<rray> all i'm doing is just running a bashcript in my upstart file
<rray> nvm figured it out
#upstart 2016-05-23
<lkthomas> folks
<lkthomas> I got a service which stuck at start and stop
<lkthomas> how could I start debug it ?
<chras> stuck?
<samueltc> hi!
<samueltc> Where do upstart store pid?
<samueltc> also can I specify a pidfile instead of letting upstart guess it?
<samueltc> except fork/daemon are not working properly
<samueltc> upstart thinks a process is running, but it's clearly not...
#upstart 2016-05-26
<blz> Hello, can someone please enlighten me as to why my upstart script fails when setgid and setuid are uncommented? http://paste.debian.net/706443/
<chras> do you have permissions to write to all of thoes files with that user?
<blz> chras, aha, probably not.  Let me try that.
<blz> chras, that seems to be the problem.  Here's the rub, though:  I created a system user with limited permissions and I'd like for him to run the service in question.  As it happens, he doesn't have access to /var/run, and i'm unsure of the security implications of modifying permissions for /var/run
<blz> Are you able to advise?
<chras> if you're doing your own pid management
<chras> why not just make a subdir in /var/run owned by that user
<blz> chras, hmm yeah that seems like the simple/obvious solution.
<blz> Works like a charm, thanks again!
#upstart 2017-05-24
<Introoter> who uses this anymore!?
<AnrDaemon> Introoter: Me.
<Introoter> are you fine with it?
<AnrDaemon> It works. And don't unnecessarily wrapping itself in less, and don't try to pretend it knows better what's good for my system.
#upstart 2017-05-25
<xnox> Introoter, AnrDaemon hey =) it does work, it is stable, but it's no longer developed and is phased out.
<xnox> if you work on products that use upstart, i urge you to move to something else.
<AnrDaemon> xnox: I don't know another init that doesn't try to make a fool of me, short of SysV.
<xnox> bug eventually will crop up, with newer kernels, newer udev, newer initramfs. Thus upgrading will become difficult if one keeps upstart as init.
<xnox> patches and bugs are still welcome, if you notice anything strange.
<xnox> if one doesn't upgrade, everything should be fine.
<Introoter> AnrDaemon: OpenRC/runit are decent.
<AnrDaemon> I will probably have to live with systemd :/
<Introoter> what do you think is wrong with systemd though?
<AnrDaemon> Gotta touch it this summer and see how really bad it is, but so far, my impression is "below the acceptance floor".
<Introoter> and what are *your* acceptance standards?
<AnrDaemon> It is annoying on user level.
<AnrDaemon> My aceptance floor is "shut up and do your job".
<Introoter> well, it does?
<AnrDaemon> And it just can't shut upâ¦
<Introoter> you dont have to live with it, if you dont feel it is right, there are seriously alternatives that work fine and are being maintained.
<AnrDaemon> I have to live with distribution I'm bound to :/
<AnrDaemon> Changin it is a separate pain.
<Introoter> slackware (bsd style init), crux (again, bsd style init), Gentoo (OpenRC), Manjaro OpenRc, voidlinux (runit)
<Introoter> though keep in mind, when you do compare systemd to other init systems, you're doing it wrong and you'll end up frustrated with things it has to offer. perhaps systemd vs busybox is a better comparison, think about it.
<AnrDaemon> I know that systemd is not just an init daemon.
<AnrDaemon> That's the part of the problem.
<Introoter> also, systemd allows you to build only the necessary components it needs to function properly (those can be kept out too given you dont mind losing stuff) by configure switches
<Introoter> most distros just push the complete build down their users' throats
<Alumin> Is there an equivalent to SysV init's "kbrequest" in Upstart 1.5 (the version that comes with Ubuntu 12.04)?
<Alumin> the goal is I want someone to be able to hit a key combination (traditionally Alt-UpArrow, but the specific combo isn't that important) and have a command execute
<Alumin> so, without logging in, etc.
