#upstart 2007-07-16
<moonz> hello world
<moonz> does someone has a few minutes ?
#upstart 2007-07-18
* Starting logfile irclogs/upstart.log
<wasabi> heh. my brain headed self just noticed ubuntu live was not free.
#upstart 2007-07-19
<twb> Does anyone know the status of upstart on Sid?
<twb> Rather, what is the status of upstart on Sid?
<JK456> hi upstarters :)
<JK456> i dont get how i can use the respawn system :
<JK456> when i use it on a soft who forks, upstart dont see the son
<JK456> and think the soft is dead, and respawn it
<twb> I am not a regular here, but I believe the upstart position is that daemons that fork into the background are broken.
<twb> What package are you having problems with?
<JK456> some soft we wrote ourself
<JK456> its a quite personalized system
<JK456> but for exemple portmap daemon
<JK456> it forks after launch
<twb> Are you sure about that?
<JK456> well i am gona check again
<twb> I think upstart would say that portmap should be run with -d to prevent it disconnecting.
<JK456> portmap forks, or if it doesn't it is restarted for no reason
<JK456> -d ?
<JK456> is it an upstart option ?
<twb> Oh sorry, -f is more appropriate.
<twb> See the portmap manual.
<twb> "-f      (foreground) prevents portmap from running as a daemon, and causes log messages to be printed to the standard error output."
<JK456> ok, its an option of portmap
<twb> As I said, I am not associated with upstart.
<twb> But I think they would advise you to add such an option to your program, too.
<JK456> but it implies to modifie the code of all daemon in our system :s ^^
<JK456> but your informations are very usefull :)
<JK456> thanks a lot
<ion_> One needs to add the daemon stanza to the job definition, but handling forking daemons isnt completely implemented yet.
<twb> I'm afraid I can't help more; if you wait long enough a regular will stop by.
<JK456> yep, i had the chance to talk them sometimes, freenode is great for that
<ion_> The sole reason why Upstart needs to be pid 1 is that it can support forking daemons. Theres no upstart position that forking daemons are broken AFAIK.
<twb> I apologize, I was clearly mistaken.
<twb> Perhaps I am thinking of the cinit people
<JK456> ion_ : oh ? how does it work ?
<JK456> twb : no prob
<twb> Does upstart on ubuntu still just call out to sysvinit compat for just about everything except inittab?
* twb remembers to check https://launchpad.net/distros/ubuntu/+spec/replacement-initscripts
<ion_> Pid 1 receives the SIGCHLD for parentless processes. But handling it isnt implemented yet AFAIK.
<ion_> twb: The sysvinit scripts havent been replaced with upstart jobs yet.
<twb> Doesn't that mostly take away the real benefit of using upstart for regular users?
<JK456> ion_ : if i understand well, i will be possible to restart forking daemon, but it is not yet possible ?
<ion_> jk456: Yes, thats the current situation as far as i know.
<ion_> twb: I dont see what you mean. The scripts will be converted to upstart gradually.
<twb> I mean that the real appeal of upstart (at least to me) is reduced boot time as a result of aynchronous service startup.  If upstart currently just uses run-parts to launch everything in rcS.d and rcN.d, then none of those scripts will be launched asynchronously.
<JK456> ok, and i guess it is not possible to use inittab respawn because there is only one process (the 1) receiving sigchild
<ion_> twb: I think the major point of upstart is a flexible bootup process that Just Works where sysvinit scripts would fail unless horrible kluges are added to them. Reduced boot time is just a bonus.
<twb> In what way does it "Just Work" more than sysvinit?
<twb> I mean, *right now* as opposed to after sysvinit scripts have been completely replaced
<JK456> twb : if you seek for speed, you can test initng
<twb> That's the gentoo thing?
<JK456> initng ?
<ion_> Right now the system is booted by the sysvinit scripts.
<JK456> initng : no i dont think i is for a specific distrib
<twb> But it's pioneered on gentoo, in the same way that upstart is on Ubuntu?
<JK456> dont knwo, there is rpm and packages for lots of distrib 
<JK456> ion_ : in my case, we builded a personalized init, we had 23 seconds at boot, we are at 5
<twb> "built"
<twb> ion_: I like their icon better than upstarts :P
<JK456> (in init phase, there is also 15 seconds for hardware loading)
<JK456> twb : but there is less features in initng
<JK456> _ion : so thanks to upstart we won 18 seconds
<JK456> (its linux embedded soft)
<JK456> twb : why dont you write your own scripts ?
<JK456> it is not so so hard to do
<JK456>     `-- rcS
<JK456>         |-- S02mountvirtfs
<JK456>         |-- S10checkroot.sh
<JK456>         |-- S30checkfs.sh
<JK456>         |-- S39ifupdown
<JK456>         |   `-- S40networking
<JK456>         |-- S40hostname.sh
<twb> Yes, it is.
<JK456>         `-- S55urandom 
<twb> It is hard because I don't have millions of other Debian users helping me debug them.
<JK456> on mountvirtfs, you launch the runlevel you want
<JK456>     |-- rc3
<JK456>     |   |-- S00set-date
<JK456>     |   |-- S02engine
<JK456>     |   |-- S05sysfs
<JK456>     |   |   `-- S06udev
<JK456>     |   |-- S11messagebus
<JK456>     |   |-- S65xinetd
<JK456>     |   `-- S70lircd
<JK456> thats the init profile we use (i removed the confidential parts)
<JK456> twb : you just have to call the scripts in rcS.d and rcX.d
<JK456> this scipts will do the job
<JK456> so all your files in event.d will look like to this :
<JK456> description     "test"
<JK456> author          "jerry"
<JK456> start on stopped mountvfs
<JK456> console output
<JK456> script
<JK456> 	echo "portmap"
<JK456>  	exec /etc/rc.d/rcS.d/S41portmap start
<JK456> 	echo "done"
<JK456> end script
<twb> Please stop flooding.
<JK456> ^^ k
<JK456> hope it helps
<twb> Ew, bootchart-view is written in Java.
<twb> ion_: have you looked at using LSB headers to programmatically convert sysv init scripts to upstart scripts?
<ion_> Is there a LSB header for things like start when network is available, start when all partitions are mounted and writable, start when a sound card has been connected? If not, doing the conversion manually will yield much better results.
<twb> Yes.
<JK456> i agree too
<twb> I concede that it won't be perfect, but I wonder if it can save you a lot of grunt work, allowing you to focus on the second 90%
<JK456> twb : we wrote it in a day 
<JK456> the main part is to kwow the dependencies
<JK456> after that you just call the sys scripts
<JK456> or you copy them
<twb> http://user.skolelinux.no/~pere/mypapers/200706-bootseq/200706-bootseq.html
<ion_> Upstart doesnt exactly deal with dependencies, its the other way around.
<julo> hi
<julo> I have created an upstart script and it fails to start automatically: "unable to read: Invalid argument", but if I manually start it, it works well.
<julo> Any idea ?
<julo> salut
<julo> j'ai un problme avec upstart: j'ai cr un script, et  l'amorage du  j'obtiens l'erreur "unable to read: Invalid argument" au lancement du script. Par contre, si je lance ce script  la main, a marche.
#upstart 2007-07-20
* Starting logfile irclogs/upstart.log
<AlexExtreme> hmm
<AlexExtreme> freespire 2 development builds are using upstart
#upstart 2009-07-13
<rjbell4> Keybuk: I was wondering if you could elaborate, as ion mentioned yesterday.
<Keybuk> rjbell4: what's up?
<rjbell4> I asked the following yesterday: Is there any support in upstart for monitoring multiple child processes?  I've found "expect fork" and "expect daemon", which seem to monitor a single child or grandchild, but what if there are several child processes, and if any of them fail then I want to take action?
<Keybuk> that's planned
<Keybuk> though obviously within certain limits
<Keybuk> since you'd need to know beforehand how many children to expect
<Keybuk> how long it typically takes for that number of children to appear
<Keybuk> and wouldn't want to die if they double-fork()d along the way
<Keybuk> etc.
<ion> rjbell4: Please describe your exact use case.
<rjbell4> Keybuk: Okay, but not yet implemented, I gather?
<ion> When i said 0.10 yesterday, i meant the-next-major-version-still-in-planning.
<Keybuk> correct
<Keybuk> rjbell4: but without more details, I'm not sure that what's planned will actually do what you want
<rjbell4> ion: We have replaced init with upstart on our product, and one of the services we run forks a few different processes to do related-but-separate tasks.  If any of those processes fails (segfaults, whatever), the whole thing should be restarted.
<Keybuk> how would you tell Upstart, in advance, what those related-but-separate tasks were?
<Keybuk> what can Upstart use to distinguish them?
<Keybuk> does the parent process that spawned them remain, or does that terminate?
<Keybuk> do any of the processes daemonise, or fork?
<rjbell4> I was actually intrigued by the "read-a-pid-a-file" approach, as I thought if the service had support, that might be a cheap way to support telling Upstart which processes to monitor.  But that support appears to have been removed.
<Keybuk> are the spawned processes the same executable, or are they exec() of other executables?
<Keybuk> rjbell4: right, it's not very reliable
<rjbell4> It might suffice to tell upstart to monitor the 3 children of the process that it kicks off, rather that just looking for 1 with "expect fork".  I'm not positive it would work, but I think it might.
<Keybuk> can you answer the other questions above?
<rjbell4> Keybuk: In this case, I think the parent terminates, and the children keep running.  I'd have to check to be certain, but I believe that's correct.  It's possible that they *should* daemonize (by forking again), but don't.
<ion> If one of the children dies, what should happen to the other children?
<Keybuk> the problem there is that you're spawning more then three new processes then
<Keybuk> so how does Upstart know it's terminating because it's daemonising
<Keybuk> or terminating because of an error?
<rjbell4> ion: I suspect that should be handled however a "stop" would normally be handled
<rjbell4> Keybuk: How is that different from 'expect daemon'?  For example, couldn't there be an 'expect 3 daemons'-like functionality?  I might be missing the problem.
<rjbell4> Oh, BTW, good job with upstart.  I'm actually considering what some colleagues have done with Upstart and wondering if it couldn't be done better / easier.
<Keybuk> because that just follows one line of processes
<Keybuk> you need the mechanism to follow multiple children
<Keybuk> and know when it's reached the stable end
<Keybuk> I'm thinking, from the information you've given, that it's not a hard problem
<Keybuk> I assume that if these children were to exit(0) that'd be ok?
<rjbell4> Keybuk: I'd actually expect that to happen only as a result of a stop event.  If they terminated any earlier it should be with an error.  Terminating earlier with a 0 exit status "should never happen", so I wouldn't presume to describe what the result should be.
<rjbell4> Keybuk: re: hard problem.  I suspect it's just extra work to track things.  For the "expect 3 daemons" case, you trace the primary process until it forks, then continue to trace the child process as it forks 3 times, each time adding the child process to the list of processes to monitor for that service.
<rjbell4> I suppose an argument could be made that this crosses some line and something else should be monitoring more complex models like this, but Upstart just seems to be in the right place to do this.
<Keybuk> no, you're not following
<Keybuk> the problem is how do you keep count of the forks
<Keybuk> a - b - c
<Keybuk>      +- d
<Keybuk>      +- e
<Keybuk>      +- f
<Keybuk> that's 5 forks, not 3 ;)
<ion> How about this: keep track of *all* children. Whenever one of them exits with a zero exit status and it wasnât the last process, just remove it from the child list and continue as usual. If one of the dies with a non-zero exit status or due to a signal, consider that an error and kill the other processes (if any). When the last process exits with a zero exit status, consider that a non-error exit.
<Keybuk> ion: that's exactly what I was thinking ;-)
<rjbell4> Keybuk: Right, you're not just keeping track of the forks, but which process forks.  You ptrace a until it forks, then you continue to trace b until it forks 3 times (in this case, for c and d and e, but not f, because you only told Upstart to trace three children)
<Keybuk> ion: that fits with the general model I was going for with netlink
<rjbell4> Keybuk, ion: Sounds reasonable, but since the mechanism is ptrace, that unfortunately rules out running a debugging on any of those processes, right?
<Keybuk> rather than having "the main process" we're in the "running" state with N processes
<ion> Substitute zero exit status with the value in ânormal exitâ
<rjbell4> ^debugging^debugger
<Keybuk> rjbell4: the mechanism is not going to be ptrace for long
<Keybuk> ptrace doesn't work
<Keybuk> ion: right - normal exit usually only implies 0 if it's a task
<rjbell4> Keybuk: Oh, well that probably colors my responses then.
<Keybuk> but it makes sense that normal exit implies 0 if it's a task *or* there are other processes still running
<rjbell4> Keybuk: You guys know what you are doing better than I do (obviously); I'm just providing feedback from a consumer. :-)
<Keybuk> rjbell4: I think we can definitely make this work for you
<rjbell4> Keybuk: Out of curiosity, what's the new mechanism planned to be?
<Keybuk> rjbell4: using a Linux feature called the "proc connector"
<Keybuk> it's a netlink socket from which you receive messages for all fork(), exec(), setsid(), setuid(), etc. calls
<rjbell4> Keybuk: Interesting, thanks for the info.
<Keybuk> ptrace has an annoying race condition
<Keybuk> when you get the TRAP for fork(), this actually happens in the parent *after* the child process is spawned
<Keybuk> the child STOPs of course
<Keybuk> but Upstart ignores that, because it didn't know the pid
<ion> Say, Upstart receives a message from the proc connector saying âprocess 1234 exited with status 1â. While Upstart begins to process that message, 1234âs child, 1235 already exited with exit status 1 and a new, unrelated process happened to start with pid 1235. Upstart happily kills 1235 and then continues to read further messages from proc connector (âprocess 1235 exited with status 1â etc). Is this remotely possible? (I havenât looked at how proc ...
<ion> ... connector behaves yet.)
<ion> keybuk: Highlight
<Keybuk> hmm
<Keybuk> ah
<Keybuk> no, you're forgetting one key detail
<Keybuk> pids aren't reused until you wait() and clean them up
<Keybuk> if the process is a direct child of Upstart, or a daemon that has been reparented to Upstart
<Keybuk> (pulls up the notes he made about this on his iPhone)
<Keybuk> right
<Keybuk> receiving a "process 1234 exited" from the proc connector *before* the SIGCHLD means we store a flag
<Keybuk> likewise receiving a SIGCHLD for process 1234 before we see the proc connector entry means we store the flag
<Keybuk> then on the opposite one, we actually take action
<Keybuk> in other words, a child of init is not considered dead until we've been told about it *and* seen the body
<Keybuk> at that point, all of its children are implicitly reparented to init
<Keybuk> so again, init would receive SIGCHLD on them as well as the proc connector event
<Keybuk> so provided we wait for the notification and the body, we're safe
<Keybuk> now there's a race as you say, if the children aren't reparented
<Keybuk> if the tree is
<Keybuk> a
<Keybuk>  `-b
<Keybuk>  `-c
<Keybuk> a is our child, we get SIGCHLD
<Keybuk> but b isn't, it's a's child
<Keybuk> in that case, I'm not sure that it's up to upstart to supervise b
<Keybuk> that's b's job ;)
<Keybuk> err, a's job
<Keybuk> but if a dies, proc connector means we know about b and c
<Keybuk> so know they're reparented to us
<Keybuk> so Upstart *will* supervise them both
<sadmac2> Keybuk: is it possible to get information about b from proc connector before a dies?
<Keybuk> sadmac2: yes, proc connector tells us everything
<Keybuk> we will know that a forked b
<Keybuk> the exception is if either b or c call setsid(), to put themselves out of a's session
<Keybuk> the only reason a process would call setsid() is if it *needs* to be the leader of a session
<Keybuk> because it wishes to control a tty
<Keybuk> e.g. ssh
<Keybuk> in which case, we deliberately abandon it
<Keybuk> because when a (sshd) dies, we don't want to just supervise b and c (ssh-login scott) in their place
<Keybuk> we want to consider a dying a bad thing
<Keybuk> and we don't want to kill b or c either
<sadmac2> Keybuk: yes, I was happy when you figured out those bits
<sadmac2> Keybuk: here's a question: how do things like gnome-session work in upstart-of-tommorow? We don't really want another per-user session manager duplicating most of our effort, do we?
<Keybuk> it's quite easy to just have upstart be the session manager
<Keybuk> the question turns out to be whether we want pid #1 to be that session manager,
<Keybuk> whether we want a middle-man session manager running as the user,
<sadmac2> Keybuk: my thought was gnome-session isn't a process anymore. Its just a taskless state that all the session services depend on
<Keybuk>   (but everything still gets reparented to #1 anyway)
<Keybuk> or whether we actually want a mini-init for user sessions
<Keybuk> such that any user session daemon actually gets reparented to the user session manager
<Keybuk> and make the process trees look pretty
<sadmac2> Keybuk: can we actually manipulate the reparenting behavior right now?
<Keybuk> not without a patch Lennart sent to lkml
<Keybuk> http://lkml.org/lkml/2009/5/28/430
<ion> keybuk: Alright
 * sadmac2 now cringes every time exit.c is patched
<Keybuk> lol, why?
<sadmac2> Keybuk: its like playing Jenga
<Keybuk> it's just the kernel
<sadmac2> I really do have to find time to just rewrite that whole file
<Keybuk> one of the simpler parts reall
<ion> http://www.youtube.com/watch?v=F9BmTmMEOhQ
<sadmac2> Keybuk: its particularly poorly written IMHO. if (some return value) { // we have a spinlock } else { //we gave up the spinlock awhile ago } is never a good thing to see
<sadmac2> ugly code is worse than broken code. Bugs are easier to fix than hideous.
<sadmac2> Keybuk: so in order to take 0.6 in Fedora, we need to not regress on the state transfer thing.
<Keybuk> does the patch apply?
<sadmac2> Keybuk: and since 0.6 is hopefully forward compatible, that means we need a solution that you've had some architectural say in.
<sadmac2> Keybuk: the patch might nearly apply (I'd imagine it needs some heavy reworking) but if you're going to do it differently when you do it, its probably best that we do it your way.
<ion> keybuk: Btw, now that jobs are in /etc/init without any 0.6 namespacing, how do you plan to have 0.10 handle 0.6 jobs cleanly? :-) Iâm still advocating a separate parser for 0.6 jobs that outputs 0.10 job objects.
<sadmac2> Keybuk: what's the last thing you got before you dropped?
<Keybuk> ion: there's not that much difference in the syntax
<Keybuk> sadmac2: can't remember, what was the last thing I said? :)
<sadmac2> Keybuk: does the patch apply?
<Keybuk> haven't tried
<sadmac2> Keybuk: no, you were asking me
<sadmac2> :)
<sadmac2> 10:35 < sadmac2> Keybuk: so in order to take 0.6 in Fedora, we need to not regress on the state transfer thing.
<sadmac2> 10:35 < Keybuk> does the patch apply?
<sadmac2> 10:35 < sadmac2> Keybuk: and since 0.6 is hopefully forward compatible, that means we need a solution that you've had some architectural say in.
<sadmac2> 10:38 < sadmac2> Keybuk: the patch might nearly apply (I'd imagine it needs some heavy reworking) but if you're going to do it differently when you do it, its probably best that we  do it your way.
<sadmac2> Keybuk: ^^ that's what lead up to you dropping
<Keybuk> sadmac2: the problem is I don't have a preferred way of doing it yet
<Keybuk> and I glanced through your patch, and I don't see how it can possibly work
<Keybuk> you don't transfer most of the state
<sadmac2> Keybuk: its enough. It does depend on the configs lining up.
<sadmac2> Keybuk: it fixed our broken TTYs anyway
<Keybuk> it isn't enough though
<Keybuk> what if a job is mid-starting?
<sadmac2> Keybuk: bear in mind that I didn't write this. Just reformatted it :)
<sadmac2> Keybuk: what are we missing for that. We have the state and the pid. The new process should get the signal and move it forward.
<Keybuk> the event queue?
<Keybuk> the attached events?
<Keybuk> if there's a "start" command running, you don't transfer the D-Bus message structure from one instance to the other
<Keybuk> (let along the d-bus connections)
<sadmac2> Keybuk: yes. that is true...
<sadmac2> Keybuk: wouldn't it be better to just stop taking input and flush all those out?
<sadmac2> well, the way blocking is done now you still need the event queue
<sadmac2> no that won't work yet..
<Keybuk> the problem is you need to be in a state where all services are running or waiting
<Keybuk> and all tasks are waiting
<Keybuk> it may not be possible to be in that state
<sadmac2> yeah. I saw it captured the other states but didn't look at what it needed to advance out of them...
<sadmac2> time to stop trusting patches from strangers
<sadmac2> Keybuk: wb
<ion> Instead of /etc/init/dbus-reconnect.conf, why not do telinit q in /etc/init.d/dbus, and then in /etc/init/dbus.conf whenever itâs moved over?
<Keybuk> ion: this was a simpler hack
#upstart 2009-07-14
<plautrba> Keybuk: there is problem in tests/test_utmp.c:1160 (test_write_runlevel)
<plautrba> TEST_EQ (err->number, EBADF);  after ret = utmp_write_runlevel (utmp_file, wtmp_file, '2', 'S');
<Keybuk> what is ret and err->number?
<plautrba> but my man page for pututxline(3) describes that errno could be set in values as open(2) does
<plautrba> so errno is EACCESS
<plautrba> as file can't be open because 0400
<Keybuk> have you actually tested that?
<plautrba> for writing
<plautrba> yes
<Keybuk> because I looked at the glibc code, and it never bothers to check the return value of open () :p
<plautrba> http://pastebin.dqd.cz/940  with this patch
<plautrba> http://pastebin.dqd.cz/941  message from make check
<Keybuk> which glibc version?
<plautrba> glibc-2.10.1-1.x86_64
<Keybuk> maybe that was fixed in 2.10
<plautrba> it's fedora 11
<Keybuk> plautrba: http://bazaar.launchpad.net/~scott/upstart/trunk/revision/1185
<plautrba> Keybuk: sorry that I haven't metioned same problem on         at tests/test_utmp.c:1421 (test_write_shutdown).
<Keybuk> plautrba: fixed in 1186
<plautrba> Keybuk: thanks, everything passed
<Keybuk> you're not using 2.6.31 then
<plautrba> still 2.6.29.4-167
<plautrba> is there any problem with 2.6.31?
<Keybuk> inotify regressions with the switch to fanotify
<ion> Sounds trustworthy. http://www.torrentreactor.net/torrents/1810935/ubuntu-8-04-Hacked-Heron
<Keybuk> lol
<ion> Sounds trustworthy. http://www.torrentreactor.net/torrents/1810935/ubuntu-8-04-Hacked-Heron
<ion> Whoops
<ion> Itâs always nice when you spout crap into IRC channels when your WLAN breaks so that your IRC client receives your keypresses but you donât get packets back. :-P
 * Keybuk was delighted to find the Upstart logo in Unicode today
<Keybuk> âº
<Keybuk> (almost anyway :p)
<sadmac> Keybuk: you could probably get them to add it. If they have room for Klingon, could logos be far behind?
<sadmac> U+8FFB STARBUCKS
<sadmac> U+8FFC STARBUCKS WITH UMLAUT
<ion> :-)
<Keybuk> so I worked out what Upstart should dump to /dev/console in the case of crash
<Keybuk> W     W      W        
<Keybuk> W        W  W     W    
<Keybuk>               '.  W      
<Keybuk>   .-""-._     \ \.--|  
<Keybuk>  /       "-..__) .-'   
<Keybuk> |     _         /      
<Keybuk> \'-.__,   .__.,'       
<Keybuk>  `'----'._\--'      
<Keybuk> VVVVVVVVVVVVVVVVVVVVV
<ion> I donât get it. :-P A reference to something?
<sadmac> Keybuk: hitchhiker's guide?
 * Keybuk facepalms
<Keybuk> it's a fail whale
<Keybuk> http://www.readwriteweb.com/archives/the_story_of_the_fail_whale.php
<ion> Ah. Iâm not very familiar with Twitter.
<sadmac> meh. not that exciting
<sadmac> also its hard to recognize as ascii.
<sadmac> I'd consult the real professionals:
<sadmac> http://love6.2ch.net/aasaloon/
#upstart 2009-07-15
<bgamari> Does upstart log job file parse errors anywhere?
<bgamari> For some reason upstart isn't listing my job yet I can't seem to figure out what's wrong with the job
<mbiebl> bgamari: it logs them to the system log
<mbiebl> On Debian/Ubuntu /var/log/syslog
<mbiebl> looks like this: Jul 15 06:59:57 pluto init: /etc/init/dbus-reconnect.conf:7: Unknown stanza
<ion> update-base-branch â Update the contents of a Git branch with a script | http://github.com/ion1/update-base-branch#readme | http://github.com/ion1/update-base-branch/tree/master/examples#browser
<sadmac> ion: its not particularly clear to me what that does
<ion> Say, you have the branch âbaseâ or âupstreamâ or whatever that contains the default configuration for $foosoftware, and the branch âmasterâ which forks from âbaseâ, containing your changes to the defaults. The script handles the updating of âbaseâ. Youâll have a script such as â#!/bin/sh, set -e, cmd="$(update-base-branch --wrapper)", eval "$cmd", cp latest-upstream-configs-from-somewhere .â and then all you need to do to merge your ...
<ion> ... changes with upstreamâs changes is ./the-script && git merge base.
#upstart 2009-07-16
<ion> http://tobytripp.github.com/meeting-ticker/
<Keybuk> erk
<Keybuk> it looks like LP was spamming everyone in the upstart-devel team with bugs
<Keybuk> is that right?
<sadmac> Keybuk: I suppose... I have it filtered to a folder so it didn't bother me much
<Keybuk> the idea was for maintainers to be able to modify bugs
<Keybuk> though I guess if you don't mind getting cc'd on them, I can leave it
<sadmac> well that's my vote. dunno how ion / plautrba / mbiebl feel
<sadmac> Keybuk: in furtherance of queue-ifying everything in Upstart I'm also reworking how blocking is done.
<Keybuk> oh right, what you thinking
<sadmac> Keybuk: basically I'm introducing a "trigger table"
<sadmac> Keybuk: a trigger is 1) a list of events that will fire it (event operator with only 'or's basically) 2) a callback, 3) a "recurring" flag (explain in a moment)
<sadmac> Keybuk: when an event is processed (an event can now be an "external" event, which is what they all are now, or another type of event like a start request), its simply matched against any of those triggers.
<sadmac> if it matches one, that callback is run, and then the trigger is removed (unless "recurring" is set, in which case it stays to be fired again)
<sadmac> once the event has been run through this table, its discarded. That's the big change.
<Keybuk> so queuing up commands and events in the same way basically?
<sadmac> Keybuk: the queueing is the same. the difference is theres no "pending"
<sadmac> Keybuk: An event is handled immediately and dropped
<sadmac> Keybuk: part of that handling though can be to set up another trigger
<Keybuk> hmm, I used the event queue deliberately though
<Keybuk> of course, the reason I did that may be invalid now
<Keybuk> but the idea was to prevent Upstart from being in the situation where it'd would endlessly follow state changes without returning through the main loop
<Keybuk> otherwise if job's A and B flip-flopped, it could just loop happily though them forever generating events
<sadmac> Keybuk: oh I see what you're missing
<sadmac> Keybuk: the event is "handled" immediately, but it may be incomplete when we're done with it
<sadmac> Keybuk: its sort of "stateless"
<mbiebl> Keybuk: I also filter the messages into a separate folder
<mbiebl> so I don't mind much receiving the messages
<mbiebl> Some of them are actually interesting ;-)
<sadmac> Keybuk: its like this, lets say we get a "start foo" event request. This fires the appropriate recurring trigger which starts foo. That does the forking and the execing, and then it sets up another trigger that says "on started foo do (send method reply, cleanup dbus connection)"
<Keybuk> I'm not sure I quite follow, but it sounds reasonable
<Keybuk> I was never happy with the blocking stuff
<sadmac> Keybuk: a question: why did you make the event queue a pointer to a list and then allocate it with a constructor. Couldn't you have just allocated a static list head? Or was it because you wanted it to hold references to other things?
<Keybuk> just general style
* Keybuk changed the topic of #upstart to: Upstart 0.6.1 "Born in the wagon of a travelling show" | http://upstart.ubuntu.com/
<sadmac> This release does not have a changelog
<sadmac> ^^uncharacteristic of you, Keybuk 
<sadmac> though it looks to be few changes
<Keybuk> "does not have a changelog" ?
<Keybuk> oh, on LP - it keeps throwing them away
 * Keybuk pastes *AGAIN*
<Keybuk> hmm 0.6.0 went missing too
<Keybuk> and 0.5.3 got swapped
<Keybuk> I bet they've broken some LP schema here
<sadmac> Keybuk: remember when I was giving Canonical crap about not open sourcing this thing? I take it back. Keep it plz.
<Keybuk> lol
<Keybuk> has it been opened yet?
<sadmac> Keybuk: I think bits of it have been creeping out. I haven't heard anyone make noise about it in awhile.
<sadmac> Keybuk: you have more patches in this dbus release than any other dev. Do you actually work on dbus or is it really all to make Upstart work?
<Keybuk> just bugs and issues I'm finding when doing Upstart
<Keybuk> I have upstream commit rights to D-Bus though
<sadmac> Keybuk: kinda sad that merely attempting to use the software yielded this many issues, after its been out that long.
<sadmac> 2-space tabs are also kinda sad, but we'll save that for another day
<Keybuk> sadmac: Upstart uses it in a slightly different way to other programs
<Keybuk> I was probably the first person to test D-Bus *without* wanting it to exit() on disconnect from the daemon ;P
<Keybuk> so I find a few bugs in that code
<Keybuk> the test suite is pretty rigorous about forcing things to clean up, so I found a few places where libdbus didn't actually get cleaned up on dbus_shutdown()
<Keybuk> and the malloc testing is pretty brutal too - most people abort() if malloc returns NULL :p
<Keybuk> the other major stuff is the timeout code
<sadmac> yeah. more an RFE
<sadmac> Keybuk: so, about that kernelspace dbus thing :)
<Keybuk> sadmac: are you running 0.6.x now?
<Keybuk> if so, compare
<sadmac> Keybuk: no. I actually just got my home box up to F11 (had some storage juggling I wanted to do) and then I have to port the job defs
<Keybuk> oh
<Keybuk> I'll paste then
<Keybuk> quest scott% sudo time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done'
<Keybuk> 0.61user 0.17system 0:01.32elapsed 59%CPU (0avgtext+0avgdata 0maxresident)k
<Keybuk> 0inputs+0outputs (0major+39960minor)pagefaults 0swaps
<Keybuk> quest scott% time sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done'     
<Keybuk> sh -c 'for i in $(seq 0 100); do initctl list >/dev/null; done'  1.68s user 0.28s system 14% cpu 13.419 total
<Keybuk> -- 
<Keybuk> both running 100 initctl list commands
<Keybuk> first is as root, so is directly between init and initctl - takes 1.32s
<Keybuk> second is as a normal user, so goes via the bus daemon - takes 13.419s!
<Keybuk> bear in mind that both are using the D-Bus protocol and libdbus
<Keybuk> the bus daemon overhead is huge
<sadmac> Keybuk: that's...noticeable. problematic even
<Keybuk> yeah
<Keybuk> I'd be very supportive of AF_DBUS ;)
<sadmac> Keybuk: tell bill to make me a developer again and I'll do it.
 * sadmac had this funny idea that graduating would give him the time to do things
<Keybuk> yeah, I've heard that from students before
<Keybuk> "when I graduate, I won't be so busy"
<sadmac> I need to be more of an asshole so people will stop socializing with me. Then I'll get code written
<sadmac> stop going outside. That's how software gets done
<Keybuk> yeah
<Keybuk> but that's not the worst thing to happen to a software developer
<ion> Iâm not in ~upstart-devel (and i wouldnât belong there anyway, since i donât manage to contribute much with this health), but now that it was mentioned, i subscribed to the bug mail anyway. :-P
<Keybuk> ion: I can add you if you like - contributing to bug triage is more than welcome
<Keybuk> the team's there to let people set bug importances and the like
<ion> Yeah, sure
<sadmac> ion: I didn't know you had health problems. Are you ok?
<ion> Nothing acute. The current diagnosis is F48.0 http://apps.who.int/classifications/apps/icd/icd10online/?gf40.htm+f480
<sadmac> ion: sorry to hear that
<ion> Thanks
<sadmac> plautrba: did you push those 0.3.11 packages when you built them?
<Md> mbiebl: how is "upstart in debian" progressing?
<mbiebl> Md: made the dbus 1.2.16 upload yesterday
<mbiebl> (which spectacularly failed because of the debhelper fuckup)
<mbiebl> that's now fixed
<mbiebl> I expect 0.6.1 to hit unstable in the next couple of days.
<mbiebl> Md: we had some good discussions on the boot performance sprint in london
<mbiebl> pere had some concerns, but it's not completely unrealistic that we might switch to upstart even for squeeze
<ion> * Bump dpkg dependency to 1.2.16
<ion> keybuk: You mean dbus? :-)
<Keybuk> err, probably
#upstart 2009-07-17
<plautrba> sadmac: only devel branch
<ion> http://isc.sans.org/diary.html?storyid=6820
<ion> Is there a typo in the code quotation, though? Should it be if (!sk)?
<wasabi> I don't get that.
<wasabi> Isn't removing the if a semantic change?
<wasabi> oh i see!
<wasabi> it's !tun, not !sk
<Keybuk> it looks like a bug anyway doesn't it
<wasabi> yeah
<Keybuk> if the code was
<Keybuk> sk = tun->sk;
<Keybuk> if (! tun)
<Keybuk> it'd crash
<Keybuk> the fact the sk = is in the initialiser should make no differences
<wasabi> Yeah. The check needed to be before tun->sk
<wasabi> I guess I don't really understand the problem.
<Keybuk> no, I think the blog poster doesn't understand
<wasabi> The post is missing a lot of context maybe.
#upstart 2009-07-18
<ion> I uploaded a video. http://www.youtube.com/watch?v=RQ3CqJ4jM90&fmt=18
#upstart 2010-07-21
<jefimenko> is there more documentation anywhere on instances?
<andoo> hi
<andoo> is there a proper way to deactivate jobs from being started by upstart?
<andoo> and a second question: is there any event that signals the network settings being up and running?
<Wampyre> Hello!
<Wampyre> Does the location of the emits keyword in my conf file make any difference?
<mbiebl> Wampyre: no.
<mbiebl> it doesn't really have any effect either
<mbiebl> it's purely for documentation purposes
<Wampyre> No?  I thought that's how you triggered something else to start when the service starts.
<Wampyre> If it's not for that, then what is?
<ion> It automatically emits âstarting jobnameâ and âstarted jobnameâ
<ion> initctl emit for custom events.
<Wampyre> Got that :)  Now my service starts like it should!
<Wampyre> Woo Hoo!
#upstart 2010-07-22
<Keybuk> hurrah, finally got my Debconf hotel sorted
<mbiebl> Keybuk: hey, long time no see
<Keybuk> hey
<ion> o hai
<Keybuk> :)
#upstart 2010-07-23
<wfamy> is there a method to launch a script with upstart and have it all done before prompt or any-dm?
<JanC> wfamy: you can make "any-dm" and the prompt wait for an event that you raise only after the script is done
<wfamy> ok but i have to emit a signel in my upstart script and patch the initial gdm kdm to start on script-signal. I do not found this very clean.
<wfamy> Before Sys V I just have to tell s19 for my script and S20 for the xdm
<wfamy> I was easy to install in a simple post nstall debian script in the package. Now I am very confused.
<JanC> upstart is still pretty new, I guess in the future it will become easier to do such things
<ion> bar.conf: âstart on starting fooâ â bar blocks the startup of foo, until bar is running (service) or done (task).
<wfamy> sure but is there any doc url explain how to do it? I am not able to migrate my customer's server from lenny debian to lucid because of that. 
<JanC> wfamy: syntax is in the section 5 manpage
<wfamy> I only found events doc http://linux.die.net/man/5/events but i do not found any help
<wfamy> man 5 init same thing
<wfamy> the simple test scrip use a yesno dialog box  and it apear when shutdown the computer
<ion> The man page you linked is for an old version of Upstart
<wfamy> a end before EVENT [[KEY=]VALUE]... [and|or...] could be a nice feature.
<JanC> you can do that now, just requires some editing of upstart .conf files -- IIRC the next version of upstart will make some things easier though
<JanC> maybe some way to add conditions from a different file might be useful...
<wfamy> my .deb script have to edit /etc/init/after-script.conf and it is for my opignon a little dirty. If I modify gdm.conf i have to modify when remove my-script.deb
<wfamy> 2 days ago my server stop booting because of a drbd not launch before the postgres or other thing but i don't know
<wfamy> Ok thx for help I go to bed. see you i'll try to found a solution.
<ion> Whatâs after-script.conf?
<wfamy> here it could be gdm.conf  
<ion> my-script.conf: start on starting gdm
<wfamy> I try it but it does not work because of dialog ?
#upstart 2011-07-19
<praveen_pk> When I try to start /sbin/init in a chroot of RHEL6, it complains about not being able to connect to /com/ubuntu/Upstart, Does init need d-Bus at Startup?
<csgeek> is there a user's mailing list to subscribe to?  for asking questions.. I saw a devel list.. but I presume that's for new features being added to upstart itself. 
<wraiden> what is your question?
<csgeek> well.. I have an upstart script that starts up fine, but it fails to terminate properly 
<csgeek> one sec.. I'll do a pastie 
<csgeek> wraiden:   http://pastie.org/2238507  
<wraiden> mhm
<wraiden> the supervision of the process works?
<wraiden> do you terminate with "initctl stop jobname"?
<csgeek> I used sudo stop jobname 
<wraiden> thats a shortcut...
<wraiden> ok
<wraiden> "initctrl status jobname" lists the right pid ?
<wraiden> it has to be the right pid as it is the pid of the process that gets a sigterm to be stopped
<csgeek> hmm.. the PID it captures seems off 
<wraiden> there is your problem
<wraiden> you have two exec in your main process...
<wraiden> the "expect fork" follows only the first
<wraiden> you can try "expect daemon"
<wraiden> mhm
<csgeek> okay.. does that the job still need to be backgrounded?  ie.  scriptname &  ?  
<wraiden> i think so
<wraiden> the exec stuff that i talked was rubbish...
<wraiden> the execs use the same process environment so there are no forks
<wraiden> try without expect fork
<csgeek> okay.. one sec.. rebooting to reset state  and all that (glad i'm doing this on a vm ) 
<csgeek> okay.. seems to work now
<csgeek> ended up removing fork/daemon statements
<csgeek> and i'm not backgrounding the job 
<danolj> question regarding redis upstart script for ubuntu, more about redis than the upstart script
<danolj> here is the proposed upstart script http://pastebin.com/n1nHhnF6
<danolj> actually, this is an upstart question, sorry
<danolj> the line 'pid file $PID_FILE' 
<danolj> as I've read in the docs indicates to upstart
<danolj> that it should monitor this process by the pid file, correct?
<wraiden> what version of upstart?
<danolj> 0.6.5-8
<wraiden> man 5 init states "pid file" ?
<csgeek> I'm on 11.04 natty.  so..     0.9.7
<wraiden> i think this was before the supervision was changed to use signals from the kernel to the init process...
<wraiden> i use upstream 1.3
<wraiden> not on ubuntu at all *g*
<wraiden> a quick grep over souces went negative
<wraiden> *sources
<wraiden> there is no pid stanza in 1.3
<danolj> ok, thanks
<danolj> so, perhaps I should simply have redis not daemonize itself so that init/upstart can retain a handle on it, sound good?
<csgeek> okay.. I have one last question.. .. I wanted to set it up so when I call childJob, it knows that its requires parentJob, so if parentJob isn't running it'll start it then, start the childJob?  any wiki/doc page I can look at that talks about the process?  
<wraiden> danolj: that would be the first thing to use if a service provides a "don't fork or daemonize"-option ...
<danolj> redis provides the choice
<wraiden> read the http://upstart.ubuntu.com/cookbook/
<danolj> to confirm, don't daemonize redis if using init/upstart as the supervisory process
<danolj> wraiden: okay, thanks for the pointer!
<danolj> oh, yes, I have been reading that
<danolj> found section 6.8.2 regarding daemonizing, thanks
<wraiden> csgeek: you can hook in on starting and stopping events of the child with the parent but if parent should be running without child by default but could be stopped it could be scripted in pre-start with help of initctl
<csgeek> thanks for all the help wraiden
<wraiden> you're welcome...
<wraiden> a port of the rhel cluster suite init scripts is a hell of an effort...
#upstart 2011-07-20
<robinbowes> Hi guys
<robinbowes> Is there a canonical way to detect if a system is running upstart or inittab?
<robinbowes> I'm updating an rpm to work on CentOS 6 and I want it to also work on CentOS 5.x
<JanC> robinbowes: do you want to know whether upstart is running *now*, or whether it's installed as "init"?
<robinbowes> I want to know whether to cat >> /etc/iniitab or cat > /etc/init/some_service.conf
<JanC> eh
<robinbowes> To install the service
<JanC> I think looking what's installed should be good then
<robinbowes> With SysVinit, it requires adding linwes to /etc/inittab
<robinbowes> Yeah
<robinbowes> What I went with was:
<robinbowes> rpm --queryformat='%%{name}' -qf /sbin/init | grep -q upstart
<robinbowes> if [ $? -eq 0 ]
<robinbowes> ...
<JanC> I suppose that's somewhat like using 'dpkg -S /sbin/init' in Debian/Ubuntu?
<robinbowes> OF course, I'll also need to add support for systems :/
<robinbowes> It means "which package owns the file /sbin/init"
<robinbowes> --queryformat='%{name}' ensures a consistent output format
<robinbowes> The double %% is required since %{...} is expanded in rpm spec files
<JanC> you can try to connect to upstart using dbus and such, but that's probably more trouble than you want...
#upstart 2011-07-21
<edakiri> Does contributing code to Upstart require a copyright assignment?  This would have you believe so: http://0pointer.de/blog/projects/why.html
#upstart 2011-07-22
<twb> Suppose I suspect pppd of being an "expect fork" daemon.  How do I find out if it actually is?  RTFS?
<twb> http://paste.debian.net/123721/
<twb> ...is what I'm seeing.  Also when pppd occasionally exits for no reason (despite being told not to), upstart isn't re-starting it, though upstart *does* restart pppd when it exits during pppd's startup (because the DSL card takes a little while to initialize).
<twentylegend> Hello
#upstart 2011-07-23
<BLZbubba> hello there, i am trying to run centos 6 on a system with no console; but some of the init files say "console output"
<BLZbubba> is there a way to have "console" mean a log file
#upstart 2011-07-24
<danolj> I have an upstart script with 'respawn' enabled, all working except, when a stop is issued, the respawn restarts the process
<danolj> I thought that respawn left the process disabled if the stop was normal
<danolj> quetions? thoughts?
#upstart 2012-07-16
<bradleyayers> any plans to add a "restart delay <seconds>" stanza?
<bradleyayers> i'd love one.
<SpamapS> bradleyayers: you can fake it with script stanzas
<SpamapS> if [ -z "$UPSTART_JOB" ] ; then sleep 1 ; fi
<SpamapS> $UPSTART_JOB will only be set on automatic start
<bradleyayers> what's -z?
<bradleyayers> ah
<SpamapS> -z is a test for empty string
<bradleyayers> what's automatic start?
<bradleyayers> as opposed to what
<SpamapS> actually I'm not 100% sure on restart it won't still be set
<SpamapS> automatic as in, as a result of 'start on'
<bradleyayers> also pre-start failures dont result in respawn
<bradleyayers> which was unexpected to me
<SpamapS> its by design
<SpamapS> pre-start is supposed to be the gatekeeper
<SpamapS> respawn should only happen when a thing expected to work fails
<bradleyayers> yeah that's reasonable
<bradleyayers> i just didn't expect it
<bradleyayers> thanks for responding :D
<bradleyayers> this place is quiet
<SpamapS> at times
<bradleyayers> would a "respawn delay" stanza be welcomed? 
<SpamapS> Well you're the first to ever ask for it
<SpamapS> but I doubt a patch would be rejected
<bradleyayers> there was a post to the mailing list in 2010 about it 
<bradleyayers> http://osdir.com/ml/upstart-devel/2010-08/msg00007.html
<SpamapS> bradleyayers: its probably more desirable that your service get smarter about being stopped/started rapidly
<bradleyayers> hmm
<SpamapS> bradleyayers: I'd suggest pre-stop but I think there's a bug that prevents those from running on restart
<bradleyayers> hmm
#upstart 2012-07-18
<scientes> how do i turn off an upstart job from starting automatically?
<ion> http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting
<thatguydan> Hey I was a question I was hoping someone might know the answer to
<thatguydan> are you able to put multiple exec's in say a pre-start script block?
<jodh> thatguydan: "exec" overlays the running program in the current process with the new program, so no.
<jodh> thatguydan: that's just shell/unix behaviour. What are you trying to do?
<thatguydan> chown a few items in a pre-start script, but it wasn't executing :s
<jodh> thatguydan: just run your chowns without the exec.
<thatguydan> yup, just tried and worked. Not sure why I was adamant on the exec's, new to upstart
<thatguydan> thanks
<jodh> thatguydan: the exec's your talking about are actually shell keywords. Take a look at http://askubuntu.com/questions/162768/starting-java-processes-with-upstart and have a poke around in the Cookbook (http://upstart.ubuntu.com/cookbook/).
<thatguydan> cheers, will do
<jodh> thatguydan: it's worth remembering that Upstart will run all shell code using /bin/sh so it's worth re-reading "man sh" too (see also http://upstart.ubuntu.com/cookbook/#develop-scripts-using-bin-sh and http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly and http://upstart.ubuntu.com/cookbook/#check-a-script-section-for-errors).
<thatguydan> will do
<thatguydan> I have one more quick question, using the task stanza, if I exec a .sh script, it shouldn't restart it on exit 1, but will on exit 0, is that correct?
<thatguydan> We're trying to write some update scripts on hardware, and I was thinking of putting a script in that checks for a flag file to decide whether to update or not
#upstart 2012-07-19
<whitley> hi all.  Does the 'env' stanza support use of environment vars on the RHS?  ala"env PATH=/foo/bin:$PATH"
<SpamapS> whitley: pretty easy to test that out ;)
<whitley> SmapapS: Fair enough. I suppose my point is more that the cookbook doesn't make it clear. It's explicit about "start on" and "stop on" not working, but mum on other stanzas.  Answer is "no", BTW, which is a considerable limitation.
 * SpamapS returns to the window to say "Great! could you maybe submit a patch to the cookbook?" but then realizes he's all alone
#upstart 2012-07-20
<mirth> whats the easiest way to create a 6 digit random number in a transformer step....basically want to do: tmp['PID']['PID.3']['PID.3.1'] = random 6 digit number
<mirth> does mirth allow this? Math.floor(Math.random()*100000+1)
<mirth> hmm...guess it does
#upstart 2013-07-15
<xnox> jodh: nice one. Have a review knit-pick.
<jodh> xnox: ack. thanks - branch updated again ;)
<xnox> jodh: right =) off by not error.
#upstart 2013-07-16
<eydaimon> would "respawn limit 0 5" mean attempting to respawn indefiniately every 5 seconds, or does it simlpy mean it will not try to respawn at all? (COUNT=0) ?
<jodh> xnox: I've now got a fix that works for https://code.launchpad.net/~jamesodhunt/upstart/bug-1199778/+merge/174138. Now just need to sort out the new test. Current plan is to cut down my new json test to say 3 session jobs, pre-process foo.json.in into foo.json (which will expand @CHROOT_PATH@ in the .in file), create an actual @CHROOT_PATH@ directory somewhere, put 3 jobs into that path, then pass @CHROOT_PATH@ to test_state.
<jodh> xnox: to be clear, @CHROOT_PATH@ won't be an actual chroot, it will just be a directory containing @CHROOT_PATH@/etc/init/job[1-3].conf.
<xnox> jodh: i didn't think we need to create @CHROOT_PATH@/etc/init/job[1-3].conf. nor process the json at all.
<jodh> xnox: my new test found a bug in the branch, but only because I had jobs in "@CHROOT_PATH@".
<xnox> jodh: load json file up, in memory, substitue chroot_path to a mktemp generated one (just the name, don't actually create it), and test against that.
<jodh> xnox: can do, but we still need the jobs on disk.
<xnox> jodh: that's not unit-testing any more.
<xnox> jodh: where is your fix? "that works for https://code.launchpad.net/~jamesodhunt/upstart/bug-1199778/+merge/174138"
<jodh> xnox: maybe not, but the point is we *should* test this behaviour since you test failed to detect a problem.
<xnox> or what you are saying to reproduce the bug you need the chroot's conf-sources to be present on disk, that's fine.
<xnox> i thought we agreed to remove re-loading conf-sources whilst de-serialising.
<xnox> thus above test with a full chroot session present, is testing the old behaviour instead of the new one.
<xnox> there shouldn't be any job_classes loaded up at that point, and the goto error, is correct in that place.
<xnox> (for sessions)
<jodh> xnox: my current changes do deserialise conf sources *with* sessions, but do not create conf sources *from* sessions. I'll push it somewhere but if you look at the code, other parts make assumptions and this is the minimal change to avoid major test-code rework.
<xnox> jodh: yeah, please push your code. cause you are asking me if above is a valid test for code I haven't seen yet =)
<jodh> xnox: I'm just trying to explain the context of what I'm proposing here.
<jodh> xnox: one sec...
<jodh> xnox: lp:~jamesodhunt/upstart/bug-1199778-16july2013
<xnox> jodh: the bug is that session_deserialise_all produced too much objects, when deserialised and it's conf-sources are present. So, I think an additional test around session_deserialise needs to be added that (1) create temp chroot path with a single job (2) creates chroot session for that path (3) tests that there are no job classes (4) serialise, clean environment, deserialise (5) check that there are still no job clases.
<xnox> this small unit test, should fail, until "- session_create_conf_source (session, TRUE);" patch is applied.
<xnox> similarly, later, we can test other _all functions, that they don't polute and create _other_ object types on deserialisation (unless expected to).
<xnox> the above test is valid, with or without full chroot-session deserialisation support.
<jodh> xnox: sounds good. I'll add that once I've finished test_session_upgrade2()...
<xnox> jodh: above test, is instead of test_session_upgrade2.
<xnox> jodh: cause you are trying to test wrong behaviour of session_deserialise_all, by testing the function state_from_string, which is too high up.
<xnox> and also not abvious.
<xnox> syntaticly i don't see test_session_upgrade2 any different from test_session_upgrade - it was added to unit-test that: state_from_string returns 0, with json which has sessions in it.
<jodh> xnox: well, ideally we'd have both as the high-level test is as close as we can realistically get to a full ser/deser test in the unit tests.
<xnox> (which is valid upgrade scenario we want to catch)
<xnox> but state_from_string testing is incomplete.
<jodh> xnox: the only real difference is that the *2 test will run in an environment which has a "valid chroot" in it - that's what found the bug in the first place.
<xnox> if we had mocking available. I'd be moking out all but one *_all function used inside state_from_string and verify the environment / changes to objects after each one.
<xnox> and then adding all of their combinations.
<xnox> jodh: define "valid" =) it's conf_source path actually existed and had job files in it. And the bug is not in state_from_string, but in the session_deserialise_all.
<jodh> xnox: I know that :) I totally agree we should test the session deser itself, but the high-level test is also valid I think, particularly to allow for when we actually support full deser of chroots.
<xnox> if each time we find a bug in one of subrutines called by deserialise_*_all, we add a unit test against state_from_string, we are making it harder and harder for ourself to later introduce chroot session deserialisation.
<jodh> xnox: imagine we refactored the code tomorrow and inadvertantly change the conffile/confsource handling. by having both tests, we're covered.
<xnox> ok.
<xnox> jodh: do we have to use pre-created json file though?
<xnox> jodh: you do nih_file_read, so can do a substituion right there for the temp-path.
<jodh> xnox: that's what I'm doing atm :)
<xnox> one session, one conf_source, one job_class - roundtrip should return one session with one conf_source without job_class (and thus no jobs / events / etc), even when that conf_source is on disk.
#upstart 2013-07-18
<jodh> xnox: could you take a look at the MPs for lp:~jamesodhunt/upstart/bug-1199778 and lp:~jamesodhunt/upstart/python-upstart-module when you get a chance?
<xnox> jodh: i am testing the first one at the moment.
<jodh> xnox: thanks!
<xnox> jodh: will look into the second one, in a bit.
<xnox> jodh: python module needs work =) but just a couple tweaks.
<jodh> xnox: ok - thanks for reviewing!
#upstart 2013-07-19
<tkd> hi, quick question - is there a way to have an upstart job load env vars from a file other than changing the exec to script and actually loading them there?
<jodh> tkd: for system jobs, not really, but you can do magic with session jobs using 'initctl set-env': http://upstart.ubuntu.com/cookbook/#initctl-set-env
<tkd> jodh: oh well. will have to change to script then.
<jodh> tkd: you can set variables using the 'env' stanza of course, but not wholesale from a file.
<tkd> yeah - this is for a managed deploy where i want to have a static upsart .conf and a separate /etc file with the actual settings
<tkd> i was hoping i could do something like the systemd EnvironmentFile
<jodh> tkd: actually, there is a way to do what you want then: create your static foo.conf
<jodh> tkd: then create foo.override containing multiple 'env $name=$value' lines.
<tkd> jodh: oh, that sounds pretty good. will check it out
<jodh> tkd: It's now in the cookbook: http://upstart.ubuntu.com/cookbook/#separating-variables-from-the-job
<allaire> Hi, can somebody explain me why these two are differents: https://gist.github.com/allaire/ab0e4900da999983ff21  the second one, with no `exec` command returns the wrong pid, always the pid just before the correct one
<allaire> Also, is the way I handle the pid in a file correct? I was curious how it was possible to know the pid ($$) before actually running the exec command
<jodh> allaire: please read http://upstart.ubuntu.com/cookbook/#expect
<allaire> jodh: In my case I have both a script and an exec, I guess it takes the last one it encounter? Thanks for the link by the way
<jodh> allaire: the correct one is probably the one with the 'exec'. Note that *that* exec is a shell keyword, not the upstart exec stanza :)
<allaire> jodh: Yes that the correct one (the one with the exec). I thought it was the upstart exec, now I'm lost :(
<jodh> allaire: when upstart sees a "script ... end-script" block, it runs it via /bin/sh. exec is a shell builting (see man sh / help exec).
<allaire> from the man page, it's the same as running "./myscript", but how come I get a different pid depending of if I use it or not?
<jodh> allaire: no, it isn't - exec *replaces* the current shell process with the command you run.
<jodh> allaire: try logging in on a console and running "false". this just returns 1. Now try running "exec false" and see how it logs you out?
<allaire> yea
<allaire> I seee
<allaire> so even if I have the "$$" var before the exec, it takes oveer the current shell process and that's why it has the right pid?
<allaire> because $$ don't return the same thing if I have exec and if I don't
#upstart 2014-07-14
<ssarah> hei guys
<ssarah> i want to ask, i wana use upstart instead of node forever. How can i make it that upstart only tries to restart a process a number of times before calling for support?
<ssarah> anyone? =O
<slangasek> ssarah: what do you mean by "calling for support"?
<slangasek> you can use the "respawn limit" command to control how many times upstart will retry a failing process; but I'm not sure if that's what you're asking for
<ssarah> slangasek: i mean, that after failing for several times, it does a custom command
<ssarah> get it? :)
<slangasek> ok
<slangasek> upstart is certainly flexible enough that this should be possible, but I can't point to a ready-made example of someone doing this before
<slangasek> in fact I think you probably would need to keep a counter, outside of upstart itself, unless the failures are immediate and could be done through 'respawn limit'
<xnox> ssarah: i'd recommend use existing monitoring to monitor that service is up, when upstart gives up restarting it the status will change to "stop/waiting" and your monitoring system (nagios, check-mk, etc) can take appropriate action for automated recovery and/or further escalation.
<xnox> ssarah: at least, in my previous sys-admin days that's what we did. Since nagios already does smart escalation notification and has appropriate means to encode shifts and rotas.
<ssarah> xnox: what status changes to "stop/waiting"
<ssarah> ?
<xnox> ssarah: of your job. If you start it, it becomes "$ status your-job" will say start/running. And would stay like that, and respawned as needed.
<xnox> ssarah: when it fails permamently, it will change status to "$ status your-job" will become "stop/waiting", and thus your nagios monitoring can be checking that.
<ssarah> im sorry if this sounds too basic but that variable is something i can see where?
<xnox> ssarah: type on the command line: $ sudo status tty2
<xnox> ssarah: $ sudo stop tty2
<xnox> ssarah: $ sudo status tty2
<xnox> ssarah: $ sudo start tty2
<xnox> ssarah: $ sudo status tty2
<xnox> ssarah: $ cat /etc/init/tty2.conf
<xnox> ssarah: for more about jobs, their states, what states they transition through and how to control/inspect/observe that see http://upstart.ubuntu.com/cookbook/
<xnox> ssarah: for more control you can add your custom jobs, or e.g. monitor signals, events and notifications on the DBUS interface
#upstart 2014-07-16
<buzuli> I read that Ubuntu is planning to switch to systemd. And this the day after I first tried upstart. 
<buzuli> Rather disappointed. I love the simplicity of upstart.
<buzuli> What are the plans moving forward?
<xnox> buzuli: for the next 5 years it's still being used as the default.
<xnox> =)
<xnox> the migration plan is not worked out yet.
<xnox> buzuli: and e.g. all chromebooks use upstart and plan to still do so.
<buzuli> That is good to hear.
<buzuli> Is there any need for contributors to the project?
<xnox> buzuli: well there are a few bugs open here and there both in upstart itself and libnih (a generic library with many useful functionality)
<xnox> buzuli: in general it's rather quite feature complete by now. Browse through open bugs on launchpad and read the source tree and check if you want to contribute / code.
<xnox> buzuli: checkout http://people.canonical.com/~jhunt/presentations/uds-r/2012-10-31/upstart-development.pdf and the upstart cookbook.
<buzuli> Thanks for the link and the update.
<buzuli> I'll take a look over the PDF
<buzuli> Is there a git mirror of libnih and/or upstart?
<buzuli> Would make at easier to get started looking over the code, especially on my tablet.
* jodh changed the topic of #upstart to: Upstart 1.13.1 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
#upstart 2014-07-17
<sean_abbott> I cannot for the life of me figure out how to register a new service with upstart
<sean_abbott> anyone?
<sean_abbott> I've tried initctl reload-configuration
<sean_abbott> but I get no results
<sean_abbott> initctl check-config doesn't work because, apparently headless.
<ion> sean_abbott: It should see the new file automatically. If there are errors, you should see them in syslog.
#upstart 2014-07-18
<elithrar> Looking at the Upstart cookbook (updated 2014-07-17) can I assume that user jobs aren't able to log to /var/log/upstart/* (i.e. I'd need to manage my own logging solution)?
<xnox> elithrar: system jobs log to /var/log/upstart/*, user-session jobs log to $XDG_CACHE_HOME/upstart/ -> which typically is $HOME/.cache/upstart/
<xnox> elithrar: so default behaviour is the same for both: stdout & stderr is collected & rotated into logs somewhere.
<elithrar> xnox: Alright, thanks. Having issues when using `set uid $USER` and `set gid $USER` where the job fails to start. No useful logging information from Upstart.
<xnox> elithrar: oh, well neither of those stanzas are correct -> job not recognised -> job not run =)
<xnox> elithrar: "setuid" and "setgid" are correct stanzas -> note no space.
<elithrar> Whoops, I typo'ed them in IRC. Not in the config.
<xnox> elithrar: and that's a system level job, so log would be in /var/log/upstart/*
<xnox> elithrar: can you run $ init-checkconf /etc/init/that-job.conf ?
<elithrar> "failed to ask Upstart" (although it still writes it to /tmp/user/$UID/init-checkconf...
<elithrar> I asked all of this as the Upstart docs indicate "User jobs cannot currently take advantage of job logging. If a user job does specify console log, it is considered to have specified console none. Logging of user jobs is planned for the next release of Upstart."
<xnox> elithrar: ..... user jobs != user-session jobs != system job with setuid specified
<elithrar> Upstart 1.5 here, so only user jobs.
<xnox> elithrar: we used to have (now deprecated) user jobs, where jobs are read from $HOME/.init/ and are run under the user jobs.
<elithrar> (running 12.04 - I should have clarified. Only just noticed that 1.7 brought session jobs)
<xnox> elithrar: well, read $ man 5 init, I don't think 1.5 had "console log" at all)
 * xnox checks.
<elithrar> It does, but only for system jobs - so you're right / my first comment was on the mark
<elithrar> logged "Only applies to system jobs: if specified by user jobs, the job will be considered to have specified the value none."
<elithrar> *log
<xnox> elithrar: yeap =(
<elithrar> Welp, I'm rebuilding this box as a 14.04 LTS machine so I'll use session jobs and test in Vagrant. Thanks for helping diagnose thoughâmore incentive to upgrade.
<xnox> elithrar: you should be able to use something like "log-output" or something like that. Or otherwise redirect stdout/stderr to a file you can write to as that user.
<xnox> elithrar: ha, log-output is ubiquity internal -> so no, can't use it.
<elithrar> Yeah, I was trying to avoid that since I then need to write a logrotate config. Which isn't a challenge, but it's just less incentive to migrate from supervisord. I prefer to use the "included tools" but older versions of Upstart are a bit limiting
<six86> Hello. I have a problem with upstart. I want to start a software when two can interfaces are available. But "start on (net-device-up IFACE=can0 and net-device-up IFACE=can1)
<six86> " does not work. Am I doing something wrong here?!
<six86> anyone?
<sean_abbott> So as I understand it, just putting the conf file in /etc/init should let upstart know about the job
<sean_abbott> So, then, I guess if it still claims to NOT know about my job, there's a problem with it.
<sean_abbott> is that correct?
<sean_abbott> here's what I dn't understand.  Your debug guide says if you get unknown job you have a configuration issue.
<sean_abbott> use init-checkconf
<sean_abbott> but init-checkconf doesn't work on servers
<sean_abbott> and ya'll don't respond at all.
<sean_abbott> ok, was finally able to run init-checkconf from my desktop and that got me there
<sean_abbott> \quit
#upstart 2015-07-14
<stemid> hi I have an old binary service that I tried to convert from sysvinit to upstart. the sysvinit script was extremely basic, just running /path/binary & so I tried exec /path/binary in upstart but ended up with many copies of that process. 
<stemid> what could be wrong?
<stemid> I solved it with expect fork
#upstart 2015-07-15
<awdavies> Hello everyone!  I have some silly questions about upstart if anyone would be willing to help :)
#upstart 2015-07-19
<yoavz> Hi, I'm having some weird issue with upstart and 14.04. init-checkconf gives me "unexpected token" for line 11 in this upstart script: https://gist.github.com/yoavzuri/0401873b0400ccf1c003 - Any ideas?
#upstart 2016-07-19
<gahan> anyone has experience of removing systemd in xenial in favour of upstart? I'm getting too many issues with systemd
<AnrDaemon> apt-get install upstart-sysv
<gahan> and then reboot?
<gahan> am I likely to encounter some issues?
<AnrDaemon> I didn't try it yet. But this what an official wiki suggest.
<gahan> can you provide me the link please?
<AnrDaemon> Google? It would take as much time for you as for me.
<gahan> I can only find instructions for 15.04 :) sorry 
<AnrDaemon> http://lmgtfy.com/?q=upstart+vs+systemd second or third link - "SystemDForUpstartUsers"
<gahan> I tried apt-get install upstart-sysv but grub2 wasn't updated, still uses init=/lib/systemd/systemd
<gahan> I tried on VM and it doesn't boot
<AnrDaemon> Thanks. That's interesting.
<gahan> it did update grub in the end
<gahan> making upstart default and systemd optional
<AnrDaemon> Did it rebuild initrd or you had to do it manually?
<gahan> I rebuilt it
<gahan> but it didn't help
<gahan> Something to do with the volumes
<gahan> ubuntu-vg wasn't found
<AnrDaemon> Oh, you have it on LVM?
<gahan> yeah
<AnrDaemon> That's different.
<gahan> I'm trying to migrate in openstak though
<gahan> which is different too unfortunately
<AnrDaemon> hah
<gahan> openstack handled it better
<gahan> tried with a test instance
<gahan> still have /lib/systemd/systemd-udevd running though
<Troova> Hi - I'm hoping for a bit of help understanding upstart monitoring
<Troova> I am using upstart 0.6.5 on RHEL 6, and I need to change to a new user to run my application.
<AnrDaemon> You - what? >.<
<AnrDaemon> Troova: `init --version` please.
<Troova> I tried the examples using su -c in the cookbook, but the tracked pid is the pid of the su calls running as root, not my application (running as a different user)
<Troova> Unit (upstart 0.6.5)
<Troova> Init sorry...
<AnrDaemon> That'sâ¦ that was several years ago.
<AnrDaemon> Do you need user environment, or just start an appa with certain EUID?
<AnrDaemon> Webchatsâ¦ :/
<JanC> sounds right that it would be following su pid
<JanC> obviously you don't want your application to fork then...
<AnrDaemon> JanC: He's long gone, you're talking to the void.
<hallyn> AnrDaemon: well gahan is gone but fwiw upstart on xenial is wha ti'm running, like you said, upstart-sysv did it, and if anyone asks again i have no issues :)
<hallyn> except power issues.  my battery lasts too long this way
<hallyn> j/k
<AnrDaemon> I'm going to upgrade "soon(tm)"
<AnrDaemon> (Or, well, reinstall, since I want 64 bit already.)
<hallyn> upgrade to yakkety, or to upstart? :)
<AnrDaemon> Upgrade in general.
<AnrDaemon> This server (the core) is over eight years old, and survived too many hardware replacements.
<AnrDaemon> I want to reinstall it once before it is failing again. :D
<AnrDaemon> (And it is running Precise ATM, if that was your question.)
<hallyn> gotcha
#upstart 2016-07-20
<andythomas> Hey folks. I've been trying to compile upstart for an embedded Linux card (on ARM Cortex A8) and I get a kernel panic on boot: "Assertion failed in control_emit_event_emitted: env != NULL". Any ideas?
<andythomas> More details here: http://stackoverflow.com/questions/38457854/upstart-causes-kernel-panic-on-embedded-linux
<andythomas> Anyone here?
#upstart 2016-07-22
<anth0ny> I'm trying to run my script as a user ("ubuntu", on AWS) but get "unable to find setuid user" in my syslog
<anth0ny> any ideas? i'm definitely running as ubuntu
<anth0ny> moreso, there's definitely a user named ubuntu
<anth0ny> blah, disregard, needed to reload configuration
<AnrDaemon> :D
<SteenJobs> is anyone here?
<AnrDaemon> No. Everyone's there.
<SteenJobs> haha
<SteenJobs> iâve been struggling for almost two days with an upstart issue, ran into the notorious stop/killed bug, etc.
<SteenJobs> and i need to get this working - trying to write an Upstart script for God (the ruby monitoring library, not the Almighty)
<AnrDaemon> pastebin your progress.
<SteenJobs> AnrDaemon: if you have a minute, iâll gist the script
<SteenJobs> ahhhh youâre the best
<SteenJobs> thank you thank you. being the only dev at the company right now is no easy task ):
<SteenJobs> AnrDaemon: https://gist.github.com/jesiegel1/2ba88ccff85001f3be57c2e2debca893 - iâve tried multiple iterations of the gisted file - iâve tried both the approach of using expect fork, and the approach of running god not-daemonized.  with the former, running god status within my project dir doesnât seem to match/recognize the running process from the upstart script, and with the latter, the service stops immediately after starting,
<SteenJobs> error.
<SteenJobs> (also the exec echo bit was st i only tried a second ago, in a desperate attempt, so you can ignore that)
<AnrDaemon> Your problem is that you're doing too much in exec.
<AnrDaemon> 1. Remove respawn, expect.
<AnrDaemon> 2. Write all preparations in pre-start.
<AnrDaemon> Is your script intended to run as root?
<SteenJobs> AnrDaemon: what about placing it inside a script block?
<SteenJobs> and yea - only bec this is the staging server
<SteenJobs> on production itâs not root
<AnrDaemon> Then don't run it as root.
<SteenJobs> this is on staging
<AnrDaemon> Don't use script/end script, if you can avoid it.
<SteenJobs> ah ok
<SteenJobs> cause that didnât work either, also stopped immediately
<AnrDaemon> Doesn't matter. It's much easier to get it working right straight away.
<SteenJobs> running as root bec everything is pretty much run as root on staging
<SteenJobs> including the location of the app
<AnrDaemon> -D - is that "daemonize" ?
<SteenJobs> and the permissions
<SteenJobs> yessir/maam
<AnrDaemon> Remove it.
<SteenJobs> no
<SteenJobs> sorry
<SteenJobs> opposit
<AnrDaemon> Ok-ok.
<SteenJobs> itâs to run in foreground
<AnrDaemon> Then that one is right.
<SteenJobs> and wouldnât removing respawn defeat the purpose of making sure God is always running?
<SteenJobs> end goal being kill -9 god should result in the process being restarted
<AnrDaemon> Removing respawn will prevent it respawning endlessly with bad job config.
<AnrDaemon> Don't add anything like that, until you know you have right syntax and the job generally works.
<AnrDaemon> Hold a moment, I'll have smth for you to try.
<SteenJobs> you are a righteous man my friend
<AnrDaemon> https://gist.github.com/jesiegel1/2ba88ccff85001f3be57c2e2debca893#gistcomment-1832245
<AnrDaemon> Always use absolute paths in init scripts.
<AnrDaemon> Unless you 100% know what you are doing.
<SteenJobs> ah ok cool. good to know. im fairly new to it, although iâve crammed well, bec the dev in charge of production quit
<SteenJobs> gimme a sec, gonna plug it in now
<SteenJobs> i need to cd because of running âbundle exec"
<SteenJobs> although thatâs a lie, i can supply the path for rvm/bundler for it to run
<AnrDaemon> chdir
<AnrDaemon> Seriosuly, check the cookbook.
<SteenJobs> yea, iâll read thru it
<SteenJobs> i saw you added that, which is why i brought it up
<SteenJobs> k trying now
<AnrDaemon> chdir will change directory before invoking every part of script.
<AnrDaemon> pre-start, exec, post-start, pre-stop, stop, post-stopâ¦
<SteenJobs> very cool - only thing iâm not sure what to plug in is the bundle exec part - i use capistrano for deployment, and in my custom task i run /usr/local/rvm/bin/rvm default do bundle exec, so iâm not quite sure what the path is for bundle. trying to figure that out now
<AnrDaemon> And check /var/log/upstart/yourjob.log for any clues if it would not start like that.
<SteenJobs> yep, thatâs what i was doing about 10 minutes ago, finally found it ha
<AnrDaemon> Here I can't help you, sorry. Not familiar with railcraft.
<SteenJobs> haha
<SteenJobs> i think i found it - gonna try now
<SteenJobs> whatâs your jam? do you do web dev?
<AnrDaemon> I'm using PHP for web. But mainly I do IT support and a little devops.
<SteenJobs> nice
<SteenJobs> iâm getting job failed to start - nothing in the logs
<AnrDaemon> That means it either didn't find anything to exec, or there was a very bad initial config.
<SteenJobs> wouldnât it log that though?
<AnrDaemon> Keep in ming, jobs start with nearly empty environemnt, and no HOME/USER defined. If you need them you gotta defien them by hands.
<AnrDaemon> It may, but not into job log. And you'd have to run upstart with higher verbosity, probably.
<AnrDaemon> Sorry, if I'm guessing much, my attempts are normally more successful :) At least, I get something in the log.
<AnrDaemon> If you failing badly to even get your app to start in the job, try this:
<AnrDaemon> exec /bin/sh -c 'set'
<AnrDaemon> Get the environment from the log, and use /usr/bin/env to run your app with a copy of the job's environment.
<SteenJobs> when you added env RAILS_ENV=staging, what does that do exactly?
<SteenJobs> eh i can just check the docs
#upstart 2016-07-23
<AnrDaemon> :F
<AnrDaemon> http://upstart.ubuntu.com/cookbook/#env
<SteenJobs> well there ya go haha
<SteenJobs> AnrDaemon: dude!!!!!
<AnrDaemon> Sure?
<SteenJobs> ok - i finally got running bundle exec god status in the proj dir to == service god status
<SteenJobs> and starting the job works
<SteenJobs> only odd thing, is once again after running service god start, i run service god status and it returns stop/waiting
<AnrDaemon> I hear "but" in your wake.
<SteenJobs> haha
<AnrDaemon> Sounds like it is detaching.
<AnrDaemon> When you initctl stasrt, it tells you the PID it was tracking.
<SteenJobs> yet bundle exec god status still knows that itâs running somehow
<SteenJobs> yep
<AnrDaemon> Check the running bundle, and its pid/ppid.
<AnrDaemon> If it forks regardless of your intent and specification, you may either need to revise your switches, or play with expect.
<SteenJobs> when i started, PID was 22221, but checking ps aux has âroot 22512 /home/root/apps/my_app/shared/bundle/ruby/2.3.0/bin/god
<AnrDaemon> ppid?
<SteenJobs> fixed
<SteenJobs> please donât kill me
<SteenJobs> i forgot the -D
<SteenJobs> :-D
<SteenJobs> i meant that to come out in text form, it wouldâve been an emoji pun
<SteenJobs> ok, adding respawn and letâs see what happens when i kill it
<SteenJobs> this is the line that saved it btw: exec bash -l -c '/usr/local/rvm/bin/rvm default do bundle exec god -D -c config/app.god -l log/god.log'
<AnrDaemon> That's wrong line.
<SteenJobs> holy crap it all works
<AnrDaemon> Remove bash, start it directly.
<SteenJobs> but iâm listening
<AnrDaemon> Else it will be tracking bash PID, not your service PID.
<SteenJobs> AnrDaemon: look at the bottom of this - http://www.grant-olson.net/news/2014/03/20/upstart_config_for_god.html - i wasnât sure exactly why they use that, but i figured iâd give it a shot. iâll remove it and see what happens.
<SteenJobs> although i ran kill -9 PID after adding respawn, checked status, and itâs running
<AnrDaemon> They are deeply mistaken, that's all.
<AnrDaemon> If it needs $HOME, then define env HOME=/...
<SteenJobs> right
<SteenJobs> learned that already :)
<SteenJobs> but i meant at the bottom, they explain the bash line
<AnrDaemon> bash -l makes it act as login shell, settign environment and all that stuff.
<AnrDaemon> Suffice to say, I've managed to start VirtualBox via upstart :P
<SteenJobs> haha word
<SteenJobs> yea, but rvm requires that kind of enivornment loading
<SteenJobs> i removed bash -l -c
<SteenJobs> and it broke things
<SteenJobs> it now shuts down immediately again
<AnrDaemon> If it actually reuires that, whoever wrote it must be lashed and chained to the table until it fix the thing right.
<SteenJobs> i lied
<SteenJobs> itâs because i didnât remove the quotes
<SteenJobs> smh
<SteenJobs> weâre in business
<SteenJobs> you are a champ, truly
<SteenJobs> AnrDaemon: aright, iâm really really late for my dinner so i gotta run, but honestly thank you so much. you canât even begin to understand how much i appreciate the help.
<SteenJobs> hey room that saved my butt yesterday - when setting setuid/setgid to deploy on my production server, when starting my service, my Rails config files throw a ânon-absolute homeâ errorâ¦any idea why?
<AnrDaemon> Did you set HOME to an absolute path in your job config?
<SteenJobs> haha hey :)
<SteenJobs> nope - ran echo $HOME and it gives me /home/deploy
<SteenJobs> so itâs not even set within the God config file
<SteenJobs> meaning i donât set it there, since itâs already set
<SteenJobs> (tried adding HOME anyway, as /home/deploy, and it didnât work eitherâ¦only thing that worked was removing setgid/setuid)
<AnrDaemon> I mean, did you set "env HOME=/whatver/something" in the init script?
<SteenJobs> AnrDaemon: ahh, no, i was setting RAILS_ROOT which i thought was missing, but that sounds like what was missing - will give it a go
<AnrDaemon> If these idiots run "bash -l" to start their service, then the most likely missing bit is user environmant, particularly $HOME.
<SteenJobs> hahah
<SteenJobs> tis why despite using resources i find online, IRC is always my last step, both to learn things that i couldnât find, and to verify those things i did find
<SteenJobs> IRC is basically how i learned how to legitimately code
<AnrDaemon> Legi... wat.
