#upstart 2007-07-04
<bicchi> since upstart replaced /etc/inittab. how can i set the runlevel at startup?
<shawarma> Stupid question alert: What is the canonical way to manage a daemon that insists on detaching itself from the console?
<Keybuk> there isn't one just yet
<Keybuk> officially you place "daemon" in the job definition
<Keybuk> that will cause upstart to not automatically leave the spawned state
<shawarma> Ah.
<Keybuk> waiting for some as-yet-unimplemented something to obtain the pid of the process to supervise
<shawarma> It might interest you to know that apache2 is one such daemon.
<Keybuk> indeed
#upstart 2009-06-29
<iamthelostboy> hi.. i have serveral upstart jobs which run in turn on startup.. one of them is pretty basic, consisting mainly of a single exec <command> in script tags
<iamthelostboy> when it is first started by upstart, the program it runs is left running, and the upstart script goes into a waiting mode, when it should be running...
<iamthelostboy> when i then exit the application, upstart doesn't continue to do the various things it should
<iamthelostboy> if i start the job manually, it all seems to work
<iamthelostboy> any ideas what I am doing wrong?
<Keybuk> iamthelostboy: it's likely that the process actually doesn't stay running
<Keybuk> and instead turns itself into a daemon
<Keybuk> do you have the output of the "start" command for that job?
<Keybuk> I wish the test suite wouldn't take 35 minutes to complete when run under valgrind
<Moncader> I have a bit of a question for jobs. The event system makes sense for starting a job, but what about stopping? Do we have to make two jobs per 'application' (Start and Stop of the init scripts)
<sadmac2> Moncader: um... could you try to rephrase that?
<Keybuk> Moncader: Upstart jobs are written in a declarative form, not an imperative form
<Keybuk> ie. instead of describing how to start and stop the service, you instead describe what the service *is*
<Keybuk> the ability to stop that service is inherently built in to Upstart
<Keybuk> (send SIGTERM, wait, then SIGKILL)
<Moncader> Hmm, this is true for running exec stanzas or scripts that run a single application.
<Moncader> However, what about the case of say, an initial system startup script, and then the equivalent shutdown?
<sadmac2> Moncader: usually the wrong way to do it. However pre-start/post-stop etc are the way to do that
<Keybuk> Moncader: can you give an example
<Keybuk> do you mean like having a job to mean "mount/unmount filesystems" - where on the way up it mounts them, and on the way down it unmounts them?
<Moncader> Well. Currently, I'm building yet another Linux from Scratch system. This time I thought I'd use a different init system. So I'm going for a 100% upstart system, trying to get rid of the whole rc.d structure.
<Moncader> To do that, there were a couple scripts (rcsysinit, rc.local) that do things only on startup.
<Keybuk> sure, but bear in mind that Upstart isn't just a "better sysvinit" - it's quite different
<Keybuk> the "only do things on startup" case are interesting
<Keybuk> the best way to do those are as tasks
<Keybuk> e.g.
<Keybuk>   task
<Keybuk>   script
<Keybuk>     ....
<Keybuk>   end script
<Keybuk> starting a task will block until it is finished, not until it is running
<Keybuk> so "start rc.local" won't return until rc.local is done
<Moncader> mm. Guess so. Just that upstart is supposed to be a full replacement for sysinitv, so I was wondering what to do in that case.
<Moncader> Alright
<Keybuk> or if you had "start on starting foo" in rc.local, foo would not be started until rc.local was *finished*
<Keybuk> it's a full replacement for sysvinit, not sysv-rc
<Keybuk> many people confuse the two
<Moncader> Ah, I see
<Keybuk> Upstart can run the sysv-rc script (usually /etc/init.d/rc) just as well as sysvinit can
<Keybuk> but it doesn't deal with /etc/rc2.d and stuff, you run the sysv-rc script from Upstart to do that
<Moncader> Yes, which is of course what most distros are doing now.
<Keybuk> another common pattern in Upstart is that the job implies a state
<Keybuk> for example, "mountfs" could be always "running" when the filesystems are mounted
<Keybuk> start mountfs would mount the filesystems
<Keybuk> and stop mountfs would *unmount* them
<Keybuk> the way to do that in Upstart is using pre-start and post-stop without a primary exec/script
<Keybuk> e.g.
<Keybuk>   pre-start exec mount -a
<Keybuk>   post-stop exec umount -a
<Keybuk> that's valid, even though there's no "exec"/"script" on its own
<Moncader> Heh, interesting way to do it.
<Keybuk> Upstart will claim it's running with no process
<Keybuk>   "start on starting mountfs" is still valid - will be run before mount
<Keybuk>   "start on started mountfs" is still valid - will be run after mount (thus when the filesystems are up)
<Keybuk>   "start on stopping mountfs" is still valid - will be run before umount
<Keybuk>   "start on stopped mountfs" is still valid - will be run after umount (thus when the filesystems are gone)
<Moncader> I see. Thank you.
<Keybuk> you might realise that it's trivial to wrap initscripts like this ;)
<Keybuk>   pre-start exec /etc/init.d/foo start
<Keybuk>   post-stop exec /etc/init.d/foo stop
<Moncader> Yes :) But for fun I'm trying to get rid of init scripts :)
<Keybuk> Upstart won't know the pid and suchlike while it's running, of course, but it's "close enough" for most people
<Keybuk> - and I have a solution for that too :p
<Moncader> Heh, of course :)
<Keybuk> my life is made so much easier by tests/expected :)
<Keybuk> TEST_EXPECTED_STR (str, "foo.c");
<Keybuk> compares the contents of str against the contents of tests/expected/foo.c
<Keybuk> and also TEST_EXPECTED_FILE (fp, "foo.c");
<ion> Neat
<mbiebl> Keybuk: just some small nit
<mbiebl> the copyright assignment pdf linked on http://upstart.ubuntu.com/wiki/CopyrightAssignment
<mbiebl> has a wrong url in the pdf document
<mbiebl> Clicking on 
<mbiebl> http://
<mbiebl> canonical.com/contributors
<mbiebl> sends you to http://www.canonical.com/contributor (note the missing 's')
<Keybuk> mbiebl: I'll let Amanda know
<mbiebl> Keybuk: is this copyrigth assignment bound to the email address I use for signing?
<Keybuk> thanks
<Keybuk> mbiebl: I'll tend to use the e-mail address for the ChangeLog
<Keybuk> unless you want me to use a different one
<mbiebl> Keybuk: my launchpad account uses a gmail address, but I don't use that address for signing emails
<Keybuk> the mail doesn't have to be signed AIUI
<Keybuk> GPG signed, that is
<Keybuk> the text itself is a signature under UK law
<mbiebl> Keybuk: I was just wondering if I send a patch using a different email address than the one that was used for signing the copyright assignment
<Keybuk> that's ok ;)
<mbiebl> hm
<mbiebl> how do you know then that the persons behind mbiebl@gmail.com and say biebl@debian.org are actually the same person?
<mbiebl> Maybe I'm just seeing a problem where there is none ;-)
<Keybuk> mbiebl: I can always ask if unsure ;)
<Keybuk> which e-mail address would you like in ChangeLog btw?
<mbiebl> I don't really mind ;-)
<Keybuk> I suspect you're just thinking from a Debian point of view
<Keybuk> where everything has to be signed, and everything has to have a trust path
<Keybuk> and all 'i's must be dotted and all 't's crossed
<Keybuk> Canonical's Contributor Agreement was written by a lawyer
<Keybuk> they see through games like "aha! but I sent it from a different e-mail address" <g>
<mbiebl> :-)
<Keybuk> plus it's not an assignment of copyright per se
<Keybuk> it's a copyright licence
<sadmac2> Keybuk: I've polished up the state transfer patch, but I'm not entirely sure what sort of testing I should do on it. Its really wired in to everything else, it could end up comprising a system test depending on how much fudging we do.
<Keybuk> sadmac2: the code should at least be covered under tests/
<sadmac2> Keybuk: if that's the water mark, then I'll have it done soon.
<sadmac2> Its only 2 functions, so just poking them doesn't take much time
<Keybuk> it's basically so we can prove it works
<Keybuk> and isn't broken by future changes
<mbiebl> Keybuk: is there a reason why upstart is still registered as GPLv3 project on the launchpad page?
<Keybuk> mbiebl: forgot to change it
<Keybuk> fixed
<achivetta> I have a network file system that I boot a large number of server off of, I would like to be able to run a getty on ttyS1 on those servers which have an appropriate device \
<achivetta> however, on some servers, getty complains of a input/output error on ttyS1 and is restarted by upstart after quitting, is there any way to prevent upstart from continuously restarting the getty?
<achivetta> (alternatively, can someone point me to the documentation on the format of the files in /etc/event.d)
<achivetta> ah, found it, http://upstart.ubuntu.com/wiki/Stanzas , thanks anyway
#upstart 2009-06-30
<iamthelostboy> Keybuk: thanks for the help earlier.. the process the upstart job is running is just a standard application.. when the job is started by me logged in as root by emitting the same event which normally starts it, the job stays running with the process id,, if the job is started during normal system startup, the process stays running, though the job goes into the waiting state
<iamthelostboy> i cant quite understand why there is a difference between me manually starting it and been automatically started during system startup
<Keybuk> achivetta: removing "respawn" from the job will prevent Upstart from respawning it
<Keybuk> but that will mean it just fails once, obviously
<Keybuk> probably better to find out why it fails with an I/O error
<Keybuk> could be that you're starting it too early?
<Keybuk> iamthelostboy: not sure on that one without some debugging traces
<Keybuk> iamthelostboy: run "initctl log-priority debug" then capture the messages when you start by hand
<Keybuk> for the boot case, add "--debug" to your kernel command line and watch the console messages
 * Keybuk came up with the release name for 0.6.0 at a very strange hour last night ;)
<johnflux_> Hey everyone
<Keybuk> hey
<johnflux_> Keybuk, is there a gui for starting/stopping services?
<johnflux_> a KDE gui would be nice
<johnflux_> Keybuk, I'm wondering how to do the integration of kde's System Activity (task manager)
<Keybuk> there is no gui
<Keybuk> however the D-Bus interface should make writing one trivial
<Keybuk> I started documenting it here http://upstart.ubuntu.com/wiki/DBusInterface
<Keybuk> obviously this is largely incomplete so far, and doesn't include the new method we discussed
<johnflux_> Keybuk, and presumably the d-bus interface isn't public just yet
<johnflux_> Keybuk, thanks for documenting it
<Keybuk> how do you mean by public?
<johnflux_> Keybuk, sorry I mean that non-root users can't use the dbus interface yet
<johnflux_> Keybuk, the second bug that I filed
<johnflux_> Keybuk, "no well-known name is required."   what does this mean?
<johnflux_> what's a well-known name?
<Keybuk> use the dbus/Upstart.conf file from trunk
<Keybuk> http://bazaar.launchpad.net/~scott/upstart/trunk/revision/1126#dbus/Upstart.conf
<Keybuk> if you don't know what a "well known name" is, I suggest starting from a D-Bus tutorial
<Keybuk> it's a fairly fundamental concept
<johnflux_> Keybuk, would you mind if I added a link from "well known name" to the appropriate dbus tutorial paragraph then?
<johnflux_> I can't be the only one who vaguelly knows what dbus is, but don't know what "well known name" means
<Keybuk> sure
#upstart 2009-07-01
 * Keybuk finally figures out what about D-Bus davidz has been bitching about all this time
<Keybuk> *contemplates versioning the D-Bus interface*
<Keybuk> I wonder whether anyone would mind if I did that, and just kept revving it
<sadmac2> Keybuk: https://bugzilla.redhat.com/show_bug.cgi?id=509113
<sadmac2> Keybuk: I'm about to close that as WONTFIX. Any special message or reason I should keep it open?
<ion> Yeah, versioning the interface would be a good thing.
<Keybuk> sadmac2: we're going to move to .conf, so I guess you could say it's an open bug
<ion> How about .job?
<sadmac2> Keybuk: matter of policy really
<Keybuk> sadmac2: yeah, depends how you deal with upstream bugs ;)
<sadmac2> ion: yeah that's the other thing. .event is wrong wrong and terribly wrong
<Keybuk> ion: confuses jobs and instances and crap
<Keybuk> right, the fact people think things in /etc/event.d are "events" is the whole reason to rename it in the first place
<Keybuk> they're things run "on" events
<ion> :-)
<Keybuk> things in /etc/apm/suspend.d are not suspenders
<sadmac2> Keybuk: unless apm is advanced pants management
<Keybuk> :D
<ion> :-D
<ion> I sincerely donât get the .d naming convention for directories.
<Keybuk> it made sense once
<Keybuk> if you have /etc/foo.conf
<Keybuk> then you'd grow /etc/foo.d/*.conf
<ion> Why not /etc.d/apm.d/suspend.d to make it absolutely clear they are directories, in case someone forgets how stat works.
<Keybuk> yeah, that's where it got silly
<Keybuk> new directories should never have had a ".d"
<ion> Yeah, i get that, but for instance, there never was an /etc/event.conf or equivalent.
<Keybuk> event.d was chosen on the spur of the moment because at least three other things used it ;)
<sadmac2> Keybuk: what other things?
<Keybuk> sadmac2: apm, powerman, d-bus
<Keybuk> /etc/apm/event.d, /etc/power/event.d, /etc/dbus-1/event.d
<Keybuk> ;P
 * sadmac2 gets an old powerman5000 song in his head.
 * Keybuk wonders how he ended up with a 50,000 line C file
<ion> :-D
<Keybuk> ironically this is the code that tests the dbus binding proxy code
<Keybuk> it's twice the size of the file that tests the object end using raw dbus
#upstart 2009-07-02
<Keybuk> wow
<Keybuk> the einit guys totally jumped the shark
<Keybuk> they renamed it to kyuba
<Keybuk> and started implementing their own libc!
<Md> are they djb groupies as well?
<Md> I think there is a significant correlation with people implementing their own libc...
<Keybuk> eglibc!
<Keybuk> oh, wait
<ion> Huh
<sadmac2> Keybuk: eglibc was a fun announcement
<sadmac2> Features:
<sadmac2> - Good for embedded stuff
<sadmac2> - Maintainer doesn't hate you and all your ilk
<sadmac2> - See above
<Keybuk> the first one is debatable
<Keybuk> there is only one diff between the trees
<Keybuk> -Ulrich Drepper
<sadmac2> Uli is very lucky that he's somewhat large
<Keybuk> really, I always imagined him to be somewhat gaunt and lanky
<Keybuk> perhaps he has so much anger that I mentally placed an image of Matthew Garrett over him
<sadmac2> Keybuk: angryfacts.com ?
<sadmac2> Keybuk: First time I met Uli, he was wearing black socks with sandals. Even his fashion sense was rife with hostility.
<Keybuk> lol
<sadmac2> Keybuk: http://upload.wikimedia.org/wikipedia/commons/5/5b/Ulrich_Drepper.jpg
<sadmac2> he looks like a long-washed-up 80s hair metal guitarist
<Keybuk> yeah I saw
<Keybuk> grr
<Keybuk> why does this test case *pass*
<Keybuk> oh, I see
#upstart 2009-07-03
<rikard> does someone know how to set "respawn" in upstart 0.5.0?
<Keybuk> rikard: "respawn" :-)
<rikard> I know, I have tried the following:
<rikard> start on stopped S70motion and stopped S71iod
<rikard> console output
<rikard> respawn
<rikard> script
<rikard>         exec /etc/rc3.d/S85httpd start
<rikard> end script
<rikard> but I can't get it to work?
<rikard> what's wrong?
<Keybuk> it'll respawn the init script
<Keybuk> not what the init script runs
<Keybuk> you can't combine respawn and init scripts in that way
<Keybuk> convert the init script into a proper upstart job instead
<rikard> how to do it?
<Keybuk> that's a complex question
<Keybuk> but fundamentally your script should look something like
<Keybuk>   console output
<Keybuk>   respawn
<Keybuk>   exec /usr/sbin/httpd --foreground
<rikard> ok, thanks a lot for your help!
<ion> http://www.milepost.eu/
#upstart 2009-07-05
<lightpriest> anyone here?
#upstart 2010-07-06
<beppo> hello anyone here?
<beppo> :)
<beppo> how can i add to smbd.conf that it should start after network interface is started
<twb> Does upstart log anywhere (e.g. netconsole) when and what events it receives?
<twb> I'm netbooting Ubuntu 10.04 and for some reason the secondary (read-write) NFS mounts on /home and /srv are never mounted.
<twb> Also, how can I get a directed graph of how events are generated and what responds to them?
<twb> It's a lot harder to see the boot order than a simple rcS.d
<soren> twb: I don't think such a tool exists.
<soren> twb: Also, an upstart job can specify which events it might emit, but it's purely informational. It can emit other ones and never emit the ones it claimed it might.
<soren> twb: ...so any automatically generated graphs of events can't possibly be guaranteed to be accurate.
<twb> I only want a rough approximation, and/or a tracing of *a* real boot
<twb> I don't expect it to be perfect
<twb> Is $PATH guaranteed to be a particular value in upstart scripts (i.e. within sh embedded in /etc/init/foo.conf files)?
<twb> Why does statd.conf's pre-start script say "start portmap || true"?  Are scripts invoked with sh -e?
<twb> Christ, this is confusing.
<twb> Where does $UPSTART_STOP_EVENTS come from, for example?
<twb> mountall-shell.conf checks its value without ever setting it
<ion> PATH is predefined IIRC. -e is on by default, as init(5) says. UPSTART_STOP_EVENTS is documented in there as well.
<twb> Hum, I'll read that manpage.
<twb> init(8) talks about /etc/init.conf, but it doesn't exist and there's not init.conf manpage.
<twb> s/not/no/
<twb> Does upstart detect cycles in the event-wait dependency graph?
<twb> e.g. in the simplest case, foo.conf has "start on bar", and bar.conf has "start on foo"
<ion> Thereâs nothing wrong with tht.
<twb> Well, I suppose not, if you assume the user can get into the system and run "start foo" by then
<ion> To be more accurate, foo.conf: âstart on started barâ, bar.conf: âstart on started fooâ should work just fine. It just ensures both are running whenever either one is. s/started/starting/ may cause neither to be able to start.
<mbiebl> twb: have you tried the --verbose boot parameter?
<twb> Hum, "--verbose"?  Not "verbose"?
<mbiebl> twb: so, apparently you haven't :-)
<mbiebl> yes, it is --verbose
<mbiebl> see also man 7 upstart
<twb> Yeah, that's exactly what I wanted
<twb> Will that get dumped to netconsole?  /me tries
<twb> Well, it probably would, if I could get netconsole.ko to load properly from the ramdisk :-/
<twb> Nope, upstart --verbose output never hits netconsole, so I have no way to get a dump of it short of transcribing the last few lines that are left on the screen.
#upstart 2010-07-07
<frederickjh> I am working on writing an upstart job for a program that has three daemons that must be started in a specific order, stopping is not so important but the prefer order is the same in reverse. Can this be done with one upstart job or is it needed to write one for each daemon?
<frederickjh> I am working on writing an upstart job for a program that has three daemons that must be started in a specific order, stopping is not so important but the prefer order is the same in reverse. Can this be done with one upstart job or is it needed to write one for each daemon?
<mbiebl> frederickjh: if you want those three daemons monitored by upstart, you need to split them
<frederickjh> ok
<frederickjh> Thats what I thougt.
<frederickjh> I had tried with two as a test in a job but only the second one was running at the end.
<mbiebl> two exec lines?
<frederickjh> yes
<mbiebl> yeah, the parser only takes the last parsed line
<frederickjh> ok
<frederickjh> I have another question regarding the program with three daemons.  I think it is possible to have another job with the name of the collective program that could emit a job and start the others.
<frederickjh> But is it possible to check the status of the "dummy" job and have it return the status of the 3 daemons?
<frederickjh> Instead of having to check the status of three daemons individually.
<mbiebl> no
<Seq> Is it possible to have an upstart script start and stop based on an old sysv script?
<mbiebl> Seq: no, not really
<mbiebl> afaik, fedora has patched the rc script to emit events when an sysv script is started and stopped
<mbiebl> /etc/rc.d/rc, to be specified
<Seq> mbiebl: Thanks. I don't control the other init script, so modifying it would be troublesome.
<mbiebl> that does not help you though, if you e.g. stop a sysv script via /etc/init.d/<service> stop
<Seq> mbiebl: true, I hadn't thought of that.
#upstart 2010-07-08
<maek> hi. Im a but confused on upstart. when I do status mysql I get this - mysql stop/post-start, (post-start) process 651
<maek> what does that mean?
<mbiebl> maek: pastebin your mysql job file, please
<maek> mbiebl: whats that? the /etc/init/mysql.conf file?
<mbiebl> yes
<maek> mbiebl: http://gist.github.com/467427
<mbiebl> maek: looks like the job is hanging in th post-start script 
<mbiebl> I assume you have a /usr/bin/mysqladmin --defaults-file=$HOME/debian.cnf ping process running
<maek> mbiebl: there is no process with the word 'mysql
<maek> mysql running
<maek> ps ef |grep mysql shows only my grep
<mbiebl> you should show all processes
<mbiebl> something like ps aux
<maek> mbiebl: same, just my grep
<maek> I thought ef shows everying in linux
<mbiebl> maek: that is the process with id 651
<mbiebl> s/that/what/
<maek> root       651  0.1  0.0   1828   524 ?        Ss   15:59   0:01 /bin/sh -e /proc/self/fd/8
<mbiebl> could you show the child processes of 651
<mbiebl> this should help you find out, where it got stuck
<maek> mbiebl: pstree pid is the only way I can think to do that. is that correct?
<mbiebl> that should work
<maek> cdickerson@isodb02:/etc/mysql$ sudo pstree 651 shâââsleep
<maek> mbiebl: got it working, thanks.
<twb> With a job like rc, which terminates, how do I tell the difference between "stop/waiting" (I haven't run yet) and "stop/waiting" (I ran, finished, and stopped) ?
#upstart 2010-07-10
<PenguinOfDoom> How can I watch upstart events in real time
<PenguinOfDoom> ?
#upstart 2011-07-04
<amit> Hello all. Would appreciate clarification on the next one: What's the recipe for telling a job to stop when another, *non-upstart* daemon is stopped (More broadly, instruct the job: "You stop running if this job stops running").
#upstart 2011-07-06
<eboyjr> Hey I have a node server and I think it's starting to soon and fails and gets respawned too many times
<eboyjr> And then it doesn't start
<eboyjr> What can I start it one so that it is basically the last to start?
<eboyjr> start it on*
<eboyjr> The cookbook thing says I can use: start on (local-filesystems and net-device-up IFACE!=lo)
#upstart 2011-07-07
<serge_> jhunt: hey are you around?
<jhunt> serge_: hi
<serge_> jhunt: oh, hey.  I wanted to get your input on bug 495394
<serge_> jhunt: in particular, as to whether the /etc/init/networking-up.conf' should be shipped with libvirt
<serge_> (and called libvirt-networking-up), or with something more general?
<jhunt> k - looking at bug...
<serge_> ignore comment 30, i'm basically going to use the debdiff attached to comment 24
<jhunt> serge_: first question is why bridge-network-interface.conf is no longer in bridge-utils. The oneiric changelog suggests it should (still) be by the looks of it.
<serge_> i thought they were suggesting a udev rule took its place
 * serge_ goes to look more closely
<serge_> yeah, it's covered
<serge_> by bridge-utils.bridge-network-interface.udev and bridge-network-interface.sh
<serge_> jhunt: and really the explanation of its interaction doesn't make sense to me.  THe net-device-up should still have been sent.
<serge_> all that job did was bring up the bridge_ports
<serge_> jhunt: so, en fin, what i'm wondering is whether networking-up.conf should ship with ifupdown or something
<serge_> i'm happy to put it into libvirt, just don't want to put it in only to pull it out next week :)
#upstart 2011-07-08
<pgr> hi. how to properly integrate svnserve into upstart? i can start but not stop (hangs)
<pgr> "exec sudo -u svn /usr/bin/svnserve -d -r /srv/svn/repos" <-- did experiment with "expect daemon/fork"
<ion> Do not use âexpectâ unless youâre absolutely sure of the behavior of the main process wrt. forking.
<ion> Better just to make the service not fork if possible, while weâre waiting for the new fork-following implementation in a future version of Upstart.
<ion> s/fork if/daemonize if/
<pgr> the problem is, that svnserve requires one of the options: -i (inetd) -d (daemon)
<pgr> i think, inetd is totally incompatible to upstart, right?
<pgr> (with inetd i mean -i option)
<pgr> maybe i am confusing between inet and init. so would installing inetd daemon solve the problem, as svnserve does not need to daemonize?
<pgr> "inet-service", "listen on", so upstart will replace inetd someday
<ion> Offering only inetd and daemonizing modes is insane. But hey, itâs svn, it can be expected to be insane in other things than version control, too. :-P
<ion> Given Upstartâs presently lacking fork tracking and missing inetd mode and given svnserveâs stupidity with the operating modes, iâd probably just go with xinetd.
<pgr> as xinetd is itself a service, how to integrate xinetd into upstart?
<ion> Just let xinetd be started by whatever the packaging comes with.
<pgr> revoking question, xinetd starts -- inetd package did not
<pgr> ok, seems to start/stop fine with xinetd. would have been nice to do it with upstart. I like it combining a lot of tools and using simple statements.
<pgr> i read about another upcoming init replacement in a computer magazine: systemd. which one will make it?
<ion> Seems to me that systemd tries to be like appleâs launchd the design of which was considered in the first place when beginning the development of Upstart and dropped for its faults.
<Keybuk> pgr: I think both have already met the minimum definition for "make it"
<Keybuk> that's the thing about Linux, there can be more than one winner
<pgr> atm I will stick to upstart and try to learn more about it.
<pgr> is it possible atm to use upstart instead of cron to do periodic (svn) backups?
<ion> Cron functionality is another thing thatâs not implemented yet but will at some point in the future. :-)
<pgr> damn :)
<Keybuk> ion: James does have the cron code now
<ion> cool
#upstart 2011-07-09
<tgm4883> Is there a way to run multiple exec from an upstart job? 
<tgm4883> Basically I want to do this  http://pastebin.com/nndv8gWm
<tgm4883> but everytime I try this, it seems that bareserver.py stops while bareprocessor.py keeps going. Commenting out the bareprocessor.py line makes bareserver.py start correctly
<ion> tgm4883: Make a bareserver job and a bareprocessor job.
<tgm4883> ion, ok, I thought that was going to be the outcome, was hoping I could do it the other way though. Thanks
#upstart 2012-07-02
<SpamapS> wmp: upstart has never worked properly w/ vserver
<wmp> SpamapS: i know this, but maybe is way to repair this
<wmp> SpamapS: ubuntu 10.04 work good with vserver
#upstart 2012-07-03
<pmjdebru1jn> hi guys
<pmjdebru1jn> I have a Ubuntu Precise system running in a large ramdisk (so no initrd/pivotroot construct)
<pmjdebru1jn> the ramdisk is the main system
<pmjdebru1jn> now when booting I get
<pmjdebru1jn> init: Failed to create pty - disabling logging for job
<pmjdebru1jn> from what I rather this is because /dev/pts probably isn't mounted yet (since this would usually be done by the initrd)
<pmjdebru1jn> the question is what would be the best point to mount /dev/pts 
<pmjdebru1jn> I could create my on job
<pmjdebru1jn> though on what event should it be started, what is most wise?
<pmjdebru1jn> btw
<pmjdebru1jn> the /dev/pts filesystem is mounted on this system
<pmjdebru1jn> though I don't see where it gets mounted
<jodh> pmjdebru1jn: this is a known limitation. /dev/pts is probably being mounted by mountalls built-in fstab (/lib/init/fstab).
<pmjdebru1jn> ok
<pmjdebru1jn> is there a way to workaround this?
<pmjdebru1jn> by creating my own upstart job to mount /dev/pts? 
<pmjdebru1jn> at an earlier stage
<jodh> mountall already starts as early as possible. The simplest solution is to boot with '--no-log' to disable job logging, since this is that part of Upstart that requires /dev/pts.
<pmjdebru1jn> jodh: I read about that
<pmjdebru1jn> just wondered if there was a way to deal with it differently
<pmjdebru1jn> jodh: anyhow, thanks for your time
<pmjdebru1jn> I'll go with --no-log then
<JanC> I guess you could use alternative ways to run something before upstart
<JanC> actually, it's quite easy to start a job before all other jobs, including mountall etc.
<JanC> if that would be helpful...
<JanC> pmjdebru1jn: ^^^
<pmjdebru1jn> well if mountall is already among the first job to start I guess it probably won't make a difference
<pmjdebru1jn> still thanks for the thought
<JanC> I never tried a setup like yours, but does it prevent loging for all jobs, or only for jobs started before /dev/pts is mounted?
<pmjdebru1jn> I think only the first few
<pmjdebru1jn> but I'd have to investigate to be sure
<JanC> okay, then you could add "--startup-event pre-startup" to the kernel commandline and add a job that starts on the 'pre-startup' event which mounts /dev/pts (and maybe does other things?) and then emits the 'startup' event (which is the default event emitted on boot, so it should start whatever would normally be started)
<JanC> that way, only this "pre-startup job" would not be logged
<JanC> I think
<JanC> ;)
<JanC> mountall is started in parallel with other jobs, so it's normall some of them start before mountall has the chance to mount /dev/pts
#upstart 2012-07-04
<pmjdebru1jn> is there an upstart config file too? so these parameters won't have to be passed on the kernel commandline?
<intgr> Hi! So I have a custom init conf script. Whatever I do, upstart doesn't even attempt to start the service. It just says it's either "start/killed" or "stop/killed" with the same old PID, every time.
<intgr> http://codepad.org/3oSxyR4p
<intgr> The PID doesn't even change when I try to start/stop it
<intgr> Nothing gets written to syslog or /var/log/upstart/daemonlogger.log
<intgr> Nor is there a "daemonlogger" process
<intgr> And the process 11920 hasn't existed for ages
<intgr> Oh great, now I ran "reboot" and it hung at "Asking all remaining processes to terminate..."
<intgr> Well the service used to include "expect fork" in it. When I re-add that back I can reproduce this problem, which seems like a bug.
<jodh> intgr: take a look at http://upstart.ubuntu.com/cookbook/#precepts-for-creating-a-job-configuration-file, http://upstart.ubuntu.com/cookbook/#determining-the-value-of-expect.
<jodh> intgr: as the cookbook mentions, never add "respawn" until you are convinced the job is behaving correctly.
<jodh> Also, please see http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
<intgr> jodh: Regardless, a bad configuration file shouldn't prevent the machine from rebooting, no?
<intgr> ?c
<jodh> intgr: it shouldn't.
<jodh> intgr: at a guess, I'd say your daemonlogger is forking and then dying. You need to know how many times it forks - http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count
<intgr> I'll just exec it without daemonization, hopefully then Upstart won't crash
<jodh> intgr: I don't think Upstart is crashing here - you'll get a kernel panic if it is.
<intgr> Well a hung reboot is a "crash" in my mind.
<jodh> intgr: if you are running on Ubuntu, that shouldn't be possible.
<intgr> Ubuntu 12.04, up to date.
<jodh> intgr: please raise a bug with full step-by-step details on how to recreate then.
<intgr> My reset button is wearing out already...
<intgr> :)
<intgr> jodh: Any ideas how to fix this without a cold reboot? I already started this job on our live server.
<jodh> intgr: the links above explain how to build up a .conf file. I suggest you try to run daemonlogger outside of Upstart (http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job) and once you have that working and know how many times it forks, start testing your .conf job without 'respawn' initially.
<jodh> intgr: or are you referring to how to reboot your system?
<intgr> jodh: I mean how do I fix upstart so the next shutdown won't hang forever.
<jodh> intgr: well, since I don't know what is causing the hang, difficult to say aside from disabling the job you are developing.
<intgr> Ok...
<intgr> jodh: Do you want to try to reproduce? http://codepad.org/lgj4aS2j
<jodh> intgr: I cannot recreate your hang - even mis-specifying the .conf file does not cause a problem on shutdown.
<jodh> intgr: looks like daemonlogger is only forking once btw so your job should specify "expect fork".
<intgr> jodh: Same thing happens when I use "expect fork"
<jodh> intgr: try creating a fresh 12.04 install as I suspect something else has changed on your system. If that still fails, please raise a bug with full details.
<intgr> This is pretty fresh -- I just cloned it from our VM template (which is a clean 12.04 install with a few additional services)
<jodh> intgr: what services? does a clean cloned system with no daemonlogger.conf reliably shut down?
<intgr> And the machine I initially experienced this on was installed yesterday, with a different configuration.
<intgr> If I remove the daemonlogger.conf file, it shuts down nicely again.
<intgr> Or if I simply don't start the service
<intgr> Oh, and the "stop daemonlogger" command is necessary too -- it doesn't hang if I don't run that.
<intgr> Did you run that?
<intgr> The VM template has acpid, atop, ntpd and is using linux-virtual kernel
<jodh> intgr: ah - because you're running "stop", but that can never complete successfully (as you've mis-specified 'expect'), yes Upstart will wait until it gets confirmation your process has ended.
<intgr> And this prevents shutdown, too?
<jodh> In the scenario where a user has manually run 'stop', not interrupted it, mis-specified 'expect' and not specified 'stop on'... yes.
<jodh> intgr: please raise a bug so we can try to find a way to identify such jobs and handle them.
<intgr> Sure
<intgr> Thanks for being heplful :)
<jodh> intgr: np. Your job prolly wants to look something like this: http://paste.ubuntu.com/1074736/
<jodh> intgr: ... although, putting logs in /tmp prolly isn't such a good idea ;)
<intgr> :)
<jodh> intgr: in fact that "pre-start script" can be just "pre-start exec mkdir $dir". It'll be handled the same internally, but it's results in a cleaner conf file.
<intgr> jodh: Does "expect" work with "script/end script"?
<jodh> intgr: "yes", but be careful since Upstart starts counting forks immediately so if your script starts by doing something like "var=$(cat /etc/somefile)", Upstart will follow the fork of /bin/cat - not what you want.
<intgr> I see
<jodh> intgr: but crucially 'expect' only works for the "main" exec or script section. Hence, makes sense to do setup in pre-start for example.
<intgr> jodh: Well it works with exec, but still not with script: http://paste.ubuntu.com/1074741/
<intgr> Oh, it doesn't hang anymore, just doesn't get the right PID
<jodh> intgr: you can overcome that issue btw by having 2 conf files - one which does the setup and reads files, etc and then runs "start job2 var1=a var2=b varc='hello world'" or similar. All those variables will be available to job2 which can just do "exec mydaemon -l $var1 -i $var2" and specify "respawn" too.
<jodh> intgr: if the pid is incorrect, you've mis-specified expect somehow.
<intgr> I'm using "expect fork" just like you did
<jodh> intgr: you need "exec daemonlogger" *within* that script section.
<intgr> Ah ok
<intgr> jodh: https://bugs.launchpad.net/upstart/+bug/1020951
<jodh> intgr: thanks.
<benbro> how can I run a service only after postgresql is running?
<benbro> I currently have this in my upstart script:
<benbro> start on (local-filesystems and net-device-up IFACE!=lo)
<jodh> benbro: nominally, "start on stopped rc" (since postgresql is a SysV service in Ubuntu atm I think).
<jodh> benbro: however, that assumes that when the postgresql SysV service script finishes that the postgresql server is ready to accept connections.
<benbro> jodh: and it is not always the case?
<intgr> benbro: I believe the Ubuntu Postgres init script returns immediately after launching postmaster.
<intgr> If your machine crashes/loses power, Postgres has to perform recovery at startup, which can take a long time
<intgr> (depending on your checkpoint_* settings)
<benbro> intgr: so there is no way to start my service after postgres?
<benbro> intgr: maybe my service should just retry creating the connection
<intgr> Yeah, that's what I do
<benbro> thanks
<benbro> in that case I should still use "start on stopped rc" or something else?
<intgr> benbro: Also beware that PostgreSQL may be restarted without warning if you have unattended upgrades enabled.
<benbro> I don't think I allow automatic upgrades
<benbro> should I use "start on (local-filesystems and net-device-up IFACE!=lo)" if I'll just retry creating the connection to postgres?
<jodh> benbro: use "start on stopped rc" but you may have to poll as intgr suggests as you cannot guarantee that the db is servicing requests just because some process is running.
<benbro> jodh: thanks
<axisys> what is update-rc.d -f name remove equivalent for upstart process?
#upstart 2012-07-05
<axisys> I am on upstart 0.6.5 .. so I guess just comment out start on line would be my only choice?
<axisys> i am on lucid lts
<SpamapS> axisys: yes thats the option you have on lucid
<axisys> SpamapS: thanks
<pmjdebru1jn> hi again
<pmjdebru1jn> I'm using/contributing to UCK (Ubuntu Construction Kit)
<pmjdebru1jn> which allows one to remaster Live CD ISOs by rebuilding the squashfs
<pmjdebru1jn> most of it works fine
<pmjdebru1jn> as far as I can tell it surpresses the starting of services mv /bin/initctl /bin/initctl.blocked; ln -s /bin/true /bin/initctl
<pmjdebru1jn> however when the upstart packages gets upgraded that link is replaced with an original binary again, and services can be started again
<pmjdebru1jn> there here a more robust way to inhibit upstart from starting services?
<pmjdebru1jn> like policy-rc.d ?
<JanC> pmjdebru1jn: about your question about an upstart config file yesterday: I don't think there is one
<JanC> but on a "normal" Ubuntu system with GRUB you can add it to /etc/default/grub
<JanC> I'm not 100% that works without an initrd though
<JanC> well, I guess it could work (I suppose it works as long as update-grub is run on kernel upgrades?)
<JanC> and if you want to inhibit certain services from starting, just add a servicename.override which doesn't have a "start on" line in /etc/init/
<JanC> starting nothing sounds like a very weird thing to me  âº
<pmjdebru1jn> JanC: I already used --no-log passed via pxelinux
<pmjdebru1jn> JanC: well, chroot environments
<pmjdebru1jn> it's fairly common
<pmjdebru1jn> the problem with the .override file is that I can't predict which services need blocking
<pmjdebru1jn> the debian policy-rc.d allows everything to be blocked
<pmjdebru1jn> which is ideal for this use-case
<pmjdebru1jn> the lame solution would be to just hold upstart, and to never upgrade it when remastering the cd
<pmjdebru1jn> but that would be a shame
<JanC> do you actually need upstart to be installed then?
<pmjdebru1jn> "installed"?
<pmjdebru1jn> upgraded
<pmjdebru1jn> upstart is already on the live cd
<JanC> if it isn't installed, you never upgrade it...
<pmjdebru1jn> huh?
<JanC> and you can remove it, of course
<pmjdebru1jn> it's the desktop cd
<pmjdebru1jn> removing upstart will criple it
<JanC> well, I'm not sure what you try to do
<pmjdebru1jn> as in ubuntu-12.04-desktop-amd64.iso  
<pmjdebru1jn> modifying the ubuntu live cd
<pmjdebru1jn> uck, unpack the squashfs, chroot's to it, allows you to modify stuff, and then repacks it
<pmjdebru1jn> nifty stuff
<JanC> ah, so you need to disable upstart while doing the changes in the chroot?
<JanC> scripted chengexs
<JanC> changes
<pmjdebru1jn> right
<pmjdebru1jn> but the disabling of upstart needs to be able to survive upstart package upgrades
<pmjdebru1jn> uck alreayd disables starting of services by diverting /sbin/initctl
<pmjdebru1jn> but that fails when upstart is upgraded
<JanC> because changes might include upgrades...
<pmjdebru1jn> including updates into the ISO is a huge boon
<pmjdebru1jn> especially a few month's after release
<JanC> hm, does initctl actually look at the upstart config files in the chroot?
<JanC> I would assume upstart is running outside it
<pmjdebru1jn> sure
<pmjdebru1jn> but divering initclt means dpkg just executes /bin/true instead of calling upstart
<pmjdebru1jn> thus the service doesn't get started, without any further errors
<pmjdebru1jn> until the upstart package itself is upgraded
<pmjdebru1jn> it's possibly to deal with this situation manually
<JanC> I'm starting to understand the problem, I think...
<pmjdebru1jn> but I'm looking for a structural solution, so people using uck aren't hit by this issue
<pmjdebru1jn> there are also upgrade problems with grub
<pmjdebru1jn> but I just added some code, to hold those packages, so they aren't upgraded accidentally
<pmjdebru1jn> so if nothing else works, I guess I could do that too for upstart,
<JanC> I wonder if a fake upstart dbus service inside the chroot is possible...   ;)
<pmjdebru1jn> heh
<pmjdebru1jn> that's nasty
<JanC> just fake you are upstart (inside the Chroot)
<JanC> and do nothing
<pmjdebru1jn> yeah
<pmjdebru1jn> I was hoping upstart had a standard feature for this
<pmjdebru1jn> as it's not that uncommon
<pmjdebru1jn> I wonder how they do this when generating the live cd's from scratch
<pmjdebru1jn> similar issues must occur
 * pmjdebru1jn wonders if systemd also discounts lots of use-cases like upstart :(
<pmjdebru1jn> I used to like to idea of replacing SysV init... not so much anymore
<pmjdebru1jn> https://help.ubuntu.com/community/LiveCDCustomizationFromScratch/
<pmjdebru1jn> dpkg-divert --local --rename --add /sbin/initctl
<pmjdebru1jn> at least there they use a dpkg-divert
<pmjdebru1jn> instead of just mv / ln
<JanC> that's more likely to persist indeed
<pmjdebru1jn> right
<pmjdebru1jn> but then I wonder where to initctl binary in the newer packages is placed
<pmjdebru1jn> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430224
<pmjdebru1jn> it's marked won't fix
 * pmjdebru1jn sighs
<pmjdebru1jn> oh wait
<pmjdebru1jn> got re-opened
<pmjdebru1jn> Chroot support is now available in Upstart 1.3.
<pmjdebru1jn> hmmm
<pmjdebru1jn> https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverviewUpstart
<pmjdebru1jn> ok
<pmjdebru1jn> so this behavior was actually _added_ to support vserver/lxc etc
<pmjdebru1jn> and can be disabled system-wide
<pmjdebru1jn> which means fiddling with kernel options
<pmjdebru1jn> :(
<pmjdebru1jn> anyhow
<SpamapS> pmjdebru1jn: AFAIK, the upstart chroot support has nothing to do with vserver/lxc
<SpamapS> pmjdebru1jn: since neither of those use pure "chroots"
<pmjdebru1jn> ok
<pmjdebru1jn> then I'm not sure why that's built into upstart
<SpamapS> they both namespace the kernel
<SpamapS> pmjdebru1jn: for actual chroots
<pmjdebru1jn> as without vserver/lxc you usually don't want stuff to actually RUN in a chroot
<SpamapS> pmjdebru1jn: it comes in handy for testing
<pmjdebru1jn> heh
<pmjdebru1jn> possibly
<pmjdebru1jn> it's a PITA as it seems it can't be disabled _easily_
<pmjdebru1jn> but dpkg-divert will probably work well enough
<jMCg> Hello happy people o/~
<jMCg> I have upstart 1.5 running and a job which is in the state of: logstash stop/killed, process 18506
<jMCg> The job itself was killed, I was so clever as to pkill it, so that upstart would restart it, and I would have it reload the config.
<jMCg> My being clever wasn't all that clever at all. Now I'm stuck in this state.
<jMCg> .
<JanC> starting the job doesn't work?
<jMCg> JanC: nope, hangs the same as stop logstash
<jMCg> http://dpaste.com/767785/
<jMCg> Of course this tracks the 'su', but even so, it should've respawned the friggin job, because it's *all* gone.
<JanC> hm, I seem to remember start-stop-daemon is currently the officially recommended way instead of su
<jMCg> oh crap. There's setuid/setgid now?!
<jMCg> In 1.5, that is..
<JanC> that too
<jMCg> So, on Ubuntu 10.04 I should use start-stop-daemon, and on 12.04 I should use setuid/setgid then.
<JanC> you can use s-s-d on both, I suppose
<jMCg> Yeah, but I'd rather not :P
<jMCg> Well, that still doesn't quite help me with the start/stop that doesn't start/stop :-/
<jMCg> /proc/self/fd/9: 2: /proc/self/fd/9: setuid: not found
<SpamapS> jMCg: if you have a process listed that isn't running, you set 'expect fork' incorrectly
<jMCg> SpamapS: yeah, and how do I fix it, other than rebooting the machine?
<SpamapS> jMCg: loop fork/wait until the process comes up, then wait for upstart to see it and let go
<SpamapS> jMCg: there's a ruby and a python version of that out there
<jMCg> O_o
<SpamapS> I'm surprised we haven't fixed that with an 'initctl forget-pid job-name'
<SpamapS> jodh: ^^
<jMCg> There's a forget-pid?!
<jMCg> Oh. No there isn't.
<SpamapS> http://paste.ubuntu.com/1076921/
<SpamapS> jMCg: there *SHOULD* be a forget-pid
<SpamapS> or even better, we should stop abusing ptrace. :)
<jMCg> SpamapS: yes
<jMCg> Oh how I yearn for Solaris' simplicity..
<jMCg> Did I just seriously say Solaris' simplicity?!
<SpamapS> hahahahhaaha
<SpamapS> jMCg: I tend to recommend that people just avoid 'expect fork' or 'expect daemon'
<jMCg> Anyway, solaris has a process-contract by default, so you follow that and don't care about the forks or how many there are.
<jMCg> SpamapS: *nod*
<SpamapS> use a post-start to determine when the job is ready
<SpamapS> since fork() is actually also rarely the time when things are ready.. just closer to it than exec()
<jMCg> So, first: Does that thing work with python != 3?
<SpamapS> jMCg: probably
<SpamapS> jMCg: I wrote it as python3 as part of my "getting used to python 3" experiment :)
<jMCg> SpamapS: how often/long will it have to run?
<SpamapS> jMCg: just run it once.
<SpamapS> jMCg: it will loop through the whole pid space until it finds the necessary pid
<jMCg> SpamapS: okay. That fixed it. Now on to the next issue:
<jMCg> /proc/self/fd/9: 3: /proc/self/fd/9: setuid: not found
<SpamapS> jMCg: thats weird
<jMCg> When I set setuid logstash/setguid adm
<jMCg> http://dpaste.com/767807/
<jMCg> That's the whole deal.
<SpamapS> ahh wrong place
<SpamapS> jMCg: they're root stanzas, not in the shell
<SpamapS>         exec java -jar logstash.jar agent -f logstash.conf --log logstash-indexer.out -- web --log logstash-web.out --backend elasticsearch://localhost/
<SpamapS>         emit logstash-indexer_running
<SpamapS> jMCg: also on that, exec never returns
<SpamapS> so emit will never happen
<SpamapS> and I don't believe it is a sub-command in the path, so 'initctl emit'
<SpamapS> jMCg: further, you don't need that emit.. 'started logstash' is the same event
<jMCg> SpamapS: yeah, but that's not so much the issue as the setuid stuff ;)
<jMCg> ah
<jMCg> root stanzas, now I see
<jMCg> SpamapS: but the chdir is not?
<SpamapS> jMCg: chdir is also a root stanza
<SpamapS> jMCg: tho it also exists in shell, which is why thats working.
<SpamapS> jMCg: I'd put it at the root tho, much cleaner
<SpamapS> 	[ -f ./logstash.rc ] && . ./logstash.rc 
<SpamapS> jMCg: you can also elimiate that and just use env statements at the root
<SpamapS> unless there's some important reason that it might be there instead
<jMCg> SpamapS: nope. There is not.
<thinkingpotato> is it possible some services cannot be controlled using Upstart? I have a case I can't get working, checked everything I possibly could (based on cookbook, forums, blogs, stackoverflow etc.)
<jMCg> SpamapS: but env cannot be a file.
<SpamapS> jMCg: right, thats the point, so if you need it in a file, leave it as-is.. but if you can store it all in one .conf file with env X=y statements, do that.
<SpamapS> thinkingpotato: no, upstart can "control" any service. What is possible is that the pid of the daemon may have to be tracked using pidfiles rather than upstart's methods (making respawn challenging)
<thinkingpotato> SpamapS: thanks for the answer, so approach such as http://askubuntu.com/a/4413 could give me some results?
<jMCg> SpamapS: where's the init(5)'s source?
<jMCg> found.
<thinkingpotato> ok, I tried setting manual start - apparently it depends on some other services, because I'm able to start it from console, good thinking?
<pmjdebru1jn> JanC: btw just tested, dpkg-divert practically solved my problem
<thinkingpotato> 10 hours later: that was a wrong uid/gid I started with... problem solved, works like charm
#upstart 2013-07-01
<xnox> pfak: with .override files you can change particular stanza, e.g. override just the exec stanza to add more parameters and the rest (pre-/post- start/stop) will be kept.
<xnox> pfak: or make a new different job "start on started foo" to have things execute straight after.
<xnox> pfak: what job do you want to append to? and what do you want to append?
<Trevinho> Hey... Since the upgrade to kernel 3.10 in saucy. I can't boot anymore using the normal mode... (see bug #1195687), is that somewhat known?
<Trevinho> Using the recovery mode works instead...
<jodh> Trevinho: please see the latest comment on the bug.
<Trevinho> jodh: I think I'm unable to boot... All I get it's a black screen (i didn't check withot quiet yet  but it seems like a problem in initializing plymouth), checking that though, thanks
<Trevinho> jodh: what's the best way for you to make me get the console log?
<jodh> Trevinho: I don't know what hardware, etc you have - can you just confirm whether there is a crash shown onscreen when you remove 'quiet' and 'splash'? if so, a photo attachment is good enough.
<Trevinho> jodh: ok
<Trevinho> jodh: unfortunately I'm getting a black screen...
<Trevinho> jodh: also removing splash and quiet I'm getting a fast log, then the screen gets blank
<Trevinho> (and nothing in /var/crash this time)
<jodh> Trevinho: can you ctrl-alt-f1/f2? do the caps-lock/num-lock lights still work? is the system accessible via ssh? please could you add those details to the bug.
<axyelp> how do i add a random number to my exec script? using env VARIABLE=$((RANDOM%100) doesn't work
<Trevinho> jodh: mh, ok, I'll check that... 
<Trevinho> jodh: however I've found what's blocking init
<Trevinho> jodh: I'm using the custom cmd line for linux radeon.audio=1
<Trevinho> jodh: removing that it boots with normal boot profile..
<Trevinho> jodh: that's weird btw... as it seems to work in recovery
<axyelp> any way to use random values in upstart?
<jodh> axyelp: 'env' doesn't pass the variable value through a shell for expansion, but you can obviously set variables in a script section. If this is a Session Init job however, you *can* do what you want though by having your job call "initctl set-env VARIABLE=$((RANDOM%100))" in say the pre-start section, and that would then be available to all other sections.
<Trevinho> jodh: just checked... not using hdmi audio in recovery mode so it seems mostly a kernel issue.. mh
<axyelp> jodh: thanks? is there anything specific to import before using it? adding the line breaks the script
<jodh> axyelp: before using initctl? no. breaks how?
<axyelp> jodh: by printing 'start: Job failed to start'
<jodh> axyelp: run init-checkconf /etc/init/your-job.conf
<axyelp> jodh: it does say syntax ok!  here's the script - http://pastebin.com/dKb2thLM
<jodh> axyelp: RANDOM is a bash-ism. see http://upstart.ubuntu.com/cookbook/#changing-the-default-shell
<axyelp> i'm trying with $(od -An -N2 -i /dev/random). sigh!
<axyelp> jodh: alright! will try that too!
<axyelp> jodh: well! /dev/random did the trick! thanks! :)
<jodh> axyelp: np.
<pfak> xnox: libvirt-bin, i actually wanted to prepend ..
<xnox> pfak: prepend to exec line should be easy..... inside script doable.... pre-start/pre-stop - well hard
<xnox> pfak: best edit it inline imho.
<pfak> ah
<pfak> I just copypasted the stanza
<pfak> http://paste.pfak.org/6ea4QJXb
<pfak> that look proper?
<xnox> pfak: yes.
<pfak> sweet!
<jodh> pfak: you might want to add "|| :" to the end of that ovs-vsctl line in case grep fails say.
<pfak> ovs-vsctl show | grep 'Port \"vnet.\"' | awk -F\" {'print $2'} | xargs -I {} ovs-vsctl del-port {} || :
<pfak> ?
<jodh> pfak: if any of those commands fails, the pre-start will fail, and your job will fail since upstart runs all scripts with "sh -e". See http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<pfak> sexy
<pfak> (you'll have to pardon me for not rtfmin'g the WHOLE upstart guidebook)
<pfak> well, hopefully that fixes my problem
<JoeJulian> I created this conf expecting that as a "task" it would finish before prefdm tries to start. I'd like prefdm to block until this script is finished, otherwise it starts with system defaults instead of the preset user config I want for my users.  http://ur1.ca/ei0a7
<JoeJulian> It seems to work most of the time, but not reliably.
<JoeJulian> I also don't want to modify the packaged prefdm.conf 
<JoeJulian> Oh, and this is the centos rpm, upstart-0.6.5-12.el6_4.1.x86_64
<pfak> Can't you just use an override?
<JoeJulian> searching...
<JoeJulian> Looks like no. Apparenly that comes with 1.3
<JoeJulian> Hmm, maybe I'll try it anyway. There is a ".override" string in /sbin/init
<pfak> :\ too bad
<pfak> Ah!
<JoeJulian> And if I'm reading this correctly, I can just put the stanza that I want overriden in the .override and the rest will run from the original?
<pfak> yes
<JoeJulian> perfect. Thanks pfak. That was the bit I needed.
<pfak> It worked? Great.
<xnox> JoeJulian: hmm... to block a job foo with your own task, you make your job "start on starting foo"
<JoeJulian> xnox: that's the way it was set, but it wasn't always consistent. (yes, it's been hours... Too many channels open and it was scrolled below the window.)
#upstart 2013-07-02
<jodh> xnox: could you take a look at https://code.launchpad.net/~jamesodhunt/upstart/fix-libupstart/+merge/172371 when you're about?
<Pyretic> hi, i tried creating a simple upstart job, but start/stop is hanging, now i tried every form of expect (none/fork/daemon) but that doesn't help, anyone know where to look ?
<Pyretic> script looks like this: http://pastebin.com/xKfeqbZ5
<jodh> Pyretic: /usr/share/... for a binary? Have you read the extremely important section in the cookbook on expect? http://upstart.ubuntu.com/cookbook/#expect
<Pyretic> yes, i've read it also from the strace it actuallly forks more then two times
<Pyretic> that's why all i tried all expect forms, but no luck, the pid is different each time
<jodh> Pyretic: this must be ruby-specific behaviour then: no daemon needs to fork >2 times. I'd look to see if it is possible to run this service in the foreground somehow and then remove 'expect'. Otherwise, make the "final" forked process call SIGSTOP and specify "expect stop".
<jodh> Pyretic: seems that foreman can auto-generate upstart jobs (?): http://michaelvanrooijen.com/articles/2011/06/08-managing-and-monitoring-your-ruby-application-with-foreman-and-upstart/
<Pyretic> lol yes, bit of a naming confusion there
<Pyretic> foreman: http://ddollar.github.io/foreman/ vs theforeman http://theforeman.org/ :)
<jodh> Pyretic: :)
<jodh> xnox/slangasek: please could one of you review https://code.launchpad.net/~jamesodhunt/upstart/fix-libupstart/+merge/172371
<xnox> =)
 * jodh wanders off to print out the automake manual, pin it to a wall and shoot at it...
<slangasek> xnox: do you have this, or do you need me to review?
<slangasek> jodh: aim for the conditionals
<jodh> slangasek: :) if you know the magic incantation to remove those multiple mkdirs, pleeeeease do let me know :)
<xnox> slangasek: i have been reviewing it. it's straightforward sans automake.
<Pyretic> jodh: i disabled the daemon setting, works now thanks :)
<jodh> Pyretic: great.
<xnox> jodh: distcheck failed for me.....
<jodh> xnox: same problem with upstart/ missing?
<jodh> xnox: about? or are you busy shooting at walls too?
<xnox> jodh: no, it's shared/static linking problem this time around.
<jodh> xnox: can you send me details? I've just tested with a pristine checkout and all works as expected.
<xnox> hm....
<slangasek> xnox: can I suggest punting on libupstart for the initial 1.9 upload?
<xnox> slangasek: yeah, best to upload, we can add it later.
<slangasek> xnox: is the branch currently in a state that it can be uploaded, then - and would you mind uploading?
<xnox> slangasek: will double check and upload after dinner =)
<slangasek> xnox: ok, thanks :)
<xnox> slangasek: uploaded.
<slangasek> xnox: cheers :)
<xnox> how british, sir. I like that =)
#upstart 2013-07-03
<bittu2> how to determine difference between single user mode and run level 1?
<bittu2> i'm using centos 6 and i'm trying to see if there is an actual difference between the levels
<xnox> bittu2: i'm not familiar with centos 6, but as far as I know by default it only uses init.d scripts. You can inspect those to see if there is any difference. I would not have thought there would be.
<xnox> elmo: upstart 1.9-0ubuntu1 is in saucy. If you are after upstart apparmor support, you might need apparmor/kernel from saucy
<jodh> xnox: thanks for doing the upload!
<jodh> xnox: ...speaking of which, could I bug you about the procenv one? :)
<elmo> xnox: no, I'm after the dbus bridge; thanks for letting me know
<xnox> elmo: than straight backport should be enough =)
<jodh> xnox: lp:~jamesodhunt/upstart/fix-libupstart updated.
<xnox> jodh: win! =)
<xnox> we should have done that long time ago anyway.... was on the back of my todo list =)
<jodh> xnox: yeah, I'd like to understand exactly what's different on 64-bit systems though.
<neomantra> hi, i am running on headless a Ubuntu cloud image (Raring with upstart 1.8) and want to use upstart session jobs.   I don't think I'm set up properly for this as I get this error in response to `initctl --user start mjob`:
<neomantra> "initctl: UPSTART_SESSION isn't set in the environment. Unable to locate the Upstart instance."
<xnox> jodh: ^
<xnox> jodh: do we spawn user sessions on servers at all yet?
<xnox> and how to do that?
<jodh> xnox / neomantra: we don't really support console login environments yet.
<jodh> neomantra: you could arrange for the system upstart to start a session init as your user, then "join" that session using something like 'export UPSTART_SESSION=`initctl list|awk '{print $2}'` before running 'start $job', but that assumes there is only 1 session init instance running for the user.
<neomantra> thanks for the responses.    ah, using upstart to start the "user upstart" it makes sense
<neomantra> my intention is to have services run as a user on cloud servers.    should i not be using upstart for this?  i'm revamping my infrastructure and thought i'd use it instead of start-stop-daemon
<xnox> neomantra: if setuid/setgid stanzas are enough, just add system jobs.
<xnox> neomantra: traditionally, userids that run webapps/etal shouldn't have login accounts / shell access at all =)
<xnox> neomantra: such that those jobs are executed as non-priviledged users.
<neomantra> xnox: that's a good point.    but i want users to be able to push configuration and then start/stop jobs...   but not do anything privileged
<neomantra> their jobs
<xnox> neomantra: for that case, user session / jobs sounds nicer.
<neomantra> so i have system upstart starting the "init --user"  with setuid/gid as my user.    still need the upstart session variable.   the "initctl list|awk" doesn't seem to work
<elmo> hmm
<elmo> configure.ac:11: option `serial-tests' not recognized
<elmo> autoreconf: automake failed with exit status: 1
<elmo> ah, looks like I need saucy automake ; will file a bug about build-depends
<xnox> elmo: or you can remove "serial-tests", introduced in automake1.12. we are in discussion with automake upstream about the whole test issues.
<xnox> elmo: i don't think in upstream we have "serial-tests" specified, due to resulting in higher automake dependancy.
#upstart 2013-07-04
<jscott1989> hey, I have an upstart script with "exec /home/astro/clyde/run-server.sh" (running that manually results in the server running) - when i run "service clyde start" or "service clyde stop" nothing gets returned and I have to CTRL+C to stop it - and after starting the service the server isn't accessible  - where would I start debugging this?
<jodh> jscott1989: is this a system job in /etc/init/ ?
<jscott1989> yeah
<jodh> jscott1989: most likely cause then is that your server script is expecting variables like "$HOME" to be set - a system job is really designed for running daemons which only require a minimal environment.
<jscott1989> http://pastebin.com/cdGQNv1K this is my run-server.sh
<jscott1989> i don't think that expects anything?
<jodh> jscott1989: I'm afraid I have no idea what your job requires.
<jscott1989> is there any way to get upstart to tell me the errors or anything?
<jscott1989> as right now when i type "service start clyde" it just hangs
<jscott1989> service clyde start*
<jodh> jscott1989: if you're running on a modern version of ubuntu, install the procenv package and run that in your normal loging environment and compare the output to when you run it from an upstart job to see the differences.
<jodh> jscott1989: cat /var/log/upstart/your-job.log
<jscott1989> thanks I'll do that
<jodh> jscott1989: see http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in and http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job.
<jodh> jscott1989: when you install procenv, you can change your job to run "exec procenv --file=/tmp/procenv.log --exec -- /home/astro/clyde/run-server.sh"
<jodh> jscott1989: which will run procenv and have it re-exec itself as your server
<jscott1989> I'll try those suggestions, thanks jodh 
<jscott1989> hmm, putting procenv in there doesn't even create the log file
<jscott1989> okay that was really strange
<jscott1989> i created a new file clyde2.conf and put "exec /home/astro/clyde/run-server.sh" and it worked fine :/ must be a permission problem on the first file i guess
<jscott1989> hmmâ¦ if I remove clyde.conf and rename clyde2.conf to clyde.conf i have the same errorâ¦ must be something to do with a log file or something??
<jodh> jscott1989: does your upstart job specify 'expect'?
<jscott1989> no
* jodh changed the topic of #upstart to: Upstart 1.9.1 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
#upstart 2014-07-01
<preyalone> Why does my Node server silently fail when daemonized with Upstart? https://github.com/mcandre/node-ios7crypt/blob/master/upstart.conf
<bbasic> Hey friends
<preyalone> Ah, it was a problem with relative paths in the Node.js code
<bbasic> I'm having problems with node.js and upstart as well....
<bbasic> I can get it to start but I cannot get it to run on restart
<bbasic> does anyone have any experience running node processes via upstart?
<bbasic> works manually start and stop
<xnox> jodh: i'm trying to fix the test-suite after adding correct pipe shrinkage and preventing close handler from double freeing the io
<xnox> jodh: however i'm noticing very odd things.
<xnox> jodh: for example: exec of a main process "/this/command/does/not/exist" in the child handler raises status 255, 13, 1 (in order of decreasing frequency)
<xnox> am i receiving and catching some unrelated events and some such? 
 * xnox ponders if i should only monitor chld exited....
<jodh> xnox: are you only running that specific test? If not, I'd comment the rest out. Also, where's the latest branch? :-)
<xnox> jodh: just locally at the moment. let me push it.
<xnox> jodh: hm, in the child handler Is it actual exit status, or does one need to call WEXITSTATUS on it?!
<jodh> xnox: yeah, you will if the child exited normally. Look at NihChildHandler in nih/child.h which documents exactly what status means (depends on NihChildEvents).
<xnox> jodh: https://code.launchpad.net/~xnox/upstart/shrink-notifications just the top level commit on top of lp:upstart
<jodh> xnox: ta
<xnox> test suite hangs at the moment. E.g. after exiting the mainloop, the log is not written / flushed for not ok 49 - with single-line command running an invalid command, then a 2-line post-stop script
<xnox> 	wrong value for stat (filename, &statbuf), expected 0 got -1
<xnox> 	at tests/test_job_process.c:3270 (test_start).
<xnox> not ok 49 - with single-line command running an invalid command, then a 2-line post-stop script
<xnox> 	wrong value for stat (filename, &statbuf), expected 0 got -1
<xnox> 	at tests/test_job_process.c:3270 (test_start).
<xnox> in the test_job_process
<xnox> jodh: i'm trying to use the minimalistically simple main-loop exitor, out of all the editions i could find. Or is/was there branch and or commits from you where those tests were already adjusted to use main-loop without a lot of debug nih message codes?
<xnox> when i went looking through your branches again, i didn't find such.
<jodh> xnox: lp:~jamesodhunt/upstart/async-spawn.WIP is the latest wrt main loop tests.
<jodh> xnox: I'd be tempted to pull in more of my test_job_process.c changes (I'm thinking of TEST_RESET_MAIN_LOOP() specifically so that you know each test will get a clean env).
<xnox> jodh: yeah, working on disecting that now, given that it does pass further than my current shrinkage branch
<jodh> xnox: ack.
<alexbligh1> Is there a way to see what jobs upstarts *thinks* is running? I'm trying to work out why on Ubuntu 14.04 'service udevtrigger start' (which is a task) says that the job is already running
<xnox> alexbligh1: $ sudo initctl list ?
<alexbligh1> xnox, that's what I was missing, thanks. What does it mean if a task is "udevtrigger start/starting"
<alexbligh1> Surely a task, by the nature of a task, should be short lived?
<alexbligh1> (and no it's not doing anything)
<xnox> alexbligh1: start/starting means the "start on" conditions are satisfied, however there are other jobs that are blocking udevtrigger from running.
<xnox> alexbligh1: e.g. jobs that are "start on starting udevtrigger" that are blocking
<xnox> alexbligh1: udevtrigger is typically run only once very early in the boot, and one wouldn't need to add any other custom jobs there.
<xnox> alexbligh1: can you pastebin $ sudo initctl show-config ?
<alexbligh1> xnox, yeah I am having an issue where on my debootstrapped trusty, /dev/net/tun is not being created
<alexbligh1> xnox, initctl show-config : http://pastebin.com/pQdSCmYn
<alexbligh1> xnox, initctl list : http://pastebin.com/AAthU77A
<alexbligh1> xnox, the only thing "start on starting udevtrigger" I can see is udev-monitor, and that is start/running
<alexbligh1> xnox, I think I've found the problem. trusty udev is unhappy if /dev is not devtmpfs, but just a normal directory in my (ram) root filingsystem. Is that intentional? It's bizarrely difficult to work around as you can't mount both /dev and /dev/pts from /etc/fstab as no directory /dev/pts exists to mount on in devfs.
#upstart 2014-07-02
<jpentland> Hi, I tired placing a new .conf file in /etc/init but it seems that it isn't being recognised as a service, what could be the reason for this?
<jodh> jpentland: http://upstart.ubuntu.com/cookbook/#init-checkconf
<zlin> on ubuntu 12.04 is there a way to make upstart interpret an init script as a native upstart job, rather than as a shell script?
<bjrohan> Hi. I an trying to run a script to start a minecraft server in screen. It appears to me that screen is not starting before I call it in upstart. How may I make sure screen is started before it is needed in my script? Currently I have start on (screen and runlevel [2345]) which doesn't appear to work
<cschneid> I have a status of: `spark-master stop/killed, process 18321` -- how do I really kill it? that process doesn't exist
<bjrohan_> Hello
<bjrohan> can anyone help me get a n upstart script to be able to run screen before I run the script? I am having issues getting this to happen
#upstart 2014-07-03
<Ozux> Do it need to restart after changing service.conf file ? or is there any way to reload the configs in upstart?
#upstart 2014-07-04
<xnox> Ozux: changes are picked up automatically, using inotify.
<xnox> Ozux: there is also $ initctl reload-configuration to ask upstart to re-read all jobs.
<xnox> Ozux: however note that changes will only take effect for newly started jobs. E.g. if service was running, you'd need to do a full "stop" and then "start" for new config to be used.
<xnox> Ozux: simply doing "restart" will continue to use previous config (the one that the job was originally started with)
#upstart 2016-07-07
<hallyn> so who's working on socket activation in a forked upstart? :)
<hallyn> (as near as i can tell it is the only *reliable* generic way to do dependencies - i.e. "when libvirt is ready do x")
#upstart 2016-07-08
<exac> hey guys
#upstart 2017-07-05
<l2y> what is the official way to detect whether a distro is running upstart? like the existence of some file or directory under /run
<hallyn> l2y: well you can do a lsof -U | grep /com/ubuntu/upstart
#upstart 2017-07-06
<l2y> hallyn: I ended up matching for "upstart" in the output of "initctl --version"
<l2y> can one stop multiple services at once on upstart? like `service one two three stop`
<hallyn> don't think so, not according to manpages
#upstart 2018-07-04
<pingwindyktator> Hello. Im trying to understand one upstart-related thing - I've got respawn stanza included in conf file and my exec looks like exec sudo -u some_user ...
<pingwindyktator> When Im killing this job (sudo kill pid), it does not respawns
<pingwindyktator> the solution is to replace exec ... with export HOME="/root" && exec ...
<pingwindyktator> why is that?
