#upstart 2008-08-29
<keesj> Hi
<keesj> I am hitting a old bug that the env are not taken into account on restart
<keesj> I am searching for a bug report for that but can't seem to find it (/me need ammo to upgrade to 0.5) 
<keesj> where is Keybuk?
<Md> BTW, a debian user too reported that $REMOVE_CMD is broken
<Millox> is it possible to act on custom events sent by initctl emit in upstart 0.3.9 (the one included in hoary)
<sadmac> Millox: yes
<sadmac> Millox: no settup. Just initctl emit anystringyoucanthinkof
<sadmac> and start on thatstring
<Millox> well, i'm trying just that but somehow it doesnt work
<Millox> in the configfile I have "start on blah" but "initctl emit blah" doesn't start the service
<Millox> actually it sometimes say Unknown stanza
<sadmac> Millox: pastebin your entire job definition
<Millox> hmm, should I use several stop on .. or should I use stop on blah or bleh?
<sadmac> depends
<sadmac> in 0.3.9 several stop on will work
<sadmac> in 0.5 it won't
<Millox> okay
<Millox> this is the start on and stop on definitions:
<Millox> start on (quagga and firewall) or router-up
<Millox> stop on router-down
<Millox> stop on runlevel 0
<Millox> stop on runlevel 1
<Millox> stop on runlevel 6
<Millox> there is also a post-start script which enables routing and a post-stop which disables routing
<Millox> start router and stop router works fine
<Millox> sorry about the spamming
<Millox> log says:
<Millox> init: /etc/event.d/router: unable to read: Invalid argument
<sadmac> dunno that 0.3.9 has an and operator
<sadmac> or parens
<sadmac> not too sure though :O
<Millox> maybe it doesn't
<Millox> I just removed them and now the invalid argument isn't seen anymore
<Millox> however, it still doesn't work
<sadmac> hm
<Millox> okay, now i managed to get the bounce example working but I still havn't the foggiest why the other doesn't work
<Millox> hmm
<Millox> just tried adding a script stanza  containg just /bin/true (and exec as well) but it still doen't work
<sadmac> try doing it without any and or or operators or parens at all
<Millox> tried with only one start on and one stop on but nothing
<Millox> hmm
<Millox> hsuccess!
<Millox> unfortunately i managed to shut down my router in the process ;-)
<Millox> apparently you can't have dash in signal names
<Millox> changing only the signal names is the difference between invalid argument and succes
<Millox> s
<Millox> unfortunately the start process doesn't return
<Millox> now
<sadmac> hm
<Millox> ah, service solved that
<Millox> okay, now I'm confused
<Millox> I've changed everything so much now that I dont know what I changed anymore
<Millox> but now it works as it should
<sadmac> heh
<Millox> okay, another question: the way to emit a signal from a job description is executing /sbin/initctl emit, right or wrong?
<sadmac> right
<Millox> isn't the job supposed to not run if any of the pre,post-start,stop scripts return nonzero?
<sadmac> pre-start maybe
<sadmac> the rest of those I think it keeps going
<Millox> seems like it yes
<sadmac> post-start things are already running, so its too late
<sadmac> post stop things are already stopped, so...now what?
<sadmac> pre-stop, well you don't want to make it impossible to stop something ever really
<Millox> no, that seems reasonable
<Millox> I just hadn't thought about it really
<Millox> and I suppose, it would be better to spell correctly so that the script doesn't return nonzero :-/
<Millox> hmm, I don't feel that the service jobs works correctly...
<Millox> i had a problem just now with jobs not starting
<Millox> i have a "bogus" job called network which is basically a placeholder for all network starting, and i had only an emitted signal in this job
<Millox> firewall and quagga had start on starting network in their job description
<Millox> when I had script or exec /sbin/initctl the network first started and then stopped immideately whereas if I used pre-start and no exec or script stanza the network started
<Millox> may
<Millox> maybe I've completely misunderstood the stanzas
<Millox> how is the environment set up for scripts, for instance is pid available through a variable in post-start/pre-stop?
#upstart 2008-08-30
<Millox> will later versions of upstart be able to handle several daemons to monitor for one service?
<ion_> Well, i already supports instances.
<ion_> it
<Millox> yep, got that part
<Millox> but what I currently need is a way to oversee several daemons at once, preferably with only one job definition file to keep clutter to a minimum
<Millox> i.e. nfsd starts i believe 4 different daemons to handle authentication, mounting, locking and uid translation
<Millox> it would have been nice to have just one job description file for these daemons since they logically is only one service
<Millox> ah, well maybe later
#upstart 2009-08-24
<Keybuk> sadmac: I'm here now ;-)
<Keybuk> I didn't vanish, I had a holiday
<Keybuk> and tried to mostly keep away from the computer <g>
<Keybuk> ion: I didn't really make any attempt to format the manpages in any way consistently ;)
<sadmac2> Keybuk: ah. good to have you back. Most of what I had to say is on the mailing list. Other than that, how do we feel about a release at LPC? I don't see much of 0.10 coming together
<Keybuk> sadmac2: yeah I'm a bit behind :-)
<Keybuk> 0.6 has worked too well
<Keybuk> which isn't a bad thing, of course
<sadmac2> yes. When gears aren't flying out the urgency goes out of fixing it
<Keybuk> it's more that part of the "rush" for 0.10 was that 0.5 couldn't supervise daemon processes
<Keybuk> and that is really essential for going native
<Keybuk> but that got fixed for 0.6, so you *can* already do a native boot with 0.6
<sadmac2> I'm in the middle of what is turning out to be a marathon rewrite (see the "triggers" thing on the mailing list)
<Keybuk> I'm way behind on e-mail, but will read with huge interest :-)
<sadmac2> sweet
#upstart 2009-08-25
<sadmac2> Keybuk: how do you feel about Dracut? Is Ubuntu interested?
<Keybuk> yes
<sadmac2> Keybuk: ah cool. I haven't done much with it yet myself. Fedora's test day for that feature is Thursday
<Stevee> good evening
<Stevee> iÂ´ve some problems with upstart and shutting down the system
<sadmac2> Stevee: go ahead
<Stevee> good evening
<Stevee> yes
<Stevee> iÂ´m using the current version 0.6.3
<Stevee> without compatiblity mode
<Stevee> on reboot iÂ´m using reboot with the flag -f
<Stevee> and it works correctly
<Stevee> but halt with -f doesnt work
<Stevee> if i try other flags like -n for now
<Stevee> the services are stopping
<Stevee> by the shutdown event
<Stevee> but the system doesnt power off
<Stevee> here is my shutdown script
<Stevee> http://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=src/initscripts/core/shutdown.conf;h=63d04acbb0a1a74b40c79f4c76a02e939b88447c;hb=master
<sadmac2> Stevee: your start on stanzas are wrong for one. you can only have one start on stanza now
<sadmac2> Stevee: start on shutdown or reboot
<Stevee> oh
<Stevee> okay, but the system reboot correctly
<sadmac2> Stevee: if you have two start on stanzas only the second one works
<Stevee> oh okay
<Stevee> okay, here is the link to the new file
<Stevee> http://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=src/initscripts/core/shutdown.conf;h=394b2274636e58ed9bef1b58150b87a2b0ad3079;hb=1237e47913328b79e5908d0d2c77f855c054ac04
<sadmac2> that looks like it should work
<Stevee> do i need the poweroff binary
<Stevee> ?
<Stevee> and the shutdown binary ?
<sadmac2> I don't believe so
<Stevee> atm they are deleted, because shutdown is for the compatiblity mode
<ion> keybuk: Btw, anything new with the mount daemon?
<Stevee> okay, now it wokrs
<Stevee> iÂ´ve got a message System halted.
<Stevee> thanks for the help sadmac2
<sadmac2> np
<ion> http://www.microsoft.com/businessproductivity/default.mspx http://www.microsoft.com/poland/businessproductivity/default.mspx
<Stevee> is upstart also going to replace cron ( frcon )
<sadmac2> Stevee: it probably will grow cron or cron-like functionality.
<Stevee> when is this feature planned ?
<Stevee> or is it already implemented ?
<sadmac2> Stevee: its kind of in the air
<sadmac2> Stevee: maybe Keybuk knows
<Stevee> is there a chance for this feature or is it only some kinde in the air ?
<_|ms|_> good evening
<ion> https://fedoraproject.org/wiki/Initrdrewrite#Initial_ideas seems against the idea of making initrd as tiny as possible for speed.
<ion> ...regarding Dracut
<sadmac2> ion: what parts?
<ion> âInclude all driversâ mainly
<sadmac2> ion: well.. dumb question
<sadmac2> ion: if you couple it with the "just build everything in" philosophy it could work out.
<sadmac2> I haven't pulled it apart yet. I dunno what to expect.
<_|ms|_> dracut seems to be a nice idea... but some kind of hard to build in :(
<Stevee> sadmac2: do you know if there is a real change to replace cron with upstart or is it just a nice idea ?
<sadmac2> Stevee: I'm betting it will happen. When and what it will look like... Scott has the only roadmap in his head (his FOSDEM talk might have some strong hints though).
<Stevee> oh, thats fine
<Stevee> hopefully it will be soon
<_|ms|_> is there a link to the talk?
<_|ms|_> may be a video link?!
<sadmac2> _|ms|_: yes...
<sadmac2> ftp.heanet.ie/mirrors/fosdem-video/2009/maintracks/upstart.xvid.avi
<sadmac2> whew that was hard to find
<_|ms|_> thanks :D
<_|ms|_> I have missed some info about the fosdem talks...
<_|ms|_> guys, I have to leave now... see you soon... gn8
<Stevee> guys, iÂ´ve to go now, see you soon, thanks again for your help sadmac2
<Stevee> good night
#upstart 2009-08-26
<Stevee> good evening
<keesj> hi
<Stevee> iÂ´ve a problem with upstart und shutdown the system
<Stevee> i emit the shutdown event
<Stevee> the job stats and some jobs stops
<Stevee> but then the the system halts and not all services are stopped clearly
<Stevee> is there way to check if all services are stopped bevore upstart power of the system ?
<Stevee> keesj: do you have any idea for this problem ?
<sadmac2> Stevee: 1) are you sure there's reason to do that? For a lot of services its just a waste of time. 2) what do your job definitions look like now?
<Stevee> my job file looks like that
<Stevee> http://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=src/initscripts/core/shutdown.conf;h=394b2274636e58ed9bef1b58150b87a2b0ad3079;hb=1237e47913328b79e5908d0d2c77f855c054ac04
<Stevee> if i remove the whole script
<Stevee> i got messages from als services that they have stopped on the console
<Stevee> if i start the job with the script section
<Stevee> i only get a message of 2 or 3 jobs
<Stevee> after that, the system powered off
<Stevee> and all other jobs arenÂ´t killed clearly
<sadmac2> Stevee: yes, that's going to halt the system as soon as it gets shutdown, with no regard to what else is going on
<sadmac2> Stevee: do your other services have "stop on shutdown" and that is how they shut down?
<Stevee> yes, they have stop on shutdown or reboot
<sadmac2> Stevee: yes. this won't work :)
<Stevee> mhm okay, why ?
<sadmac2> Stevee: make them stop on some other event (stop-all say) and then add an emits stop-all stanza to your shutdown job, and in the script do initctl emit stop-all
<Stevee> and why i canÂ´t use stop on shutdown or reboot ?
<sadmac2> Stevee: everything that happens on shutdown or reboot will happen at the same time.
<Stevee> so if emits a stop-all, all services will be stopped
<Stevee> and than, the system will halt ?
<Stevee> or reboot ?
<sadmac2> yes.
<keesj>  Stevee do you always have the same behaviour or not?
<Stevee> yes
<Stevee> allways the same
<keesj> and do all your job directly depend or stop on "starting" shutdown?
<keesj> (what version btw?)
<Stevee> no only on stop on shutdown or reboot
<Stevee> version is 0.6.3
<Stevee> also the current one
<keesj> on thing that can happen is that one script fails and this makes the rest fail
<Stevee> but without compatiblity ( no runlevels )
<keesj> Stevee: also I think you need stop on starting 
<keesj> the ohter problem I see is that your even is names after the job name
<keesj> so shoulden't it be "stop on starting shutdow" so first everything is started before the schutdown script is executed
<sadmac2> Stevee: he's right. Stop on starting shutdown will let you avoid having to do the emits/initctl emit
<keesj> (I have not played much with 0.6.3 yet)
<Stevee> stop on starting shutdown or reboot, is that correct
<Stevee> or do i need
<Stevee> stop on starting shutdown
<Stevee> stop on starting reboot
<Stevee> i two lines ?
<keesj> you are no longer allowed to have two lines any more
<Stevee> okay
<keesj> stop on starting shutdown or starting reboot(I would guess)
<Stevee> okay, and do i have to change the job name to something other than shutdown like "anything"
<Stevee> ?
<Stevee> do you know a distribution that uses upstart fully event based ?
<sadmac2> Stevee: you don't /have/ to rename the job, but its probably better practice to not have jobs and events with the same name
<Stevee> okay so if i name the event halt and the job shutdown, i add to all other jobfiles stop on starting halt or starting reboot
<Stevee> everything should work fine ?
<sadmac2> you'll want stop on starting shutdown
<sadmac2> starting <jobname>
<Stevee> oh, the jobname, okay
<sadmac2> the other jobs will then stop whenever something tries to start your shutdown job, and they will block that shutdown job until they have all stopped
<Stevee> oh, i see
<Stevee> i allways depended on the event
<Stevee> not on the started job
<sadmac2> its still an event. started is the name of the event. shutdown is the first argument
<Stevee> yes, but i also have to change the eventname or ?
<sadmac2> you can have an event named shutdown and a job named shutdown, and that's fine. but its confusing.
<Stevee> oh, okay
<Stevee> so i will try it now, i will give a feedback
<Stevee> thanks for your help
<keesj> Stevee: one more tip
<keesj> you can set the log-priority using initctl. and when set to verbose it can help to understand what is going on
<Stevee> now the shutdown / reboot worked fine
<Stevee> thanks
<Stevee> but how can i hide all the messages of the stopped services ?
<sadmac2> Stevee: you'd have to do that on a service-by-service basis
<Stevee> yes, i used it as event by service
<Stevee> if you want, you can add us to your list of know distributions that are using upstart
<Stevee> we are a firewall distribution called ipfire
<Stevee> page: http://www.ipfire.org
<Stevee> guy iÂ´ve to go to bed, i wish you a nice evening and thanks for your help again
<Stevee> hopefully we will see you again
<Stevee> good bye
#upstart 2009-08-27
<Lunderhage> How do I make upstart log to serial console?
#upstart 2009-08-28
<sadmac> Keybuk: thought: nih_discard should run the destructor always.
<Keybuk> sadmac: why?
<sadmac2> Keybuk: Think of it in the case of our most common destructor: removing the node from a list. Discard should only leave the item around for people still referencing it, which means external references like that should go away.
<Keybuk> right, but that's not how it's supposed to work ;-)
<Keybuk> discard is "drop the NULL reference"
<Keybuk> the assumption is that you allocate an object with a NULL reference, pass it to something that actually references it
<Keybuk> and then drop the NULL ref
<Keybuk> if it didn't get referenced, dropping the NULL ref does free it
<Keybuk> e.g.
<Keybuk> void *foo;
<Keybuk> foo = nih_new (NULL, SomeObject);
<Keybuk> nih_list_init (&foo->entry);
<Keybuk> pass_to_some_func (foo);
<Keybuk> nih_discard (foo);
<Keybuk> ...
<Keybuk> where
<Keybuk> pass_to_some_func (void *foo)
<Keybuk> {
<Keybuk>     nih_list_add (&foos, &foo->entry);
<Keybuk>     nih_ref (foo, &foos);
<Keybuk> }
<sadmac2> well that's what it /does/ sure :) The name to me implies "normal operation of the program is done with this object. Only keep it around if something hasn't remembered to dereference it yet."
<sadmac2> In a more literal sense, "discarding" the object should take it out of a list.
<Keybuk> it's more equivalent to g_ref_sink in the old libgtk style referencing
<sadmac2> Keybuk: also I've occasionally found a list that I'd prefer used internal referencing (i.e. actually do nih_ref (list, list->next) etc rather than just having a destructor pull it out when its done). I was thinking of adding a second set of list helpers to facilitate maintaining a list in this way.
<Keybuk> sure, that's more like how nih_list_entry works, no?
<sadmac2> hm?
 * sadmac2 pulls a libnih tree onto his work machine
<Keybuk> NihList is embedded in structures
<Keybuk> NihListEntry is an NihList with a generic pointer
<Keybuk> where the list references the data contained in it
<sadmac2> oic. that's an interesting way of doing it...
<sadmac2> does its destructor unreference its target pointer then?
<Keybuk> you could make it do that
<sadmac2> then you could just use nih_free on the entry to remove from the list
<Keybuk> in theory the list/alloc stuff should be flexible enough to do it either way
<Keybuk> one of my other two libnih-using projects doesn't use the embedded list stuff
<Keybuk> because every object is in multiple lists
<sadmac2> I've also had some ideas I'm sitting on about how to reduce nih_alloc's overhead and possibly make it a bit more flexible, but I'm still churning.
<sadmac2> I have a thought that we could kill the parent/child lists and store a big adjacency matrix instead within a good sparse matrix data structure
<sadmac2> might perform better too (cache lines hate linked lists)
#upstart 2009-08-30
<dacresni> can I make X.org KeepAlive via Upstart?   
<dacresni> or rather, respawn 
#upstart 2010-08-30
<robinsmidsrod> is it possible for upstart to start a job as a specific user without using su in the command line of the job - trying to keep my process groups small
#upstart 2010-09-01
<ion> Hi Keybuk
<Keybuk> hey, how's it going?
<ion> Oh, the usual. You?
<Keybuk> getting better mostly
<ion> Getting better from what? I must have missed something.
<Keybuk> been suffering from depression this year
<ion> Ouch. Good to hear youâre getting better.
<Keybuk> thx
<ion> My meds keep the depressed mood away, but i have yet to find something to help with the fatigue and the inability to get shit done and to concentrate.
<Keybuk> yeah, have known that feeling all too well
#upstart 2010-09-03
<hallyn> for a very simple libvirt-lxc container with upstart, i have just an lxc.conf which emits 'start console', and a console.conf that then runs getty on /dev/pts/0.  When the resulting login exits, the exit_group() seems to kill upstart.  Simple solution?
<hallyn> (running getty through setsid doesn't work bc then upstart respawns to the limit immediately)
<hallyn> (i don't get why this is different from console gettys on a normal system - which doesn't seem to do anything special)
#upstart 2010-09-05
<mikhas> heya - just a quick question: can I configure upstart dependencies so that if service A needs a restart, service B is restarted, too?
<ion> B: start on started A, stop on stopping A
<mikhas> hm, will that  also work if A crashes?
<ion> yes
<mikhas> cool, thanks!
<mshadle> now that a lot of services are being setup to run via upstart, simple rc.d symlink management like S -> K to stop a service isn't an option. so what -is- the best way to say, not have vsftpd start on boot (without just rm /etc/init/vsftpd.conf or manually editing the file?)
<mbiebl> mshadle: there is currently no better way than to either remove the file or comment out the "start on" lines
<mbiebl> this is supposed to be fixed in 0.10
<mshadle> how's the change going to be done?
<mshadle> the other thing is to tell people "hey if you want to use upstart, you need an /etc/default/$daemon file, with $daemon_ENABLED="no" etc.
<mbiebl> mshadle: afaik the plan is to use "override" files
<mbiebl> Keybuk can tell you more, when he's around
<JanC> well, you can make the /etc/default/* option work now
<ion> Well, thereâs really not much of a difference between changing a value in /etc/init/foo.conf and changing a value in /etc/default/foo, except that the latter just splits stuff to two files for no reason.
<mbiebl> ion: the reasoning behind separate "override" files is, that you can manipulate with say a run level editor
<mbiebl> and your next package update will not cause a dpkg prompt
<ion> Yeah, but we were talking about /etc/default/foo with foo_enabled="no", which sounds like /etc/init/foo.conf sourcing /etc/default/foo.
<JanC> ion: which splits often used options from the main script...  ;)
<JanC> editing or rewriting a script is fine for those who understand them, for others editing a simple config file is safer (and they are safer to edit by GUI tools too)
<mbiebl> ion: well, yeah, I hate those /etc/default/foo files with foo_enabled=.. 
<mbiebl> for sysv we already have a perfectly working mechanism to enable/disable scripts from being started on boot
#upstart 2011-08-29
<ryoohki> how do i turn a service off so it won't start on reboot?  vi files in /etc/init?  there is no "chkconfig service off" functionality?
<jY> you have to edit the conf file.. there is a start on line
#upstart 2011-08-30
<sadmac> .wub 34
<ion> wubwubwubwubwubwubwubwubwubwubwubwubwubwub
<tgm4883> I'm trying to find if it's possible to have upstart run a job as another user. It would be a non-interactive job. I've found a post that mentions it is going to be in an upcoming version, but I can't find anything else about it, and I'm not sure where I can subscribe to so I see when this functionality exists
<ion> Use su for now.
<tgm4883> from what I've read, su won't work as it needs an interactive console
<tgm4883> correction, consolekit. We actually used to use su, but it caused issues with that and shutdown
<JanC> tgm4883: I don't know why 'su' shouldn't work
<JanC> maybe it needs some options in some environments?
<superm1> tgm4883 asked me to pop over here about su.  we ran into problems with su in the job that it left an interactive consolekit session open
<superm1> so if someone tried to reboot the machine it seemed like people were still logged in and there was a warning every time to reboot
<tgm4883> JanC, ^
<JanC> IMO that would be a bug in 'su' (or maybe su has an option to prevent that)?
<JanC> (or maybe sudo is more powerful in that respect?)
<JanC> the 'su' manpage lists a specific option to mimic a login session, so that indicates it should not start one by default?
<superm1> we were previously doing "exec /bin/su -c "/usr/bin/mythbackend $ARGS" $USER" which caused ck-list-sessions to list a mythtv session
<superm1> since then we've added support to mythtv to setuid seteuid etc, but this has the side effect that core dumps can't be captured anymore
<superm1> slangasek explained here: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/445953/comments/19
#upstart 2011-08-31
<hallyn> SpamapS: if job A is 'start on startup' and job B (udev) is 'start on virtual-filesystem', I assume there is no guarnatee that A will finish before B starts right?  
<SpamapS> hallyn: they are completely unrelated
<SpamapS> hallyn: so, correct
<hallyn> drat.  thanks.  
<hallyn> SpamapS: then maybe another q - do you happen to know where udev gets its list of devices to create in udev_event_execute_rules() ?
<hallyn> it can't just be /lib/udev/rules.d
<SpamapS> hallyn: not very well versed in udev internals no
<hallyn> ok, thanks
#upstart 2011-09-01
<roog> in the script block is it possible to determine which start on condition started the service.  I want my script to act differently based on which event it received 
<jhunt_> roog: See http://upstart.ubuntu.com/cookbook/#standard-environment-variables, specifically the UPSTART_EVENTS variable.
<roog> jhunt_:  that is perfect, thanks
<jhunt_> roog: np.
<hallyn> jhunt_: is there a trick to building upstart locally and not having test failures?
<hallyn> (with fakeroot debian/rules binary...)
 * hallyn sets up pbuilder for another approach
<jhunt_> hallyn: don't build it as root or the tests will fail.
<hallyn> oh, so not even with fakeroot.  got it.  thanks
<jhunt_> pbuilder works fine too though.
#upstart 2011-09-02
<SpamapS> sbuild does not.. something w/ the aufs I think
<hunterloftis> So - I'm trying to issue a 'killall' command to clean stuff up before a job is started. But if a matching process isn't killed, I guess killall returns a failed exit code (?) because then the job "fails to start"
<ion> What are you killing in pre-start?
<hunterloftis> ion - killing old instances
<hunterloftis> This process sometimes doesn't clean up after itself
<hunterloftis> And it creates child processes
<ion> Shouldnât that kluge be placed in post-stop?
<hunterloftis> It also binds to a port, so if any of the worker processes still exist on the next attempt at restarting it, you get an address in use error
<hunterloftis> I plan on putting it in both places
<ion> Or perhaps pre-stop.
<hunterloftis> Why not pre-start?
<ion> Isnât that redundant?
<hunterloftis> Well, if I had to choose, pre-start would be the best place in that case
<hunterloftis> Because I don't care about the workers except when I'm trying to start a new process
<hunterloftis> So cleaning up after is much less important than preparing at the beginning
<ion> When Upstart thinks a job is in the stopped state (which is a prerequisite for starting something), it *should* be.
<ion> Itâs very nasty to leave processes just laying around even though the job claims to be stopped and then try to clean them up just before starting it again.
<hunterloftis> Then why not just do it on both ends?
<frewsxcv> to get a script working, do i just copy my conf file into /etc/init? and then just do 'start script'?
<codebeaker> is it intentional that daemons started with upstart (ubuntu 10.x) don't inherit limits from /etc/security/limits.conf ?
<frewsxcv> so if i create an upstart conf, shouldn't i be able todo 'start myscript' immediately?
<jhunt> codebeaker: upstart doesn't use pam currently.
<codebeaker> ok, so it's planned/unplanned/etc - but the limits stanza is just as sane (once you know about it)
<jhunt> frewsxcv: yes, assuming the script has valid syntax - try running "init-checkconf file.conf"
<codebeaker> I've inherited a somewhat badly written upstart script via a ppa package, and was surprised that the software basically doesn't work out of the ppa, didn't know that there was a limits option
<jhunt> l
<frewsxcv> jhunt: i don't have that command
<jhunt> assuming the file is in /etc/init/, run "initctl log-priority debug && touch /etc/init/myfile.conf". Then, tail you system log and look for the name of your .conf file.
<jhunt> Upstart will have logged if it has read it or if it is syntactically incorrect.
<jhunt> frewsxcv: alternatively, do this: http://upstart.ubuntu.com/cookbook/#older-versions-of-upstart
<jhunt> frewsxcv: (just to check the code blocks)
<frewsxcv> thanks jhunt 
<jhunt> frewsxcv: np.
#upstart 2012-08-27
<pulz> seems i was incorrect when using start stop daemon its tracking the wrong pid 
<SpamapS> pulz: would you mind pasting your job file somewhere so we can take a look?
<pulz>  hehe, i mangled it now, but i can put up here the orig and the new 
<pulz> SpamapS: http://pastebin.com/AkszchTK here you go
<pulz> and thx for the intrest
<JanC> pulz: you should probably use one of the matching options of start-stop-daemon
<JanC> e.g. the -p/--pidfile option
<SpamapS> pulz: just drop the -D and the 'expect fork'
<SpamapS> amazing how many things do daemonization *wrong*
<SpamapS> https://github.com/gamelinux/passivedns/blob/master/src/passivedns.c
<SpamapS> should not daemonize until after compiling the pcap config and setting up the filters
<pulz> SpamapS: so the program is wrong ? 
<SpamapS> pulz: well, its silly that it crashes after daemonize() is called, thats all
<SpamapS> pulz: anyway, there's no reason to need -D and use 'expect fork'.. just run it without -D, and without expect fork, and you'll have an easier time....
<SpamapS> pulz: that said, if it immediately crashes, you should see something about that in /var/log/syslog, like "passivedns exitted with exit code 1"
<pulz> im assigning it the wrong interface to listen to, so it doesnt crash just exit to quick ? 
<SpamapS> pulz: yeah not much upstart can do about that :)
<SpamapS> pulz: note that if you are on Ubuntu 11.10 or later you should have a log of its output in /var/log/upstart/passivedns.log (assuming your job is /etc/init/passivedns.conf)
<pulz> SpamapS: yes it does, just tells you that it cant open the interface ([*] Error pcap_open_live: eth1: No such device exists (SIOCGIFHWADDR: No such device)) 
<meme> hello. i'm trying to daemonize node.js, with upstart. i follow this tut http://howtonode.org/deploying-node-upstart-monit , it gives a configuration sample, but it never mentions where it should go. any tips?
<SpamapS> meme: reading
<SpamapS> meme: /etc/init/yourprogram.conf
<SpamapS> meme: which, it says
<meme> huh? really?
<SpamapS> meme: yes, its in the paragraph right under the upstart config block
<meme> oh, yes. now i see, i just got confused, thanks for pointing that out
<SpamapS> meme: thanks for using upstart. :) Thats a pretty good article btw :)
<meme> oky :)
<SpamapS> meme: note that the pre-start and pre-stop in that job file are *completely* unnecessary
<SpamapS> meme: as is the script section.. it could be rewritten quite a bit simpler
<meme> alright, cheers
<SpamapS> meme: also 'start on startup' is dead wrong
<SpamapS> ok never mind that article is not so smart ;)
<meme> o.O
<meme> lol
<meme> i just need the basics, for now
<SpamapS> http://paste.ubuntu.com/1170475/
<SpamapS> thats all you need
<SpamapS> meme: start on startup just won't work unfortunately.. startup is before the filesystems are mounted, before networking is up..
<SpamapS> it probably accidentally works only because the root FS is mounted (readonly) and the thing listens on 0.0.0.0
<SpamapS> but the monit stuff is, I think, alright :)
<meme> it's ok, it is just for my personal site now, not a multi million traffic site :D
<meme> who knows in the future.... I have nginx as a proxy, so the power is there
<meme> `start on (filesystem and net-device-up IFACE!=lo)`
<SpamapS> ew
<SpamapS> don't use that
<SpamapS> ever
<SpamapS> meme: thats going to get you into trouble. Just trust that runlevel 2 is "when things are basically ready"
<meme> lol, someone at node,js is telling me, cauze i have asked the same question there also, lol
<SpamapS> yeah
<SpamapS> its a common misconception because a lot of official Ubuntu packages use it still
<SpamapS> but having rewritten the code th delay runlevel 2 until things are ready.. I'm well aware.. use runlevel 2. :)
<meme> i see, thanks god i meet you, you seems like an expert
<SpamapS> actually, having participated in the rewrite that smoser did .. :)
<SpamapS> meme: its only good in 11.10 and later. In 10.04 .. runlevel 2 is too early usually
<meme> i see
<meme> so i will just stick with the bin you gave me for now, let's see what's happen
<meme> SpamapS, i cannot get it to work. do you think that for the fact i'm using nginx as a proxy, it could be there some conflict?
<SpamapS> meme: nginx would be a completely different process, so no
<SpamapS> meme: why don't you try connecting directly to the node.js port, just to see if it works?
<meme> ok, but how?
<meme> i got the system message and all, app start/running, process 7613
<meme> after i do sudo start app
<meme> where app, is the app.js file, in my node app, it is an express app(not sure if you know node )
<meme> but i got a 502, if i visit the domain
<meme> when using the upstart
<meme> if i just do a normal node app.js command, all works with nginx 
<SpamapS> meme: oh, I think you might need $HOME set
<SpamapS> meme: so add a line..  'env HOME=/wherever/users/home/is'
<SpamapS> meme: i bet node is printing stuff into /var/log/upstart/app.log tho
<meme> lemme me check
<meme> i will vim'it
<meme> ;P
<meme> nope, it is not, it is empty
<meme> i have the app in my $HOME user folder
<meme> if i env HOME=/wherever/users/home/is same as env HOME=/home/[username] ?
<meme> or  env HOME=/home/[username]/sites/domain.com/public/app.js ?
<meme> ugh, i'm getting a lil bit frustrated, i will try this now https://github.com/nodejitsu/forever
<meme> i just need a quick hack for now
<pulz> SpamapS: about your fix, when disabling the daemon flag and just using exec it forks 13 procs 
<SpamapS> pulz: yeah that shouldn't really matter though
<meme> mm, i think i have a clue now, when trying to unistall i got npm WARN uninstall not installed in /usr/lib/node_modules: "npm"
<meme> ops, sry
<JanC> SpamapS: "runlevel 2" should be renamed to something more sensible IMO  ;)
<SpamapS> JanC: *100%* agree
<SpamapS> JanC: I meant to work on that this cycle but it got pushed out by other stuff
<SpamapS> JanC: I think  'start on starting network-services' and 'stop on stopping network-services' makes a *lot* more sense.
<SpamapS> JanC: there's another benefit to that which is that we can then have back our sequencing of things we want to start "after everything normal"
<SpamapS> like cron
<JanC> as long as it uses human-understandable names that are more or less self-explanatory  âº
<JanC> and of course well-documented
<SpamapS> yeah, runlevels are just left overs
<SpamapS> But I intend to have that network-services job 'start on runlevel [2345]' and 'stop on runlevel [016]'
<SpamapS> but having a job to follow gives us sequencing so its better then runlevel whcih is just a signal
#upstart 2012-08-29
<mitsuhiko> does anyone have any ideas why upstart sometimes i unable to pickup changes?
<mitsuhiko> how does one go about debugging upstart?
<mitsuhiko> does this ring a bell to anyone? https://gist.github.com/5f9061af79bb8b38d240
<mitsuhiko> service start just hangs
<mitsuhiko> i can confirm it does not even manage to start the executable
<mitsuhiko> god knows what it waitpids for
<mitsuhiko> i replaced the config file with one that just logs something
<mitsuhiko> and it still does not do anything
<mitsuhiko> force initctl reload-configuration does not do anything either
<mitsuhiko> what the fucking fuck. i just renamed the service and that fixes it
<jodh> mitsuhiko: is 'salt-master' a daemon by any chance? If you haven't already done so, I'd recommend reading http://upstart.ubuntu.com/cookbook/#precepts-for-creating-a-job-configuration-file.
<jodh> mitsuhiko: also, if you are creating this .conf from scratch, don't add respawn until you are convinced the job is working as you expect (http://upstart.ubuntu.com/cookbook/#respawn).
<jodh> mitsuhiko: also, you can remove all that redirection and either specify "console none" or just remove it any have Upstart auto-log any output to /var/log/upstart/<job>.log.
<jodh> mitsuhiko: another point - you don't need the script/end-script - just use 'exec'.
<jodh> mitsuhiko: to understand what is going on with your original job, 'initctl status <job>'. I suspect salt-master is forking but you haven't told Upstart that it does that (respawn stanza), which will lead to interesting results.
<jodh> mitsuhiko: oops - I meant 'expect' stanza, not 'respawn' above.
<mitsuhiko> jodh: the file works just fine
<mitsuhiko> i renamed it and it works
<mitsuhiko> so something in upstart is broken
<mitsuhiko> also the file worked for two months without changes
<mitsuhiko> jodh: the script/end-script was there for debugging purposes
<mitsuhiko> before it was expect daemon and salt-master -d as only exec line
<jodh> mitsuhiko: Upstart is not broken. The problem I think is that your original unrenamed job is not working as you expect, and since Upstart was unable to track the PID of the initial job, you were not able to start it (as Upstart thought it was still running).
<mitsuhiko> jodh: so how do i fix the unrename job?
<mitsuhiko> and no, the script was always correct
<mitsuhiko> i verified by spawning instances of all permutations of scripts i tried under the new name
<mitsuhiko> all of them work
<jodh> mitsuhiko: well, if you had 'expect daemon' and tried to start the job but salt-master does *not* fork, that too will confuse Upstart, hence your problem.
<mitsuhiko> jodh: as i said, all permutations work
<mitsuhiko> i tried expect daemon with -d and no expect with the redirected script block
<mitsuhiko> both work fine as expected
<mitsuhiko> my salt-master.conf file still does not start
<mitsuhiko> the same file as salt-wtf.conf does start
<jodh> mitsuhiko: and you verified that the PID Upstart reported in 'status job' reflected the real pid?
<mitsuhiko> jodh: the service is not running
<mitsuhiko> it *does not start*
<mitsuhiko> it hangs
<mitsuhiko> as shown by the strace above
<jodh> mitsuhiko: what does 'status job' show?
<mitsuhiko> $ status salt-master
<mitsuhiko> salt-master stop/killed, process 7240
<jodh> mitsuhiko: and does pid 7240 exist on your system?
<mitsuhiko> no
<mitsuhiko> it might have at one point but it's hard to say because upstart is completely unable to do anything with salt-master.conf at this point
<mitsuhiko> i cannot start it
<mitsuhiko> i cannot stop it
<mitsuhiko> yet if i rename it to salt-wtf.conf i can start and stop it properly
<mitsuhiko> intictl reload-configuration does not help
<jodh> mitsuhiko: right, so I think you or someone else has at some point changed the original conf file and attempted to start that job. Upstart is unable to track the pid as 'expect' probably wasn't specified correctly. Hence, you cannot start that job as it's in a bad state. Copying the job file creates a brand new job, so is not encumbered by that problem ;)
<mitsuhiko> jodh: trust me, there was nothing wrong with the file in the first place
<mitsuhiko> jodh: but assuming it was, how do you let upstart forget about the job?
<jodh> mitsuhiko: unfortunately, currently you can't without using gross hacks (or rebooting): the whole point is that Upstart is supposed to be supervising your services so it should not be possible to say "just forget about this one". That said, we are considering adding a feature as this does catch folks out occasionally.
<mitsuhiko> and you're telling me that is not an upstart bug
<mitsuhiko> seriously. i fix this by rebooting?
<jodh> mitsuhiko: ultimately, building up a new .conf file step-by-step should allow you to be assured the job is behaving correctly such that you'd never get into that scenario.
<mitsuhiko> jodh: seriously. that file was never wrong
<mitsuhiko> feel free to mistrust me on that one, but it was always correct
<mitsuhiko> how do i know? because we used this for two months
<mitsuhiko> what changed? i did a service stop, upgrade on salt, service start
<mitsuhiko> stopped functioning
<jodh> mitsuhiko: it admit, it's not ideal, but I've explained the rationale. Patches welcome of course ;-)
<jodh> mitsuhiko: but did you test the job with stop/start/restart followed by killing the PID to see how it behaves on respawn?
<mitsuhiko> jodh: it does not start
<mitsuhiko> there is no pid to kill
<mitsuhiko> it does not start
<mitsuhiko> and in case you have not noticed it, i am kinda pissed off right now because i am debugging this problem for two hours by now
<mitsuhiko> and now it turns out to be a bug in upstart with the only solution being a â¦ restart?
<mitsuhiko> there is also zero information that upstart gives even at highest debug levels
<mitsuhiko> i wonder if telinit c would fix it, but i am too scared to try that
<jodh> mitsuhiko: I don't know the full details of what has happened on your system. However, the limitation in Upstart is that is it not currently possible to rectify a problem cause by job misconfiguration.
<mitsuhiko> there was no job misconfiguration
<mitsuhiko> jodh: what would the gross hack be?
<mitsuhiko> i much rather not reboot that machine
<jodh> mitsuhiko:  it's not something I would consider - it involves exhausting the PID namespace until you get back to the PID shown in 'status <job>' to allow that (pid) to  be stopped.
<mitsuhiko> jodh: exhausting does not work
<mitsuhiko> it did not even try to issue a signal
<mitsuhiko> readlink("/proc/7340/root", "/", 4096)  = 1
<mitsuhiko> wat
<mitsuhiko> ah yes.  recorded the wrong pid
<mitsuhiko> 7340 != 7240.  Not sure why upstart showed the wrong one on the status message
<mitsuhiko> i suppose what happend is that on salt upgrade the process did not deamonize properly and upstart responded badly to it.
<mitsuhiko> race?
<freerobby> Can anybody explain why this works in a shell, but when I start a process via torquebox upstart, it doesn't honor the system ulimits? https://gist.github.com/7fff364c0bca20c27aa5
<freerobby> https://gist.github.com/6b22f5e1742f2bd63a75
#upstart 2012-08-30
<dj_jack> good morning
<mitsuhiko> $ sudo service salt-master status
<mitsuhiko> salt-master stop/killed, process 15251
<mitsuhiko> fuck this
<mitsuhiko> seriously
<mitsuhiko> jodh: it's doing that again
<jodh> mitsuhiko: there must be a problem with your job - mis-specification of 'expect' will result in such odd behaviour (how many other jobs have you seen do this?) Take a look at the cookbook in the debug section. Specifically, I'd consider changing your debug level via 'initctl log-priority debug' and keep an eye on your system log for that job.
#upstart 2012-08-31
<mitsuhiko> jodh: there is nothing wrong with the job
<mitsuhiko> feel free to doubt that, but unfortunately that is the case
<SpamapS> mitsuhiko: I would agree. The problem is upstart's fragility with regard to following forks.
<SpamapS> mitsuhiko: the two options for avoiding this bug, are to not use expect fork/daemon (run in the foreground) or fore-go the process tracking of upstart and use pre-start/post-stop to create a pid file/kill said pid.
<mitsuhiko> why does upstart track daemonizing behavior at all anyways?
<mitsuhiko> there are much better ways than that
<SpamapS> boot speed
<SpamapS> mitsuhiko: for some of the early plumbing, we want to start running dependant tasks/jobs ASAP.. and often, on fork of a daemon is ASAP
<mitsuhiko> what's wrong with cgroups?
<mitsuhiko> then you can see what damage the proess did after the fact
<SpamapS> nothing is wrong with cgroups
<SpamapS> they did not exist when upstart was written
<SpamapS> mitsuhiko: there is a mid-term plan to provide an alternative to the ptrace technique that expect * uses.
<mitsuhiko> SpamapS: ignore my snark. upstart just caused me so many issues this week :-/
<SpamapS> mitsuhiko: no worries. It has caused me quite a few issues the last 2.5 years ;)
#upstart 2013-08-26
<Screwba> xnox:  are you around?
#upstart 2013-08-27
<Screwba> xnox: You around?
<xnox> Screwba: yeap =) what's up?
<Screwba> xnox: you helped me the other day and stated "You mostly likely want your job to start at network-interface IFACE!=lo and before runlevel job is executed."  Would my `start on` statement look like "start on started network-interface IFACE!=lo and starting rc RUNLEVEL=[2345]"
<xnox> Screwba: looks right.
<Screwba> xnox: cool...going to give it a test by just having a script which polls for the IP and pauses for 2 mins writing the IP and timing to a /tmp/mytest.log file
<Screwba> xnox: I should not have to `emit` anything correct?
<xnox> Screwba: nope.
<Screwba> xnox: just write my screwbas_event.conf file in the /etc/init folder with a script section calling my /usr/local/bin/screwbas_script
<Screwba> xnox:  YOU ROCK !!!  If this works for me, then YOU RULE !!!
<Screwba> ;)
<Screwba> xnox: it is not working for me...   =(
<xnox> increase debugging and see what events are emitted.
<xnox> jodh: is "starting rc" ever emitted?
<jodh> xnox: yes
<xnox> Screwba: boot with --debug kernel arg and see what happens - e.g. order of the events.
<Screwba> xnox:  this is my /etc/init/mytesttask.conf file  http://pastebin.com/MW8657ew  maybe something wrong there in my script section?
<Screwba> xnox:  will try the --debug option now
<jodh> Screwba: that should be "start on net-device-up IFACE !=lo" or "start on started network-interface INTERFACE != lo".
<Screwba> jodh: thanks, I will change my conf in a min and test again...   =)
<Screwba> jodh: sorry, should it be both or one or the other?
<jodh> Screwba: you should use "start on started network-interface INTERFACE!=lo and starting rc RUNLEVEL=[2345]"
<Screwba> jodh:  testing now
<Screwba> xnox:  I added the --debug option to Grub but it does not seem like I am getting any debug info...I made the change permanent by editing /etc/default/grub and I also removed the quiet and splash options
<xnox> ... and run update-grub ?
<Screwba> xnox:  LoL...sorry, brain fart this morning
<Screwba> rebooting now...
<Screwba> jodh: that sort of worked, I have a 1 minute pause in my /usr/local/bin/testsjy.sh script, but it appears that the script only hits about 40 secs then maybe UpStart is killing it?
<Screwba> jodh/xnox:  testing again now...
<Screwba> jodh/xnox:  only ran for about 35 seconds this time
<Screwba> jodh/xnox:  New paste  http://pastebin.com/9V7G4B7E
<Screwba> updated with my testsjy.sh script and the updated .conf file
<jodh> Screwba: you need to get debug enabled. --debug gives a firehose of debug output that will get redirected by rsyslog depending on your config.
<jodh> Screwba: take a look at /var/log/upstart/$your_job.log too
<Screwba> jodh:  --debug enabled, powering off machine and rebooting in a min
<Screwba> jodh:  there is only a .1.gz file in /var/log/upstart/mytesttask.conf and that is an old version, seems like it is not logging there
<Screwba> back in a bit
<jodh> Screwba: your script isn't producing output then
<Screwba> jodh: it is only echo'ing to my /tmp/testjsy.log file, not sure if that would be output
<Screwba> jodh: or if I need to modify it so UpStart sees something else
<linuxnewbie> i'm having some trouble with an ts3 upstart script http://pastebin.com/ijFBrZnL ...it starts the server but it gives me wrong PID ..and status ts3 shows me ts3 stop/waiting
<linuxnewbie> if anyone have an idea what I do wrong please answer :)
<Screwba> jodh / xnox: I added a line to my script which just echo's to the console, it would appear that my script is running fully now but it does not seem to 'hold/pause' the boot sequence for the 1 minute that the script should run...does the `sleep` command work in the UpStart {script/end script} section?
<Screwba> jodh / xnox: I am now getting a log file in /var/log/upstart/mytesttask.log
<Screwba> xnox: it is not 'stopping' the boot sequence until my script finishes, I have now confirmed that.  My script continues to run even after logging in.  I used initctl2dot and created a graph, my script is definately dependant on network-interface and rc.
<Screwba> xnox / jodh: is it possible to totally pause the boot up between network-interface and rc until my script totally finishes?
<jodh> Screwba: if you look at upstart-events(7), you'll see that to do that you'd need to specify "start on starting network-interface ...". The 'starting' event blocks, whereas the 'started' event does not.
<Screwba> jodh:  ahhhhhhhh...so my start on should look like:  start on starting network-interface INTERFACE!=lo
<Screwba> jodh:  or the full string `start on starting network-interface INTERFACE!=lo and starting rc RUNLEVEL=[2345]`
<jodh> Screwba: the latter I think (although I don't have the full context of what you're trying to do).
<Screwba> jodh:  or possibly just the `start on starting network-interface` and from there, I poll to wait for an actual IP address to be assigned to the NIC, then do my work and exit 0
<Screwba> jodh:  I have a configuration script which I want to run on first boot up of an Ubuntu machine.  The script will mount a floppy and read information from files on there, then rename the host, join it to an Active Directory domain and configure a few other things on the system.  With CentOS/Red Hat it is easy because they are still using SysV init, with Ubuntu and Debian, it is harder since UpStart is the boot init
<jodh> Screwba: sounds like you want to use cloud-init. That solves your problem in a generic manner: https://launchpad.net/cloud-init
<Screwba> jodh:  xnox suggested I look at cloud-init but that is something else that I would have to teach to 'others' who may be using this.  I would really like to just get it done via UpStart natively since it is there by default and everything in my configuration script uses default/built-in utilities
<jodh> Screwba: cloud-init runs on centos too fwiw.
<xnox> Screwba: you still didn't tell us what you want to do. And upstart spend a lot of work speeding up the boot and parallelising. Not inserting 1 minute sleeps blocking everyone =)
<Screwba> jodh:  hmmmmmmm...I could not find any really good configuration scripts which would show the host rename and some other things.  I looked at the site but the docs seem to be lacking
<jodh> Screwba: maybe ping smoser then?
<Screwba> xnox / jodh :  Thanks a lot, I will tackle the cloud-init side of things and report back.   =)
<Screwba> jodh:  I will try that as well
<xnox> Screwba: do note that e.g. cloud-init runs in parallel, such that there is login prompt but cloud-init may still be running remaining parts of configuration (e.g. upgrading packages) but the generic stuff is done by that time (e.g. networking configuration & setting hostname)
<jodh> Screwba: also note that cloud-init runs earlier. it specifies 'start on mounted MOUNTPOINT=/' (note that mounted also blocks - see upstart-events(7) again).
<Screwba> thanks guys
<Screwba> the biggest thing with my script is joining the AD Domain, that usually takes 2 - 5 mins using the `net ads join` command
<Screwba> I really need this done before the GUI login is shown
<Screwba> =)
<xnox> Screwba: echo "start on started my-ad-task" >> /etc/init/lightdm.override
<xnox> Screwba: lightdm will not come up, until my-ad-task is finished & thus no-one will be able to login.
<Screwba> xnox:  but does that mean I need another task (/etc/init/my-ad-task.conf) created first?
<xnox> Screwba: yes, that would be where you run your scripts to do AD stuff.
<Screwba> xnox:  is there a rc.override as well?
<xnox> Screwba: you can .override any  .conf file
<Screwba> xnox:  you see what I am getting at...   ;-)
<Screwba> ahhhhhhhh...
<Screwba> xnox:  excellent...will give it a go
<xnox> Screwba: and it overlays config. It's documented in man pages & the cookbook......
<Screwba> thanks again guys for your information and especially your PATIENCE with me...   =)
<Screwba> thanks again
<Screwba> all:  what does `instance $JOB` do?  I see it but when I try to use it, I get an error when I do a `status myjob`
<Screwba> how does the script get the $JOB variable populated?  is it internal to UpStart?
#upstart 2013-08-28
<ArthurBorsboom> Hi guys, I have an issue with an init script (upstart job), which I have a hard time to solve. Would somebody mind to listen and maybe give suggestions for solving my issue?
<Screwba> I have been playing with the blocking of the boot process and I can not get it paused when depending on `startingï¼
<Screwba> network-interface INTERFACE!=lo` but I can get it paused when depending on `starting rc-sysini
<Screwba> xnox:  ^^^^
<Screwba> xnox:  your patience paid off, looks like all your pointers, as well as jodh pointers, have helped me out and I can get the pause I require during the bootup sequence now
<Screwba> THANKS GUYS !!!
<jdhore1> How can i tell upstart to autorestart a process even if it returns exit code 0?
<jdhore1> would i just do normal exit HUP? (so it only considers SIGHUP something normal)
#upstart 2013-08-29
<rob_> hi
<rob_> im trying to get an upstart job to log to logger but whatever i try it doesnt seem to work, if i run the same command at the console its fine
<jodh> rob_: what do you mean by "logger" - syslog? or upstarts logging?
<jodh> rob_: also, try reading http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in, http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job, http://upstart.ubuntu.com/cookbook/#determining-why-your-service-fails-to-start
#upstart 2013-09-01
<SmileyChris> I've put a new .conf in /etc/init -- running `service myservice status` still returns "unrecognized service". I'm guessing I need to refresh the service list somehow?
<xnox> SmileyChris: you can do $ sudo initctl reload-configuration
<SmileyChris> oh duh, I wasn't running sudo service :P
<SmileyChris> but thanks, xnox
<xnox> SmileyChris: and do check the conf with: init-checkconf /etc/init/foo.conf
<xnox> maybe it has errors.
<xnox> SmileyChris: ah ;-) yeah...
#upstart 2014-08-25
<grahamc> Hi, I have made serviceB stop when I stop serviceA, but when I start serviceA, is there a way to automatically start serviceb?
<grahamc> my serviceB has this start on line: start on filesystem and started serviceA
<lu_> I'm trying to make a simple upstart script and test it on the command line, but it doesn't seem to work.   I'm using these commands:
<lu_> initctl emit x1
<lu_> x1 is the name of my file in /etc/init/x1.conf
<lu_> my script is: http://pastebin.com/xRRPPRr5
<lu_> It's just a simple iptables script that I know works well for the commands on the command line.
<lu_> But it doesn't work when I try to test it with initctl
<lu_> Who are the fucking retards who made upstart?
<lu_> I've got fucking question for them idiots!!!!
<grahamc> lu_ didn't wait around very long :|
<puhuri_> I would actually like to hear the answer (maybe ignore last two lines) :-)
<puhuri_> Is there somewhere pointer how to debug upstart scripts?
<puhuri> on Ubuntu 14.04 upstart usb_modeswitch gets killed but no trace about reason is in log files
<puhuri> and fails to restart or start
<cwillu_at_work> puhuri, not much to that job; if it's dying, it's probably due to the process itself
<cjenkin1> I need to create an upstart job to fix a bug with my platform's system time / RTC. I have a script that will do the trick, but I need to know if, inside a script declaration, there is some way to avoid immediate exit on error
<cjenkin1> Reading the RTC occasionally throws an error (device busy) which clears up on the second read, and I my code handles that, but I need the job to keep trying 
<cwillu_at_work> cjenkin1, || true
<cjenkin1> cwillu_at_work: Heh, didn't think of that. Clever.
<cjenkin1> My bash-fu is lacking
<cwillu_at_work> well, sh-fu
<cwillu_at_work> bash-isms won't work in script tags unless you point sh at bash, and even then, bash will still be mostly acting like sh
<cjenkin1> Gotcha, good to know
<CrazyTux[m]> Hey guys â starting to get frustrated, it seems the packaged tarballs are broken job.h:200: error: redefinition of typedef 'JobProcessData'
#upstart 2014-08-26
<CrazyTux[m]1> Hey guys trying to compile from source and keep getting: job.h:200: error: redefinition of typedef 'JobProcessData'
<CrazyTux[m]1> this is 1.13.1
<CrazyTux[m]1> Any ideas?
<p3rsist> Hi guys. I'm having problems with upstart and monit on Amazon Linux
<p3rsist> It doesnt start it correctly 
#upstart 2014-08-28
<shorena> can anyone help me with upstart on ubuntu server 14.04? I want it to launch my bitcoind after boot, yet the very simply basic start on runlevel [2345] exec /usr/bin/bitcoind -daemon does not work :C
<jodh> shorena: have you looked at the cookbook? What does 'sudo cat /var/log/upstart/$myjob.log' show? Also http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
<jodh> and http://upstart.ubuntu.com/cookbook/#determining-why-your-service-fails-to-start
<shorena> the log is helpfull is throws a bunch of errors related to bitcoind, looks like its unable to find the config file... its run as root isnt it?
<shorena> its running, thanks :)
#upstart 2014-08-29
<jgornick> Hey guys, how can I verify that my upstart script is valid.
<jodh> jgornick: http://upstart.ubuntu.com/cookbook/#init-checkconf
<jgornick> jodh: Perfect! Thank you!
<jgornick> Is it possible to evaluate a path when setting environment variables: env SERVICE_NODE_BIN=$(which node)
<jgornick> If I use start-stop-daemon in my script stanza, do I need to include any cleanup stanza to start-stop-daemon --stop my PID? Or becuase my original start-stop-daemon creates a PID, upstart knows how to track that and stop it properly.
#upstart 2014-08-30
<rkulagow> hi, question on the best way to accomplish something
<rkulagow> long-running php scripts that pull work out of a jobqueue
<rkulagow> different scripts, different jobs, so they're unique.
<rkulagow> if a script aborts for some reason, i'd like it to get restarted
<rkulagow> i've read the cookbook, and want to check strategy on how to proceed
<rkulagow> the most likely reason that the scripts exit is due to mysql server going away; restarting the script re-inits the db connection, so the scripts then work correctly
<rkulagow> the parent that launches the sub-scripts seems like it would be best. but if i just do 4 individual scripts, that are of the for i in `seq 1 4` variety, if instance #3 dies, will upstart restart that one, or does it consider the group of 1 through 4 as a single instance and won't restart the group until the last child dies?
#upstart 2015-08-26
<dgarstang> how do I source env vars in upstart job and preserve into exec ?
#upstart 2015-08-27
<gregp_> hi guys. I found interesting thing today, when I run python script that runs ansible.playbook.PlayBook()  manually, it works fine.  When I do it through upstart (/etc/init/ script)  it lets ansible playbook running for some time then kills it and continues runnin python script.  Any thoughts how to prevent this from happening?
#upstart 2015-08-29
<topi`_> reading the Cookbook now. I'm trying to mount an ecryptfs filesystem at boot time, but it requires a certain script to be run (that actually contains a hidden key for the FS) ... how do I create a "oneshot" type of .conf file for this?
<topi`_> this is what I tried, but I'm not sure if I can have other jobs depend on this?
<topi`_> description	"ecryptfs init"
<topi`_> start on local-filesystems
<topi`_> stop on deconfiguring-networking
<topi`_> exec /root/domount 
#upstart 2016-08-29
<majuscule> How can I redirect stdout/err to a logfile using start on filesystem exec ?
<majuscule> looks like i can just add normal >/var/log 2>&1 to the exerc
<majuscule> exec
<AnrDaemon> majuscule: Don't do that crap.
<AnrDaemon> Use "console log".
<majuscule> hmm, the docs on that are a little unclear. console log --logdir /var/log/ ? and then what does it name the file
<AnrDaemon> In Ubuntu, it's /var/log/upstart/$JOB${INSTANCE+-$INSTANCE}.log
<AnrDaemon> And system's logrotate already set to wrap them around.
<majuscule> gotcha, thanks AnrDaemon 
#upstart 2016-08-31
<aquarius_> I have a "two stage" process; first, I make a curl request to a URL which returns me a hostname, and then I ssh to that hostname with autossh. I'd like to have upstart manage this process so that if autossh dies it gets respawned, but I don't want it to run the curl again if it gets respawned; just restart autossh. How am I best to do that with upstart?
<AnrDaemon> aquarius_: I'm not sure it's a good idea to build something like that. What if it drops because host moved?
<AnrDaemon> How would you manage repetitive respawns in transition process?
<AnrDaemon> If I were you, I'd write a wrapper app to manage respawn of autossh.
<AnrDaemon> And set up that as the job.
<aquarius_> AnrDaemon: I thought about that, but I don't think I can tell the difference between "it dropped because there was a network wobble" and "it dropped because the host is gone", but I want to reconnect on wobbles and do a new curl request if the host goes away
<aquarius_> I do see your point though.
<AnrDaemon> That's up to your wrapper to solve. Ping the host, if not available, lookup and ping again, for example.
<aquarius_> on the actual upstart point, what I've done is have two jobs; one is start on network-up and does the curl, then emits start-the-ssh HOST=somehost, and the second is start on start-the-ssh; stop on network-down; respawn; exec autossh $HOST
<aquarius_> can I tell from inside a job if I was respawned by upstart?
<aquarius_> what I'm trying to avoid is writing my own tiny service monitor to deal with autossh dying, because upstart's good at that and I'm not :)
<aquarius_> Second upstart question. Does upstart fire an event when one connects to or disconnects from a wireless access point? I can put a script in /etc/NetworkManager/dispatcher.d to do that and fire a custom event, of course, but it'd be nice to stay within upstart.
<AnrDaemon> aquarius_: If you want to go that route, you can just make second job an instance.
<AnrDaemon> But you'll need to have first job start on stopped XXX.
<aquarius_> AnrDaemon: can you explain that in a bit more detail? I don't think I really understand instances
<AnrDaemon> Instance is a job that can be started multiple times, each identified by a key.
<AnrDaemon> So, say, you make it "instance $HOST" and start one instance per host. http://upstart.ubuntu.com/cookbook/#instance
<aquarius_> ah, I get it, I think. Cheers
#upstart 2017-08-30
<lilis> Hi guys, I'm trying to start a GUI application through Upstart but it has to have root privilege. How do I do that?
<lilis> I can start it through `sudo -E` but not just `sudo` or `sudo su -c`
<lilis> but not*
<lilis> So I guess it needs certain environment settings but I'm not sure how to put them in Upstart
<xnox> lilis, you most likely need to determine current active display and pass X server variables for such a display.
#upstart 2017-08-31
<JanC> either that or you need something else inside the X session which you can trigger to start the application
