#upstart 2007-04-09
<rawler> heya ppl..
<rawler> i'm having a small issue, perhaps someone cold clarify a thing or two to me?
<rawler> I've written a small startup-script that enables a vpn-connection and sets up a bridge as soon as internet-connection is up..
<rawler> however, when starting the service, the "start openvpn-dtvb" command hangs bootup until ctrl+c is pressed?
<rawler> does anyone know anything about this?
<rawler> http://pastebin.se/13022 <- the service-definition.. i can't figure what would block the startup..
<rawler> the service runs fine, btw.. the only problem is that I have to press ctrl+c to boot, which is a bit confusing.. ;) 
<_ion> I don't immediately see what causes the problem, but on an unrelated note, what does Canal Digital have to do with a VPN? :-)
<_ion> That is, for what purpose do they provide it?
<rawler> _ion: we don't.. ;) I work there, we use it for internal purposes.. :)
<rawler> _ion: found the trouble myself.. I had to define it as a service  (adding a line "service")
<rawler> perhaps something that should be added to the FAQ? I could not find it in the documentation, but while browsing through gmane I found a similar problem..
<rawler> _ion: I see you're from Finland?
<rawler> btw, forgot the ordinary, "great job".. really, great job with upstart.. :) kick-ass init-solution..
<rawler> when I first read about upstart I thought event-based seemed like a stupid idea, and were going for deps-based instead, but after working with it a little, as well as seeing the bigger picture, it's a killer.. :)
<rawler> just the basic solution of beeing capable of things like triggering services based on particular interface-events is great..
<rawler> I can hardly wait for Feisty to get out, so that work on full integration for Feisty+1 can begin.. :)
<Yorokobi> Is upstart's /sbin/init SELinux capable/compatible or should I use sysvinit for SELinux? (OS: Kubuntu Edgy, upstart ver: 0.2.7-7)
<_ion> rawler: Yeah, i'm from Finland. And d'oh, i should have realized the "service" stanza is needed. :-)
<rawler> hehe.. it weren't when I wrote the service, about a year ago.. :)
<rawler> _ion: btw, what's your role in Roundup?
<_ion> Roundup?
<AlexExtreme> it's needed now after the JobsAsStates specification is implementaed afaik
<AlexExtreme> *implemented
* AlexExtreme hates this keyboard...
<_ion> yorokobi: I think there has been some discussion about SELinux on the mailing list, but i haven't paid much attention to it.
<_ion> yorokobi: Perhaps you'll find the answer from the archives.
<Yorokobi> _ion, yeah, I read through it
<Yorokobi> it looks like its still a work in progress
<rawler> _ion: sorry.. Upstart.. doing a little too much at the same time now.. ;)
<_ion> rawler: Keybuk is the one who has done all the actual work. I'm mostly just an enthusiastic observer, trying to get an useful patch done every once in a while.
<rawler> allright.. :)
<rawler> just curious.. :)
#upstart 2007-04-10
<AlexExtreme> hmm, in ubuntu, does usplash get started by the initramfs or is it started by the init scripts?
<_ion> It's started ASAP from initramfs.
<AlexExtreme> thought so
<AlexExtreme> btw _ion, did you get anywhere with your event based mounting ideas?
<_ion> I haven't yet got around to implementing any of that.
<AlexExtreme> k
* Starting logfile irclogs/upstart.log
* Starting logfile irclogs/upstart.log
<mbiebl> Keybuk: hi
<Keybuk> hey
<mbiebl> I noticed when I symlink an upstart job file into /etc/event.d, upstart does not recognize when the file is changed.
<Keybuk> right
<mbiebl> Is that a limitation of inotify?
<Keybuk> or a feature
<Keybuk> more a filesystem limitation
<Keybuk> since when changing a file, one would have to search the entire disk for symlinks to it, in order to update their directory entries
<mbiebl> why that?
<Keybuk> because the alternative would be every time you make a symlink, storing a back link somewhere in the linked-to file's inode
<Keybuk> and that simply doesn't work with relative symlinks ;)
<Keybuk> since they can be on filesystems that can be mounted anywhere
<Keybuk> thus refer to different paths
<Keybuk> (not to mention that it wouldn't work with cross-filesystem symlinks)
<mbiebl> Hm, maybe I don't get it. If /etc/event.d/foo is a symlink to /lib/upstart/foo, why would you have to store a back link?
<Md> the solution would be to use inotify on each symlink in the directory. may or may not be worth the effort (see the debian-devel thread about udev and the same problem)
<Keybuk> because upstart watches /etc/event.d for changes
<Keybuk> and changing /lib/upstart/foo doesn't change that directory
<Keybuk> it changes the /lib/upstart directory
<Keybuk> and there's nothing there telling the filesystem that there's a symlink in the /etc/event.d directory and you might want to touch that too
<Keybuk> personally I think it's a feature, since it means you can have a set of files that are explicitly *not* watched
<mbiebl> I guess, you're right
#upstart 2007-04-11
<costinel> md, ayt ?
#upstart 2007-04-12
<_ion> Much of network-manager's functionality could be moved to upstart jobs. For instance, the job that responds to network-interface-added $ifname could ifup a wired interface immediately if it doesn't support media sense, but wait for network-cable-connected $ifname instead if it does.
<AlexExtreme> what would emit network-cable-connected though?
<Keybuk> HAL
<AlexExtreme> hmm
<AlexExtreme> good point :)
* AlexExtreme didn't think of that
<AlexExtreme> hmm
<AlexExtreme> I still need a way of disabling services... does anyone have any ideas for that?
#upstart 2007-04-15
<AlexExtreme> heh
<AlexExtreme> the initng guys are copying the event functionality from upstart...
<AlexExtreme> also the fedora guys don't seem to be getting a new init in for FC7
<_ion> The concept or the code?
<AlexExtreme> the concept
<AlexExtreme> http://fedoraproject.org/wiki/FWN/Issue82#head-05ece5b2bb5370378a065e738e3a0884e30d580f
<AlexExtreme> on one of the mailing list posts there an initng guy mentions that it is getting an event plugin
#upstart 2008-04-07
<warren> Any Ubuntu user here?  Fedora developer here wondering about how runlevels on Ubuntu behave.
<warren> On Fedora we have runlevels like:
<warren> 1 - single user mode
<warren> 3 - network with text login
<warren> 5 - network with X
<warren> 6 - reboot
<warren> We can use "init X" where X is a number to switch between them
<warren> Does Ubuntu behave anything like this?
<Keybuk> warren: Ubuntu's runlevels are the same as Debian's
<Keybuk> we have S and 0 thru 6
<Keybuk> where 0 and 6 are special (halt and reboot)
<Keybuk> 1 is used for switching to S (single user)
<Keybuk> 2 thru 5 are up to the user to define
<Keybuk> with 2 as the default
<warren> Keybuk: do you understand the /etc/event.d/ file format?
<Keybuk> sometimes
<warren> for example:
<warren> /etc/event.d/rc3:
<warren> start on runlevel 3
<warren> stop on runlevel
<Keybuk> right...?
<warren> what does it mean if you have no number on "stop on runlevel"?
<Keybuk> runlevel is an event
<Keybuk> 3 is an argument to that event
<Keybuk> the runlevel event means that the runlevel has changed
<Keybuk> it gets the new runlevel as an argument
<Keybuk> so "on runlevel 3" means "when the runlevel is changed to 3"
<Keybuk> "on runlevel" just means "when the runlevel is changed"
<Keybuk> (ie. to any runlevel)
<warren> hm
<warren> stuff in /etc/event.d are events as well?
<Keybuk> no
<Keybuk> they are jobs
<warren> another event.d file has:
<warren> start on stopped rc5
<warren> where are the "start on foo" things documented?
<Keybuk> right
<Keybuk> stopped is the event, it means that a job has stopped
<Keybuk> it gets the job name as an argument
<Keybuk> so that means start this job when the rc5 job is stopped
<Keybuk> the rc5 job probably runs the /etc/rc5.d (or /etc/init.d/rc5.d on "strange distros" :p) directory
<Keybuk> the events are limitless
<Keybuk> start on bangbangwibblewheresmypopsicle
<Keybuk> is valid
<Keybuk> something just needs to call initctl emit bangbangwibblewheresmypopsicle somewhere
<warren> oh crap.  I have to work on a bigger bug. brb.
<warren> ok, back now.
<brendan_> Keybuk: is there a way to emit runlevel 2 apart from using the sysv compat runlevel command?
<brendan_> like "initctl emit runlevel 2"?
<brendan_> are events allowed to have spaces like that?
<Keybuk> brendan_: exactly like that
<brendan_> Keybuk: great! thanks
<Keybuk> there's no space
<Keybuk> you're separating an event name and its argument there
<warren> Keybuk: our /etc/event.d/rc5 http://fpaste.org/paste/1656
<warren> Keybuk: it seems that we're setting runlevel 5 in this job
<Keybuk> warren: looks the same as the demo one?
<warren> ok...
<warren> i'm just trying to better understand what's going on
<Keybuk> "runlevel --set" stores the runlevel in utmp
<warren> Keybuk: we're trying to deal with a few upstart bugs
<warren> Keybuk: like ... during shutdown you don't see anything
<Keybuk> do you have "console output" in the rc6 job?
<warren> yes
<Keybuk> are you running anything that might change /dev/console ?
<warren> change in what way?
<Keybuk> e.g. usplash, X, rhgb, bootlogd, etc. ?
<Keybuk> redirect
<Keybuk> a common issue is if you run shutdown -h now while under X, the output will go to VT 7
<warren> not that I'm aware of
<warren> so if I switch to VT7 during shutdown I should be able to chdeck
<warren> check
<Keybuk> right
<warren> ah, you're right!
<warren> redirected to VT7
<warren> Keybuk: here are all of our reported upstart bugs
<warren> Keybuk: http://tinyurl.com/4w8cdr
<warren> Any ideas about these two? https://bugzilla.redhat.com/show_bug.cgi?id=441339 and https://bugzilla.redhat.com/show_bug.cgi?id=438444 
<Keybuk> back
<Keybuk> sorry, was taking an exam there ;)
<Keybuk> warren: 441339: is that not the case with sysvinit?
<Keybuk> 438444: that may be a difference in the way that runlevels work in Fedora and Ubuntu?
<Keybuk> in Ubuntu, rc 1 will run /etc/rc1.d which contains a K script for everything in rc2-5
<Keybuk> and then finally will run telinit S to switch to S (single-user-mode)
<Keybuk> maybe Fedora has those two completely backwards?
#upstart 2008-04-08
<warren> Keybuk: yes 441339 is true in sysvinit
 * warren checks for K* scripts
<warren> /etc/rc.d/rc1.d has K scripts of everything
<sadmac2> Keybuk: So, we want to add telinit u functionality to upstart
<sadmac2> Keybuk: we can do it the quick way, just make telinit u kill -TERM 1, or we can add an upstart message
<Keybuk> right
<sadmac2> We're currently looking at the latter. Which would you expect is preferable?
<Keybuk> latter is harder
<sadmac2> true, but its not that hard
<Keybuk> though obviously more forwards portable since in 0.5 it would be a dbus command anyway
<sadmac2> does doing it as a message make it more forwards portable? I would assume less since all that messaging stuff is getting replaced with dbus
<Keybuk> right
<Keybuk> but at least it would be ideologically the same
<sadmac2> so 0.5 won't handle TERM?
<Keybuk> it might
<Keybuk> but that obviously won't be the preferred way to do it
<Keybuk> since it doesn't fail well if init is /bin/bash ;)
<sadmac2> true
<sadmac2> Keybuk: so within init, should I a) move term-handler so its somewhere I can call it. b) copy the restarting code from term_handler. c) selfTERM?
<Keybuk> self term is probably easier ;)
<sadmac2> yes it is.
<sadmac2> gaaah!
<sadmac2> Apr  8 12:21:24 foucault init: control.c:364: Assertion failed in control_version_query: type == UPSTART_VERSION_QUERY
<sadmac2> I ALREADY FIXED THAT ASSERTION!
<sadmac2> why? why won't the problem go away when I fix it?
<sadmac2> ... or maybe that just isn't the line I thought it was...
<Keybuk> lol
<Keybuk> assert() is your friend
<ion_> Assertion bugs are the easiest to fix, just remove the assert() call. :-P
<Keybuk> that's like saying that gout is easy to fix, just remove the leg
<ion_> \\oo/ â Zaphod
#upstart 2008-04-09
<ktk> hi all
<ktk> short q: what would be the correct way to start a service as another user with upstart? I tried this:
<ktk> exec su - vbox -c "svscan /home/vbox/services"
<ktk> but that creates three processes: 
<ktk> --
<ktk> vbox      4099  0.0  0.1   2672  1068 ?        Ss   13:56   0:00 su - vbox -c svscan /home/vbox/services
<ktk> vbox      4179  0.0  0.0   1752   508 ?        S    13:56   0:00 -su -c svscan /home/vbox/services
<ktk> vbox      4185  0.0  0.0   1708   380 ?        S    13:56   0:00 svscan /home/vbox/services
<ktk> --
<ktk> couldn't find hints in the docs so far
<ion_> How about if you scrap the - and use -c 'exec svscan ...'? (Just guessing here)
<ktk> well if I run it by hand I need the - for switching to the correct environment of the user
<Keybuk> not sure why su adds another child there
<ktk> well the last pid makes sense
<ktk> the other two not IMHO
<Keybuk> exec su -c "exec svscan /home/vbox/services" - vbox
<Keybuk> is the usual way
<ktk> letme try that
<ktk> ok now I could get rid of one process :)
<ktk> looks like this now:
<ktk> --
<ktk> vbox      4031  0.0  0.1   2668  1064 ?        Ss   15:26   0:00 su -c exec svscan /home/vbox/services - vbox
<ktk> vbox      4105  0.0  0.0   1708   380 ?        S    15:26   0:00 svscan /home/vbox/services
<ktk> --
<ktk> but 4031 still should not stay like this 
<Keybuk> are you sure that the 4105 isn't a fork by svscan
<ktk> good question, letme try that by hand again
<ktk> doesn't seem to fork like this
<ktk> so I am pretty sure that's not svscan
<ktk> hmm su seems to do that
<ktk> but I don't see why
<Keybuk> who knows
<Keybuk> tried without the "-" ?
<ktk> will try moment
<Keybuk> it might be because upstart processes are session leaders
<Keybuk> so su makes a new session
<Keybuk> you need to fork to do that
<Keybuk> odd that it keeps the old one around though
<Keybuk> normally the parent would exit
<ktk> nope that seems to cause more problems without the - 
<ktk> then I get even more
<ktk> couldn't find any other example of a process that should run under a different user
<ktk> anyone got an example how apache would be started like this?
<ktk> for example
<Keybuk> usually they do it themselves
<ktk> hmm ok
<brendan_> Keybuk: is running event.d scripts as different users on the roadmap?
<Keybuk> eventually
<Keybuk> there's a small parcel of issues and decisions there though
<Keybuk> e.g. what does "run as a different user" actually mean
<Keybuk> it can mean setuid(), it can mean setuid() and initgroups(), it can mean a full PAM session, it can mean ConsoleKit registration and it can mean a session environment including such things as D-Bus, etc.
<Keybuk> also there's the permission aspect
<Keybuk> e.g. if I jobs are run as my user, should my user have permission to stop and start them?
<Keybuk> therefore if I emit an event, are only my jobs started by it?
<brendan_> complex, indeed
<brendan_> keybuk: as an aside, we're running upstart inside xen virtual domains and it works great for that purpose. especially so since the virtual domains are treated like a service - having init be able to handle respawning of things is a huge help
<brendan_> we're loving upstart :)
<Keybuk> cool
<sadmac2> Keybuk: how's dbus support comming?
<Keybuk> sadmac2: haven't done much on it recently
<sadmac2> Keybuk: ah.
<Keybuk> ENOTIME
<sadmac2> Keybuk: as soon as that and profiling/flags appears in some form in upstart I'm going to want to build trunk in rawhide so we can gear up for F10.
<sadmac2> (F9 is in final release freeze now)
<Keybuk> *nods*
<Keybuk> once my Meteorology exam is out of the way, I'll probably have more spare time again ;)
<Keybuk> though then I should really concentrate on Navigation
<Keybuk> still aiming for a May release of 0.5 though
<sadmac2> May is good
<sadmac2> still waiting to hear about whether they're sending us to the con.
<sadmac2> Keybuk: https://bugzilla.redhat.com/show_bug.cgi?id=439699
<sadmac2> ^^I'm a bit stumped by this one.
<jdong> Keybuk: cool, you study meteorology?
#upstart 2008-04-10
<Keybuk> jdong: it's one of the exams you have to pass for a PPL
<Keybuk> sadmac2: the reporter was on here, the messages will be on VT 7 because X moves /dev/console there while it's running
<Keybuk> sadmac2: sysvinit always behaved exactly the same
<jdong> Keybuk: so it determines weather or not you get your license?
<jdong> (haha sorry that was horrible!)
<Keybuk> lol
<Keybuk> knowing not to fly straight into a thunderstorm comes in handy
<Keybuk> since flying into one generally means not flying out again
<jdong> Keybuk: I thought it was those granite clouds that pilots hate the most :)
<Keybuk> ah yes, cumulus granitus
#upstart 2008-04-11
<Keybuk> hurrah
<Keybuk> after 4 hours of fiddling, I'm now back to being able to make a change :p
<Keybuk> http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb?start_revid=scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb
<Keybuk> \o/
<Keybuk> and with the following revision, we now support respawn and task :)
<Keybuk> task
<Keybuk> exec /some/script
<Keybuk> respawn
<Keybuk> will repeat /some/script until it exits with zero :)
<ion_> keybuk: Nice
<Keybuk> My main blocker at the moment is deciding whether or not to export the difference between Jobs and Instances over D-Bus
<Keybuk> and if not, which way to err
<Keybuk> ie.
<Keybuk> should it have a D-Bus object per job
<Keybuk> should it have a D-Bus object per instance
<Keybuk> or should it have D-Bus objects for both?
<Keybuk> per job would mean you had .../jobs/getty with Start() and Stop() methods, and methods to probe for instance and process information
<Keybuk> per instance would mean you had .../jobs/getty-tty1 with a Stop() method; and a Start(name) method on the upstart object
<Keybuk> both would mean you had .../jobs/getty with Start() and StopAll() methods, then .../jobs/getty/tty1 with a Stop() method and methods to probe process information
<ion_> Iâd lean towards the latter, and .../jobs/getty would provide a method to find a list of .../jobs/getty-tty1 etc.
<ion_> My thinking tends to favor object-orientation.
<Keybuk> the only real problem with the latter I guess is the overhead in terms of D-Bus objects
<Keybuk> Job.Start(Array of String env)
<Keybuk> job.GetInstance(Array of String env)
<Keybuk> job.GetInstanceByName(String name)
<Keybuk> something like that?
<ion_> But is that overhead really that big?
<Keybuk> maybe not I guess
<Keybuk> Job.Start(Array of String env) => (Object Path instance)
<Keybuk> Job.GetInstanceByName(String name)
<Keybuk> Job.GetInstanceByEnv(Array of String env)
<Keybuk> (all => instance)
<Keybuk> Job.StopAll(Array of String env)
<Keybuk> Instance.Stop(Array of String env)
<Keybuk> Instance.Restart()
<ion_> Looks nice.
<Keybuk> Manager.GetJobByName(String name)
<Keybuk> I guess that'd mean I could throw away instance ids :p
<Keybuk> UPSTART_JOB=getty
<Keybuk> UPSTART_INSTANCE=tty1
<Keybuk> would be enough :p
<ion_> How would that go currently?
<Keybuk> right how you'd have
<Keybuk> UPSTART_JOB=getty
<Keybuk> UPSTART_JOB_ID=3721
<Keybuk> where initctl would only use the latter
<Keybuk> if I dropped ids, initctl would use both
<Keybuk> Manager.GetJobByName($UPSTART_JOB).GetInstanceByName($UPSTART_INSTANCE).Stop() :p
<ion_> Nice
<Keybuk> "start" would become an error in a job
<Keybuk> with "restart" being the right command
<Keybuk> ie.
<Keybuk> pre-stop script
<Keybuk>   [ ... ] || restart
<Keybuk> end script
<Keybuk> ?
<Keybuk> hmm
<Keybuk> maybe they should still be different
<Keybuk> start returns you to start without killing
<Keybuk> restart would kill, but return you back to start again
<ion_> Any use cases?
<Keybuk> just thinking of things being common senes
<Keybuk> there's a few obvious ones
<Keybuk> stop on stopping some-other-job
<Keybuk> pre-stop script
<Keybuk>   if can-carry-on-with-it-but-need-restart; then
<Keybuk>     restart
<Keybuk>   fi
<Keybuk>   if can-ignore-it-safely; then
<Keybuk>     start
<Keybuk>   fi
<Keybuk> end script
<ion_> Perhaps start should be named otherwise to avoid confusion, though.
<Keybuk> such as?
<ion_> I dunno. cancel-stop? :-P
<Keybuk> ion_: that'd mean a /usr/bin/cancel-stop? :p
<ion_> Well, it would, and that would suck. :-P
<Keybuk> heh
#upstart 2008-04-13
<jyujin> hey channel
<jyujin> would any of you guys happen to be mr. scott james remnant?
<jyujin> i was gonna try to get dave's proposal from last october back to life :D
<thom> jyujin: scott -> Keybuk 
<jyujin> thom: thanks
<jyujin> Keybuk: PING :)
<Keybuk> jyujin: hello
<jyujin> Keybuk: hey there. I was gonna try and ping the lot of us for that bootstrap programme meeting kinda thingy that dave (zarzycki, from launchd) proposed last october, since i kinda liked the idea but never heard of anything actually coming of it.
<jyujin> roy (marples, openrc) would tag along too, and i was trying to talk ismaell from initng into it as well
<jyujin> oh yeah, excuse my manners, i'm magnus from einit
<Keybuk> *nods*
<Keybuk> where/when were you thinking of holding it?
<jyujin> heh, thats the tricky thing. i'm pretty sure we're all quite scattered around the place, but i was thinking that coming together in some irc channel would be a good start, wouldnt it? i was hoping we could get something arranged this month on a weekend maybe
<jyujin> that way none of us needs to make any travel arrangements and we could probably still work out some commonalities that we should all stick to ;)
<Keybuk> weekends are normally bad for me
<jyujin> heh, i assumed as much judging from the time you came online today :)
<Keybuk> Linux stuff is my day job, so I tend to be around 1000-2000 UTC weekdays
<jyujin> heh, medical image analysis here, and my boss doesn't really appreciate me hanging out on irc, but i'm sure i could arrange something... we could all just join a chan anyway couldnt we?
<jyujin> i'm sure we can find some time to sit together ;)
<Keybuk> yeah, I'm sure we'll find something
<jyujin> sweet... ill go reg a chan then. what about #bootstrap?
<Keybuk> #init ?
<jyujin> mhh seems to be some kind of freenode channel
<jyujin> #unix-init?
<jyujin> Keybuk: looks like ismaell likes the chan name as well ;)
#upstart 2009-04-06
<sadmac> Keybuk: around?
#upstart 2009-04-07
<sadmac> Keybuk: did you change any of that job class candidate stuff in light of the new memory management (beyond just making it use it. Did you change the design)?
#upstart 2009-04-08
<pwgen> hi want to get upstart 5.1 running but i have problem regarding oom adjustment can someone help ?
<pwgen> s/5.1/0.5.1/
<sadmac2> pwgen: is upstart crashing on start due to failing to set oom adjustment?
<pwgen> yes, maybe no proc mounted ? its says something about not rootfs .  0.3.8 is running ( distro Angstom on zaurus )
<sadmac2> pwgen: exactly. 0.5 requires proc to be mounted at boot (this is considered a bug, but it hasn't been fixed yet)
<pwgen> i want build upstart for openmoko and are developing it with an old c-1000 , my goal is to control runlevel scripts via dbus, 
<pwgen> should i use 0.3.8.instead  ?
<sadmac2> pwgen: you could mount /proc in the initrd, or possibly patch away the oom adjustment features if you don't need them
<sadmac2> you could also make an oom adjustment failure non-fatal
<pwgen> on an embedded device do   usually do not boot with an initrd so i think i have to patch it ..(:-((
<sadmac2> the change shouldn't be too hard.
<pwgen> thx  a lot seems to work .. are there special samples for 0.5.1 version out ?
<temoto> Hello. What's proper way to setuid/gid with upstart? Writing script stanza with su?
<temoto> How to run daemon as particular user?
#upstart 2009-04-10
<Keybuk> damn, no mbiebl
<sadmac> Keybuk: are you up early or late?
<Keybuk> I'm in SF
<sadmac> Keybuk: you only ever visit the interesting coast
<Keybuk> damn straight
<Keybuk> ion_: la la la, I can't hear you
<ion_> :-P
<Keybuk> did you read the diff? :)
<ion_> Nope. Iâll do that. :-)
<sadmac> Keybuk: you should come to NC sometime. We'll eat barbecue and sweet tea served by a pregnant 17 year old waitress with a wrist splint, and then we'll go to a monster truck rally.
<Keybuk> sadmac: that honestly sounds awesome!
 * Keybuk wants a monster truck
<ion_> Huh. irssi says âDCC no file offered by Keybukâ, but still shows the pending request.
<Keybuk> ion_: kooky
<sadmac> Keybuk: sadly they tend to do them in the new arena, which isn't really big enough for serious monster trucking. hopefully they'll do one in carter finley soon.
<ion_> Oh, it says that because it already began fetching the file â it just canât connect to your machine.
<Keybuk> damn firewalls
<Keybuk> anyway yes, update your udev
<Keybuk> no, REALLLY
<ion_> Yeah :-)
 * sadmac goes fooding
<Keybuk> sadmac: I should end up somewhere on the East Coast sometime
<sadmac> Keybuk: well, assuming I'm out of school we should run into eachother
<Keybuk> yeah, I do try and run into people
<ion_> When you visit Tampere, iâll buy you a beverage. :-)
#upstart 2009-04-12
<PovAddict> if I add my own upstart job, the command under "exec" will be run when the job starts; what does upstart do when the job is stopped?
<sadmac> PovAddict: kills the process that resulted from the exec
<PovAddict> SIGTERM?
<sadmac> I believe so
<PovAddict> can it be made to call a custom command on stop?
<sadmac> PovAddict: not sure if the current version can. You can make pre-stop do it, but I'm not sure if upstart will read it as a failure.
<PovAddict> are there hooks to make 'status' give service-specific information?
<sadmac> not at present
<PovAddict> to run a service as a different user do I just use 'su' in the exec, or is there specific support for that?
<sadmac> just use su
<PovAddict> what about cwd?
<sadmac> I want to say there's a stanza for that....
<PovAddict> heh, undocumented-dont-rely-on-it stanza?
<sadmac> same as all of them
<PovAddict> all of them? I'm sure you don't consider 'exec' undocumented and shouldn't be relied on! :)
<sadmac> PovAddict: chdir
<PovAddict> I don't want to use things that may break later; I guess I'll just use a 'script' with cd and su
<sadmac> PovAddict: upstream's philosophy (and by upstream I mean Keybuk) is that until 1.0, anything is subject to change
<sadmac> really. AN-E-THING
 * PovAddict >:o's at the lack of upstream config syntax highlighting in vim
<sadmac> why? 0.10 is going to have a different syntax anyway
<PovAddict> heh
<PovAddict> the current sysv scripts are set so it's killed on runlevels 0 1 6 and started on 2 3 4 5
<PovAddict> that's mapped to "stop on runlevel 0" etc, right?
<sadmac> stop on runlevel [016]
<PovAddict> note I have a relatively old version, 0.3.9 :$
<sadmac> that's what ships in ubuntu/fedora
<PovAddict> yep
<PovAddict> but since topic mentioned 0.5.1 *points*
<PovAddict> and I have an old Ubuntu, I thought maybe newer Ubuntu versions had newer upstart
<sadmac> I don't think any distro is planning to ship a 0.5 at any point. everyone's skipping to 0.10
<PovAddict> docs mention /etc/init/jobs.d
<PovAddict> /etc/init doesn't exist here, but I have stuff in /etc/event.d; should I put my job in there?
<PovAddict> is the code in the script supposed to fork and return? initctl start mythingy seems to be blocked, as if it was waiting for the script to terminate
<sadmac> no forking
<sadmac> and /etc/init/jobs.d is the 0.5 location
<PovAddict> I see
<PovAddict> any idea why my 'start' blocked?
<sadmac> do you have a 'service' or 'respawn' stanza?
<PovAddict> neither is mentioned in the documentation I'm reading :] so, no
 * PovAddict goes to the wiki
<PovAddict> http://upstart.ubuntu.com/wiki/Stanzas ok, so chdir *is* documented
<PovAddict> sort of :)
<PovAddict> adding 'service' worked \o/ thanks
<PovAddict> i love the fact that it reloads config instantly using inotify
#upstart 2010-04-12
<viric> Hello
<viric> Does anybody know of an upstart script for postfix?
<viric> well, a 'job configuration' I mean
#upstart 2010-04-13
<Nikratio> I have configured a job with "start on runlevel [2345] and net-device-up IFACE=eth0" and "stop on runlevel [!2345]", however, it is not started on normal system boot. Why not? eth0 is up and running. 
#upstart 2010-04-14
<Nikratio> Is there a way to ask the Karmic upstart *why* a particular job is not running/being started? If have configured a job with "start on (local-filesystems and net-device-up IFACE=eth0)" but I always have to start it manually...
#upstart 2011-04-11
<hsuh> i'm failing to set some environment variables in my pre-start ... i'm trying source /home/hsuh/.credentials but the variables aren't getting set
<hsuh> inside .credentials i got a couple "export"s
<hsuh> sourcing .credentials directly works for the current user, that is, sets the env variables...
<hsuh> since i exec my jar with sudo -u hsuh, i thought of doing something similar with source, but it  isn't recognized as a command, so i can't sudo
<SpamapS> haha.. yet another vi fail.. brought to you by modal editing, and the letter I
 * SpamapS loves finding "i" in his upstart job files now that we have init-checkconf
<ion> That *never* happens to me.
#upstart 2011-04-12
<semiosis> i'm working on writing an upstart job that will start a service after the network interface is up, but before remote filesystems are mounted.  or at least start the service after the network interface is up, then reattempt mounting of remote filesystems.  emitting remote-filesystems doesnt seem to have any effect on the _netdev entries in /etc/fstab.  any ideas?
<semiosis> this is on ubuntu maverick
<Keybuk> semiosis: a lot of that stuff is custom to Ubuntu
<semiosis> i'm sure it is.  any pointers?
<Keybuk> I've no idea, sorry
<Keybuk> I haven't been able to keep track of Ubuntu's fork so far
<semiosis> ok, thanks anyway.  i'm sure i'll figure something out :)
<SpamapS> semiosis: so you really need to block the mounting of remote filesystems, right?
<SpamapS> semiosis: sounds like you may need to block some of the 'mounting' events until your service is started.
<semiosis> SpamapS: not sure what i need, but i figured out that emitting a 'startup' event caused a retry of the mounts.  not sure what the other implications of that are though
<SpamapS> semiosis: emitting startup seems a bit bass-ackwards. ;)
<semiosis> SpamapS: yeah it does!
<semiosis> SpamapS: but mountall service goes away, so emitting a remote-filesystems (which would trigger the mountall-net job) does nothing at all
<SpamapS> semiosis: so what you want, I think, is start on mounting TYPE=nfs ...
<semiosis> SpamapS: actually it's glusterfs I'm working with, but it might be similar enough
<SpamapS> semiosis: mounting is a hook point, so mountall blocks on anything that uses that event...
<SpamapS> Ah gluster. Ok.. is mountall "gluster aware" ?
<semiosis> SpamapS: i dont know.
<SpamapS> seems its not
<SpamapS> so gluster will be treated like a local filesystem unless given the 'nobootwait' flag, I think.
 * SpamapS is still wrapping his head around mountall
<SpamapS> so tiny, but so twisted.. :)
<semiosis> SpamapS: basically, gluster service starts up & exports directories over the network (which could be eth0 or lo) then I have a client mount of the glusterfs volume in my fstab, which never gets mounted during bootup, unless i put 'mount -a' or similar in rc.local
<semiosis> SpamapS: hmm that woudl explain why _netdev didnt seem to make any difference.  in fact, nobootwait didnt seem to make any difference either
<SpamapS> semiosis: right, you might just try adding  _netdev=eth0 to the options
<SpamapS> err
<SpamapS> just _netdev
<SpamapS> semiosis: no _netdev should make it a "remote" filesystem
<SpamapS> semiosis: so you're saying in order for gluster to be able to mount a remote fs, it needs a service, right?
<semiosis> SpamapS: not at all
<SpamapS> Ok.. then thats very odd that _netdev didn't work
<semiosis> SpamapS: this host is a server and a client, in order for it to be a client of its own served volume, the service needs to be up
<SpamapS> semiosis: AHHH
<semiosis> SpamapS: so the server name here is localhost
<SpamapS> yeah so you *do* need it to start on mounting TYPE=glusterfs
<semiosis> SpamapS: hmm i was hoping this could be solved by adding an upstart job to my custom glusterfs package, but are you saying it requires changes to mountall?
<SpamapS> semiosis: you might just try a task that is 'start on mounting TYPE=glusterfs' that starts the service (exec /etc/init.d/glusterfs start)
<semiosis> SpamapS: ok then where does the mounting TYPE=glusterfs event get emitted?
<SpamapS> semiosis: by mountall, whenever it tries to mount glusterfs volumes
<semiosis> SpamapS: ooh neat
<SpamapS> and, importantly, it waits for that task to finish
<SpamapS> semiosis: you could also, of course, convert glusterfs to an upstart job completely.. which would improve boot speed and be super cool. ;)
<semiosis> SpamapS: thats what i'd like to do
<semiosis> SpamapS: and it shouldnt be too hard, the service is super easy to manage (it really manages itself, just needs a kick) i just need to figure out these events
<SpamapS> semiosis: the one tricky thing about mounting TYPE=glusterfs is you're going to see that event multiple times and sometimes the network won't be up... but don't be tempted to do 'and net-device-up' ;)
<semiosis> SpamapS: actually i was thinking 'or net-device-up'
<semiosis> SpamapS: but first things first
<SpamapS> see if you do 'or net-device-up' you may not block mounting TYPE=glusterfs
<SpamapS> unless you add  instance $UPSTART_EVENTS
<SpamapS> and even then I'm not sure if that will work
<semiosis> SpamapS: hmm no luck yet.  i've got a trivial upstart job to start glusterd, it has 'start on mounting TYPE=glusterfs' and 'exec /usr/sbin/glusterd -N -p /var/run/glusterd.pid' which will execute the daemon and have it stay in foreground (-N = no fork)
<semiosis> SpamapS: now this job does get run at boot, the service is up when I login, but the mount from fstab is still not mounted
<SpamapS> semiosis: one thing that may cause that to fail is that it will be considered "started" as soon as it execs glusterd ..
<SpamapS> semiosis: but it may not be ready to service things yet.
<semiosis> SpamapS: i also tried adding _netdev to the fstab but no effect
<SpamapS> semiosis: weird. I wonder if your glusterfs partitions are even being attempted on 'net-device-up'
<semiosis> SpamapS: well doing 'initctl emit -n startup' does mount the volume from fstab
<SpamapS> semiosis: but.. that seems a bit .. silly.
<SpamapS> semiosis: maybe just 'start mountall'
<SpamapS> but even that is counter intuitive
<semiosis> SpamapS: i know but as a test it suggests to me that the mount in fstab is being evaluated due to upstart events
<SpamapS> semiosis: boot with '--verbose' and see if the mounting event is even being emitted
<semiosis> SpamapS: the service does start up, and mounting is the only event in its 'start on' line
<semiosis> SpamapS: where do I add --verbose?  grub boot line?
<SpamapS> semiosis: yeah
<SpamapS> semiosis: ahh ok so the service does start ... then that makes me think the gluster mount just fails
<semiosis> SpamapS: checking client logs... looks like it's trying the mount before the service is started, which has been the issue all along
<SpamapS> semiosis: right, so you need to add a post-start to your job that spins until gluster is ready
<semiosis> SpamapS: interesting, sounds reasonable, i'll work on that.
<semiosis> SpamapS: you rock!!!  adding a post-start script of just 'sleep 5' did the trick!  now i know what's needed I can get it down to the minimum necessary.  thanks for your help! :-D
<semiosis> SpamapS: also as a side note, thanks for the quick tutorial on mountall & the events it generates, i've found a whole new area of man pages to study based on that quick tip.
<SpamapS> semiosis: in natty, 'man upstart-events' is really good
<semiosis> SpamapS: nice, i'll check that out on the web, i dont have a natty install set up yet
<SpamapS> semiosis: manpages.ubuntu.com has it
<semiosis> SpamapS: i'm there
<SpamapS> "we're there dude"
<jMCg> oh wow. I'm absolutely flabbergasted. Since when does that exist?
<jMCg> O_o
<jMCg> How do you fuck up man pages?
<semiosis> i dont know, how?
 * semiosis likes a good joke
<jMCg> semiosis: compare manpages.ubuntu.com with http://www.freebsd.org/cgi/man.cgi
<jMCg> It's actually a bad joke.
<jMCg> Also try finding that site from: http://www.ubuntu.com/ or https://help.ubuntu.com/ (th eofficial documentation)
<jMCg> Keybuk: what's it take to port upstart to FreeBSD :)
<Keybuk> jMCg: a FreeBSD developer being interested enough to do it
<JanC> jMCg: the manpages site is linked from https://help.ubuntu.com/community but I agree it should probably be linked from the frontpage...
<jMCg> JanC: or at least from help.ubuntu.com
<JanC> yes, that's what I meant, the frontpage of the help site
<Keybuk> jMCg: the trouble is, of course, that FreeBSD developers don't need Upstart
<Keybuk> they still haven't moved off the one big shell script approach
<Keybuk> (at least, don't think they need :oP)
<mastamind> hi. can i use upstart without dbus?
<ion> The daemon? Sure.
<mastamind> it seems, that the tools only use dbus to communicate with the daemon.
<mastamind> shutdown, telinit, ...
<ion> The daemon? Only optionally if it happens to be there.
<mastamind> sysv_change_runlevel requires dbus.
<Keybuk> it requires the dbus protocol, not the dbus daemon
<Keybuk> there is a miniature dbus daemon built into upstart that it connects to
<mastamind> ok :-)
<mastamind> so the upstart daemon will "emulate" the dbus daemon?
<Keybuk> not so much, but close enough for government work
<mastamind> ok
<mastamind> thank you for your help.
#upstart 2011-04-14
<JohnTeddy> http://paste.pound-python.org/show/5215/
<JohnTeddy> What is wrong with that script?
<JohnTeddy> I want an ssh tunnel to start, everytime my computer connects to a network.
<JohnTeddy> Since my chrome, pidgin, and everything else is setup with ssh tunneling/localhost socks proxy
<sneumann> Hi, I am currently creating upstart scripts for the batch queueing system gridengine.
<sneumann> The pre-start script needs NFS directories to be present, so I have
<sneumann> start on (local-filesystems and remote-filesystems and net-device-up IFACE!=lo)
<sneumann> and yet my /tmp/my-log output shows /vol/local/bin/register_sge.sh: No such file or directory
<sneumann> Script is on http://pastebin.com/QKnP8neJ anything obvious I missed ?
<JohnTeddy> sneumann: You know more about upstart than I do, what's wrong with my script?
<sneumann> what's the error ?
<sneumann> starting too early ?
<JohnTeddy> It just keeps restarting.
<JohnTeddy> I'm not sure why, I don't know how to debug it.. or I can't find the log.
<sneumann> remove the respawn for now, enable it once it works
<sneumann> I guess it is started too early, namely before networking to mybox can happen
<sneumann> try my http://pastebin.com/QKnP8neJ line exec > /tmp/my-log 2>&1
<sneumann> Any Canonical people there ?
<sneumann> upstart.canonical.com is down
<JohnTeddy> I see, so gridengine is how you debug?
<sneumann> no thats a batch system, debugging is via sending stdout/stderr to /tmp/my-log
<JanC> about upstart.canonical.com being down: there is upstart.at now
<JanC> would be nice if the old site would refer to that though...
<JanC> JohnTeddy: first of all, the /etc/init/*.conf files are not scripts but configuration files  ;)
<JanC> also, what is the post-start script supposed to do?
<JanC> and how does ssh login work?
<JohnTeddy> JanC: I am in Shanghai.. so I can't visit facebook, youtube, twitter, and a large selection of other websites.
<JohnTeddy> So everytime I login, I type that ssh command. It forms an ssh tunnel to a remote server in California I own (the company owns). So chrome and pidgin are setup to use localhost:1080 as a socks proxy. So I can visit whatever websites I want, and not worry about certain things being blocked, or being snooped on.
<JohnTeddy> The annoying this is typing that command a few times a day.
<JohnTeddy> Each time I move my laptop, say from one office to another. Or sometimes the great Chinese firewall will kill off my ssh tunnel, so I have to start it again.
<JohnTeddy> I'd li ke upstart to type this ssh command, as soon as I connect to the network, either over WiFi0 or eth0. I don't know anything about upstart, or programming in general.. so I'm struggling.
<JanC> do you need to type any password when connecting with ssh ?
<JohnTeddy> no, I have sftp'd my ssh DSA certificate to the remote server in remote:/home/me/.ssh/known_hosts
<JohnTeddy> So if I do 'ssh john@remote', I just get a shell with no password prompt.
<JanC> so you haven't encrypted your private key...
<JanC> okay, now one problem is that upstart runs ssh as root, and root probably doesn't have a private key that you uploaded...
<JohnTeddy> mmm, my disk is encrypted.
<JohnTeddy> I am using cryptsetup, so when I boot my system.. busybox pops up.. and asks for a key before my large file system can be mounted (which included .ssh).
<JohnTeddy> So I don't believe my private key is easily accessible, and is not shared with anyone.
<JohnTeddy> JanC: hmm, I see.
<JohnTeddy> I don't want to run ssh as root anyway, that seems like a bad idea.
<JohnTeddy> Can I just manually do 'su john; ssh blah blah;'?
<JanC> you can do su -c "ssh blah blah" john 
<JanC> I think you also shouldn't use the -f option
<JanC> because when it forks to the background, upstart will probably think it exits
<JohnTeddy> I see.
<JohnTeddy> JanC: So besides those changes, the script should work?
<JohnTeddy> I googled for this ping command, it seemslike a better condition to be met, relative to the interface starting up.
<JanC> like I said, it's not a script but a configuration file  ;)
<JanC> JohnTeddy: the problem is that it gets run *after* ssh
<JanC> so if you have no connection, ssh will always be run
<JanC> and it will probably fail because early during boot there is no connection, exit with an error, get restarted by upstart, repeat until there is a connection--then you test if there is a connection
<JanC> so it should be a pre-start script really
<JanC> and it's probably better to make "start on" depend on a network device comming up
<sneumann> hi, I am still trying to create an upstart job for the gridengine daemon, facing two problems:
<sneumann> 1) my job is not executed upon booting
<sneumann> 2) service gridengine stop simply hangs, and I don't know what it is waiting for.
<sneumann> The job is started with "expect fork", but I also tried "expect daemon"
<sneumann> Any clues ? The full script is at http://pastebin.com/QKnP8neJ
<sneumann> I tried "start on (startup and remote-filesystems)" but it is not triggered
<Keybuk> it strikes me that the Upstart documentation is sorely missing the page from the Make documentation that explains that there are really two separate syntaxes in the files
<Keybuk> upstart and shell
<ion> heh
<JanC> or that they are configuration files that contain snippets of shell code  ;)
<ion> A lot of people do seem to talk about Upstart âscriptsâ. That might indicate they have the wrong impression of the semantics of the job definitions.
<Keybuk> indeed
<ion> Of course, nothing would prevent a very similar syntax that is in fact a DSL in a scripting language.
<JanC> you can say that about HTML too  ;)
<ion> of course
<ion> (html (head (title "foo") (script (on-click 'foo (alert "bar")))) (body (h1 "o hai") (p (id 'foo) "quux")))
<ion> Web scripting in the same language as the markup of content, anyone? :-P
<JanC> Mozilla configuration files are sort of JavaScript scripts too  ;)
<JanC> Mozilla/Firefox/etc.
<JanC> or were (maybe not anymore nowadays that they have SQLite?)
<ion> prefs.js still exists.
#upstart 2011-04-15
<Russehl-Athletic> hiho
<Russehl-Athletic> can i somehow disable the current ubuntu (10.10) init stuff from starting everything in parallel? problem is our dhcp server is a bit slow and we don't get the nfs mounts and nis stuff after our bootup
<Russehl-Athletic> speed really doesn't matter here
<JanC> why not make the thing(s) that don't work wait longer?
<JanC> you could add an event that fires when the DHCP response came in, and then make sure the jobs that need it wait for that event
<Russehl-Athletic> ok thanks for the help
<kyheo> hi 
#upstart 2011-04-17
<eFfeM> hi, I want to use "service" to restart networking (service networking restart), but I get "networking stop/waiting" google comes with a number of pages that suggest interference with NetworkManager, I already uninstalled that one but that does not help. btw /etc/init.d/networking start does work (but I'd rather use service as this is used on several places in a script I got
<eFfeM> this is on 10.04.02
#upstart 2012-04-10
<Totum> hi.. sorry for such a basic question.. but I'm trying to write my first upstart script, and I'm trying to decide what the most appropriate 'start on stanza' to start the program is... is there a big list of all the possible EVENT options??  : man upstart - start on EVENT [[KEY=]VALUE]... [and|or...])
<Totum> all of the guides seem to assume this knowledge, and I cannot find anything but a handful of examples from scripts that other people have written
<SpamapS> Totum: 'man upstart-events'
<SpamapS> Totum: *most* regular services should just 'start on runlevel [2345]' and 'stop on runlevel [^2345]'
<Totum> hi SpamapS.. thanks for the information, its been very helpful (and apologies for my slow feedback..! hehe) .. it makes more sense for me to use runlevels rather than as this is what I am used to.. I was only using  events as I had copied these from another script... so know the script is starting correctly now.. i'm having other issues but I will try to work these out before shouting for...
<Totum> ...more help :)
<marrusl> Hmmm... what might cause mountall not to emit "filesystem"?
<marrusl> I have a situation where that's happening and so rc-sysinit doesn't run.
<marrusl> and syslog has "init: Handling filesystem/failed event"
<marrusl> but then when you telinit 2, the sys v runs and everything seems normal.
<marrusl> I'm going to have to wait for a reproducer.   all i have is " grep "init:" /var/log/syslog.....
<marrusl> so maybe there's some obvious reason as to why "filesystem" isn't getting emitted in the full logs.
<marrusl> SpamapS, ^^ do you know the criteria for mountall to emit "filesystem"?
<marrusl> I guess this is really more of a mountall question...  omg... I just looked at man mountall
<marrusl> still says "temporary".
<marrusl> ;-)
<JoeGaudet> Hey gues
<JoeGaudet> guys
<JoeGaudet> I am new to upstart, just wondering how I can make an upstart process not belong to root.
<JoeGaudet> That is to say, I can start / stop it with another specified user.
<SpamapS> marrusl: filesystem is emtited when all filesystems are mounted from /etc/fstab
<SpamapS> marrusl: excluding 'nowait'
<SpamapS> marrusl: that includes any remote filesystems.. which are only known to be remote because mountall has a big switch/case
<SpamapS> JoeGaudet: you can actually
<SpamapS> JoeGaudet: there's a dbus socket that non-root users can use to call initctl (which start/stop are just aliases for)
<SpamapS> JoeGaudet: the permissions are specified on Ubuntu in /etc/dbus-1/system.d/Upstart.conf
<marrusl> SpamapS, ok.  That's about what I expected.  Thanks for the info.
<JoeGaudet> SpamapS: So I can basically add a policy for another user in that conf file ?
<JoeGaudet> hrm
<SpamapS> JoeGaudet: or just add that user to the admin group
<SpamapS> JoeGaudet: oh actually there's nothing special for admin. So yeah, you'd just make another user like 'root'
<SpamapS> JoeGaudet: almost easier to just use sudo.....
<JoeGaudet> This is part of a one click deploy script though
<JoeGaudet> that isn't run as root
<SpamapS> JoeGaudet: so just give your one-click deploy script running user sudo access to run 'start X' or 'stop X' .. seems more straight forward than dbus permissions.
<JanC> JoeGaudet: do you want an upstart job to run as non-root, do you want to install an upstart job as non-root or do you want to start/stop an upstart job as non-root?
<JoeGaudet> 1 & 3
<JoeGaudet> I'd like it to run as not root
<JoeGaudet> and stop + start by a non root user
<JanC> on Ubuntu or on another OS using upstart?
<JanC> upstart supports user jobs, but not on Ubuntu (yet?) AFAIK
<JanC> run as non-root is easy with 'su'
<JanC> start/stop as non-root might require changes to /etc/sudoers
<JoeGaudet> Ubuntu
<JanC> depending on if the user is already able to use sudo...
<JanC> JoeGaudet: by default on Ubuntu all users who are members of the groups "admin" or "sudo" can become root using sudo
<JanC> so depends on if you want non-privileged users to start/stop your service too...
<JoeGaudet> I do yeah
<JoeGaudet> I have script that builds the jar that needs to be run
<JanC> JoeGaudet: does it have to run as the user who starts your service?
<JoeGaudet> So at the end of the script I'd just like to have stop <serviceName>; start <serviceName>
<JoeGaudet> Nope
<JoeGaudet> I could be someone else
<JoeGaudet> though Ideally i'd like it to be owned by deploy
<JoeGaudet> for organization sake
<SpamapS> JanC: don't use 'su' for running as not root btw
<SpamapS> JanC: it keeps the 'pam' session open for the user, causes problems
<JanC> SpamapS: ah, what's the recommended way then?
<SpamapS> JanC: start-stop-daemon is safer
<JanC> ah, right
<SpamapS> JanC: or on precise and later, setuid/setgid .. though the problem with that is pre-start and post-start run as not-root too, which can be problematic
<JanC> sounds like we need something more fine-grained in a future upstart then  ;)
<JoeGaudet> indeed
<JoeGaudet> I'll give it a poke later 
<SpamapS> JanC: yeah its been discussed that the setuid/setgid should be arguments to script/exec .. that would work.
<SpamapS> JanC: so you'd have 'script setuid nobody\n...end script'
<benburkert> i've got an upstart job that is failing to start, but "start job" says the job is already running
<benburkert> is there any way to debug upstart to check what process it considers this job to be?
<SpamapS> benburkert: status jobname
<benburkert> SpamapS: status says it's up, but it's not, is there any way to get the PID that it thinks the job is?
<SpamapS> "up" ?
<SpamapS> benburkert: a job does not need a pid to be in a start/running state.
<SpamapS> benburkert: if a job has no exec/script section, it will not track a pid
<benburkert> it's the default mysql package
<benburkert> which has exec /usr/sbin/mysqld
<SpamapS> benburkert: and status shows 'start/running' but no pid?
<benburkert> but it also has a pre-start and a post-start script
<benburkert> SpamapS:  yes
<SpamapS> benburkert: that would be a bug then. As soon as that process goes away, the job should go into respawn mode, or stop/waiting
<SpamapS> benburkert: do you maybe have an override file?
<benburkert> where would that be?
<benburkert> also, is there any other logs than syslog for this stuff?
<SpamapS> /etc/init/mysql.override
<SpamapS> benburkert: you can up the verbosity with 'initctl log-priority info'
<SpamapS> benburkert: all logs should be in /var/log/syslog
<benburkert> SpamapS: there's a /etc/init/mysql.conf.dpkg-dist file, would that be it?
<SpamapS> benburkert: no, but that is the original file, diff against that to see what local mods have been made
#upstart 2012-04-11
<SpamapS> benburkert: I'd be interested in what that diff is :)
<benburkert> SpamapS: https://gist.github.com/367891f799fc5769f5c6
<SpamapS> benburkert: ok so datadir was moved
<benburkert> right
<benburkert> is it trying to use the old data dir maybe?
<SpamapS> benburkert: no
<SpamapS> benburkert: unless my.cnf tells it to
<SpamapS> benburkert: if you stop/start the job, then do 'status mysql' does it say start/running ?
<benburkert> SpamapS: it does start properly if i do that
<benburkert> the problem is that i have chef scripts that think mysql is running because "start mysql" exits normally
<benburkert> but it aint
<SpamapS> benburkert: AHHH
<SpamapS> benburkert: so later on, mysqld dies, and upstart does not respawn it?
<SpamapS> benburkert: ultimately, there needs to be a chef module that asserts the state it wants (started, or stopped) and then uses status/start/stop to make that happen. I think the ones I've seen make invalid assumptions about the exit codes of start/stop/status
<TauPan> Hi... I have a job that should start an agetty on ttyS*, as soon as it appears, but I have to start it manually. I wonder what's wrong with: 'start on device-added SUBSYSTEM=tty DEVPATH=ttyS*'
<TauPan> it looks like the device is added pretty early, so I guess it might already be present as soon as upstart sees that 'start' line
<TauPan> hm, maybe 'start on device-added SUBSYSTEM=tty DEVPATH=ttyS* or runlevel [2]' is better
<SpamapS> TauPan: there is no "device-added" event. You probably want tty-device-added, per the explanation in the manpage of upstart-udev-bridge 
#upstart 2012-04-13
<lolmaus> Hi! Does Ubuntu 12.04 allow using $HOME/.init ? If not, what modifications should be done to Upstart.conf to allow that?
<claudio> Hi. I'm using Upstart to run my program, but I'd like to rely on Redis being already started. Redis is not under Upstart (and I'd like it to remain this way). How could I "start on" depending on another non-upstarted process? 
<blami> lolmaus: user must run initctl to tell upstart about ~/.init conf files (someone here told me)
<lolmaus> Thx blami, but i've got no idea what that means
<claudio> I think I'm going to add "initctl emit redis-server" to the redis-server init.d script
<claudio> one line fix.
<lolmaus> I've created /etc/init/chili.conf. How do i start it? "start chili" says no such job.
<TauPan> tried 'initctl reload-configuration' ?
<lolmaus> TauPan, tried just now when you suggested. No result :(
<TauPan> and you might need to check for error messages in syslog, upstart refuses malformed jobs
<TauPan> (I think)
<lolmaus> TauPan, "/var/log/syslog" is fine
<TauPan> so after reload-configuration, the job is still unknown?
<lolmaus> TauPan, it was an error in my job config.
<lolmaus> I wish it reported the error and erroneous line. "Unknown job" is misleading...
<lolmaus> TauPan, is there an upstart equivalent for "/etc/init.d/foo status"?
<TauPan> initctl status foo
<lolmaus> Thank you TauPan, you're very kind
<lolmaus> TauPan, can i set working directory in job config?
<TauPan> no idea
<TauPan> I'm out of off-hand knowledge now, I'd need to check the manual.
<JanC> 'cd'?
<jY> anyone know if it's possible to build 1.5 from source to install on ubuntu lucid?
<SpamapS> jY: in the past I tried and there were some build-deps that had to be backported
<jY> ok
<JanC> I seem to remember somebody saying that backporting those build-deps would break other applications, etc.?
<SpamapS> JanC: right
<SpamapS> jY: I tried a while back and libnih failed.. https://launchpadlibrarian.net/75414144/buildlog_ubuntu-maverick-amd64.libnih_1.0.3-0~1052~maverick1_FAILEDTOBUILD.txt.gz
<SpamapS> and that was just 10.10
<SpamapS> 10.04 got even uglier
#upstart 2012-04-14
<steffen123> hello, i'm trying to figure out the command to run to get the list of services started on boot. i've found the upstart docs and read everything that looked relevant to me but i still havent figured it out... any pointers would be appreciated
<steffen123> this is on a ubuntu 11.04 headless server
<SpamapS> steffen123: because of the parallelism and event based nature, its hard to say on a modern system what gets started...
<SpamapS> steffen123: there is a visualization tool though, that will show you a graph of events -> jobs that helps
<SpamapS> steffen123: its called 'initctl2dot'
<SpamapS> steffen123: initctl2dot && dot -Tx11 upstart.dot    <-- will show you your system's "graph"
<JanC> also, there isn't a fixed list of what services are started on boot, as that might well depend on external circumstances...
<JanC> or if you look at it from a more narrow angle, only jobs with "start on startup" are started directly because you are booting, all the rest gets started because of other events  ;)
<steffen123> ok thanks for the advise
#upstart 2013-04-08
<gansbrest> hi. I'm trying to restart solr with upstart, but reload command doesn't seem to do anything
<gansbrest> have to use stop start to enforce updated config 
<gansbrest> I was under impression that it does stop and start behind the scene
<xnox> gansbrest: reload simply sends SIGHUP to the daemon process.
<xnox> vedic: do you mean server as in the whole machine, or server as in a running daemon?
<Tor-Mentor> Hi, im in the process of writing a bootstraping script to start up multiple instances of a process. The script itself works wonders when called at boot, but when called manually with "start my_apps", it does not return to the prompt. 
<Tor-Mentor> The script is basicly an abstract job with a pre-start script stanza in it.
<jodh> Tor-Mentor: what happens when you start it manually? is the job running? can we see the .conf?
<xnox> Tor-Mentor: usually with "instances" like jobs you pass a variable as well. E.g. start mymultiinstance MYNAME=foo1
<Tor-Mentor> Yeah, the script runs fine. It starts all instances. Its just that i need to hit ^ to return to the prompt.
<Tor-Mentor> CTRL + C even. Is pastebin ok?
<jodh> Tor-Mentor: sure
<Tor-Mentor> http://pastebin.com/YNjyNZmB
<Tor-Mentor> jodh: I have no problem starting the instances manually via "start pmm MODULE=xmlserver".
<jodh> Tor-Mentor: you should probably specify 'start pmm MODULE=$i || true' to avoid the case where a single instance failing to start will stop all subsequent instances starting.
<xnox> Tor-Mentor: why is it a pre-start script, instead of just "script" ... "end script" ?
<SpamapS> also
<SpamapS> there is no need
<SpamapS> just make them all 'start on starting pmm'
<SpamapS> Tor-Mentor: ^^
<Tor-Mentor> xnox: I wanted to be able to control all instances using "service myapp stop/start"
<SpamapS> Tor-Mentor: literally, that job can be one line description "Start/stop all the things"
<SpamapS> Tor-Mentor: and they can all just be 'start on starting pmm' and 'stop on stopping pmm'
<Tor-Mentor> SpamapS: Im not really following you here. inside pmm I have stop on stopping myapp.
<SpamapS> Tor-Mentor: no, you do not need anything in the pmm job
<SpamapS> Tor-Mentor: in all the oter jobs, just do 'start on starting pmm' and 'stop on stopping pmm'
<SpamapS> pmm can literally be a single line       description "this is just a description"
<SpamapS> Tor-Mentor: upstart will keep a "state" for pmm which is either 'start/running' or 'stop/waiting' which you can then use to control all of the other jobs.
<SpamapS> IMO upstart could improve on this a bit with the 'while' keyword that was discussed oh so long ago
<Tor-Mentor> SpamapS: But pmm is the script that controls the jobs and sets up the environment variables needed for the processes. 
<SpamapS> ..
<Tor-Mentor> I might be misinterpreting you massivly here. 
<SpamapS> No you're not
<Tor-Mentor> Let me append some to the paste, for clarity.
<SpamapS> Tor-Mentor: I used the wrong term
<SpamapS> Tor-Mentor: your job that you're showing there is like 'pmm-controller' right? Thats what I meant as the one that can be a single line
<Tor-Mentor> Yeah, exactly. 
<SpamapS> Tor-Mentor: ok, so I would create a conf file for each of those modules, that is just this:
<SpamapS> start on starting pmm-controller
<SpamapS> env MODULE=xmlserver
<SpamapS> export MODULE
<SpamapS> hm
<SpamapS> never mind
<SpamapS> Tor-Mentor: never mind your way should work fine. Ignore me.. need coffee
<Tor-Mentor> Let me show you what I got instead :D
<Tor-Mentor> SpamapS: So do I! ^^
<Tor-Mentor> http://pastebin.com/BihP0yPS Now with 100% more pmm.conf!
<Tor-Mentor> jodh: Is there any resources related to that syntax?
<SpamapS> Tor-Mentor: wow
<SpamapS> Tor-Mentor: I think you are doing *WAY* too much in upstart
<SpamapS> Tor-Mentor: I would have almost all of that in a bash script
<SpamapS> Tor-Mentor: and just pass in the module name as the 1st cmdline argument. Then you can separate your concerns (how to launch your program, vs. how to make upstart run your program)
<jodh> Tor-Mentor: +1 on SpamapS comment - a .conf file should be very short.
<jodh> Tor-Mentor: have upstart 'exec /your/script.sh' and have that script 'exec java $ARGS'.
<SpamapS> also that way you can do my previous idea much easier, which is to just have a job per module with 'start on starting pmm-controller' and then just 'exec /start/my/program.sh module_name'
<SpamapS> jodh: btw, since there's no UDS, I think we should have an upstart champagne brunch (breakfast-y hours for west coast US..late lunch for you folk) at vuds
<jodh> SpamapS: dude, if you're paying, I'm there! ;)
<Tor-Mentor> Ahhh, sounds good. I will look into it.
<Tor-Mentor> I suppose that would require a expect fork, if im running a bash script instead. Is that correct?
<Tor-Mentor> Thanks for the help so far.. Im going to go home and play a bit more with this. 
<SpamapS> jodh: well I'm paying for my own champagne and toast :)
<SpamapS> Tor-Mentor: that is not correct no
<SpamapS> Tor-Mentor: expect fork is only needed if your program daemonizes
#upstart 2013-04-09
<brendand> jodh, we want to run our test tool as soon as the system is ready to be tested. what that actually means may need discussion. i don't know that much about upstart
<jodh> brendand: ok, well you need to know what environment your test tool needs to run in.
<jodh> brendand: 'start on runlevel [2345]' is generally appropriate for jobs that need to run when disks are mounted and networks are up.
<brendand> jodh, we do - but how to express that in upstart terms is beyond me at the moment
<jodh> brendand: so what does your test tool need before it can run?
<brendand> jodh, the best way to describe it would be to say that we should start testing when all initialisation that's going to happen has happened
<jodh> brendand: what does the test tool test?
<brendand> jodh, well we're testing hardware so all services that interact with hardware need to be started
<jodh> brendand: can you give examples of such h/w services that you care about?
<brendand> networking
<brendand> usb
<zyga> jodh: we talk to network manager, udisks, poke udev
<brendand> zyga, actually on servers we don't touch NM
<zyga> brendand: perhaps this also implies our jobs should be able to depend on upstart stuff being started? that would remove the requirement from plainbox itself and offset it to other parts of the system
<brendand> jodh, on desktop systems we are just using xdg autostart to start after login
<brendand> jodh, so we're thinking only about servers here
<zyga> brendand: we could perhaps use upstart for that as well, without user sessions (jodh: we need to support precise +)
<jodh> brendand: I'd go for the runlevel 'start on' then since nm isn't going to be available on the server.
<zyga> jodh: meta-question, do you think backporting current upstart to precise would be a good idea? 
<brendand> jodh, http://upstart.ubuntu.com/cookbook/#normal-start seems to imply that using the runlevel start on would mean that you are okay with the service starting without a valid network interface
<jodh> brendand: please just try the runlevel start on. I'll tweak the cookbook when I'm less busy ;)
 * brendand is reading https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/701576
<jodh> zyga: why?
<zyga> jodh: so that stuff that targets 12.04 can take advantage of new features and can rely on stuff that upstart is good at
<jodh> zyga: doesn't that argument apply to most packages in Ubuntu though?
<zyga> jodh: yes but web apps typically sidestep normal packaging already
<zyga> jodh: yet depend on upstart for getting started 
<jodh> zyga: upstart in precise works perfectly well. I don't understand your argument.
<zyga> jodh: perhaps I miss something, let me explain that
<zyga> jodh: I was looking for setgit/setuid but apparently those are in precise by now
<zyga> jodh: I must have confused that with lucid
<zyga> setgid
<jodh> zyga: ok. You can compare 'rmadison upstart' with http://upstart.ubuntu.com/cookbook/#stanzas-by-category
<fabiant7t> Is it possible for a service to stop itself and prevent further respawns for the current upstart session?
<fabiant7t> My use case is to shut down a client service whose server (another system) rejected communication. The client exits but respawns immediately due to upstart.
<xnox> fabiant7t: respawn can have limits, such that it will stop respawning.
<fabiant7t> xnox: thx! I'll try to add a respawn limit to the upstart job
<xnox> fabiant7t: http://upstart.ubuntu.com/cookbook/#respawn-limit
<fabiant7t> xbox: Jap, I'm reading through it, just need to find the right place to apply it on saltstacks generic upstart job script (http://dpaste.com/1052456/)
<SpamapS> fabiant7t: if the service exits with a normal exit, no respawn will ocurr
<SpamapS> fabiant7t: so just exit(0)
<fabiant7t> SpamapS: I tested that with sys.exit(0) in python, but it got respawned
<SpamapS> fabiant7t: something went wrong then
<SpamapS> fabiant7t: is it being run by a wrapper script that maybe doesn't exit cleanly?
<fabiant7t> SpamapS: As far as I can tell (and read in the logs), it did exit property with a return code 0
<fabiant7t> SpamapS: I'm trying to fix that issue here, btw: https://github.com/saltstack/salt/issues/4411
<SpamapS> fabiant7t: oh I misunderstood actually
<SpamapS> only tasks can exit 0 to avoid respawn
<SpamapS> fabiant7t: to make non-tasks behave the same way you have to add 'normal exit 0'
<fabiant7t> SpamapS: It's a system service, and it's running into a deadlock right now
<fabiant7t> SpamapS: to this script? http://dpaste.com/1052456/
<fabiant7t> I am pretty unfamiliar with upstart and the startup scripts, unfortunately :(
<SpamapS> fabiant7t: oh thats a sysvinit. Wha?
<fabiant7t> obviously it got automatically rewritten to upstart
<SpamapS> fabiant7t: wait no, ignore that script
<SpamapS> fabiant7t: /etc/init/$that_scripts_name.conf
<fabiant7t> SpamapS: aaah, got it
<fabiant7t> SpamapS: That fixes the loop, thanks a lot!
#upstart 2013-04-10
<unixpro1970> is it possible to send a dbus event to upstart?  I am having issues with PID tracking ( the app forks more than twice )  My app generates a pid file so I wish to send a dus message to change the PID that upstarts has stored for my service.  However when I issued a dbus-send it mentioned the PID field is READ-ONLY for my upstart application.
<SpamapS> unixpro1970: no, thats not really possible.
<SpamapS> unixpro1970: why does your service fork twice to daemonize?
<unixpro1970> It forks multiple times and I don't have controll over the amount of times it forks.  Someone else wrote it and I am not allowed to modify the functionality. :-(
<unixpro1970> Due to this the PID tracking is off.
<SpamapS> unixpro1970: yeah, you're out of luck. Use pre-start and post-stop to start/stop the daemon.
<SpamapS> unixpro1970: oh, and write a nasty email to the author.
<unixpro1970> Tried that without luck.
<unixpro1970> The other possible solution I was thinking of developing, was creating a proxy program that will catch upstart signals and can foward them.
<unixpro1970> basically creating my own signal handler to catch the upstart signals and forward them using the pid file.
<SpamapS> unixpro1970: thats a waste of your time honestly
<SpamapS> unixpro1970: you can use pid files with upstart. Just use pre-start and post-stop.
<unixpro1970> how can I force upstart to associate the PID within the pidfile?
<unixpro1970> I have seen the start-stop-daemon example but I don't see how that will fix the upstart pid tracking problem.
<unixpro1970> exec start-stop-daemon --pidfile
<SpamapS> unixpro1970: no don't use exec. In pre-start, start it the same way you would start it in a sysvinit, and in post-stop, the same way sysvinit would stop it
<SpamapS> unixpro1970: if you already have a sysvinit script, you can just call that in those methods. This is only useful if you need to coordinate other services with this one.
<unixpro1970> but it will still track the incorrect PID even without exec keyword
<unixpro1970> remember it forks more than twice
<unixpro1970> the application creates a pidfile that contains the correct pid which I can read.  Howeve can I force upstart to use it?
<unixpro1970> In other words, overwrite the PID that upstart thinks it is using.
<drebolo> hi... I have some questions... I'm trying to create a user job in a ubuntu server but initctl is not seeing my jobs at $HOME/.init
<drebolo> I'm using upstart 1.5
<drebolo> I try to do the same thing in my desktop also with upstart 1.5 and worked
<drebolo> both machines are Ubuntu 12.04.2 LTS
<drebolo> the main difference is that the server doesn't have X installed
<drebolo> any ideas ?
<drebolo> this is just a test script: "task
<drebolo> script
<drebolo>     sleep 5
<drebolo> end script
<drebolo> "
<drebolo> init-checkconf returns "syntax ok"
<xnox> drebolo: user jobs are not enabled by default.
<xnox> drebolo: and user jobs have been removed in the recent 1.7 upstart in raring.
<xnox> drebolo: one needs to do a full login to initialise user session over dbus.
<xnox> drebolo: there were tricks of doing it on the server but i can't quite remember how it was done.
<xnox> drebolo: it is usually recommend to simply use setuid/setgid to change username/group.
<drebolo> hum... that's the problem....
<xnox> drebolo: what are you trying to do? maybe there is another way to do it better =)
<drebolo> I don't do a full login... I just do su - username from root
<drebolo> I want to start a pinto server (https://metacpan.org/module/Pinto) from a specific user
<drebolo> I tried to do it from root but it keeps failing when I do ". /some/bashrc", and  If I managed to do it for that user I would not need to do that...
<monkeynipples> how can i give a unprivileged user the ability to run a specific upstart job ?
<monkeynipples> to start/stop/restart it
<ion> Take a look at sudoers(5)
<monkeynipples> ion: something like sudo -u username /etc/init/job.conf ? 
<ion> The user wonât need -u username, it defaults to root. The user will use sudo start jobname.
<xnox> monkeynipples: you can use policykit to grant users to work/do actions to specific jobs
<xnox> monkeynipples: by adjusting /etc/dbus-1/system.d/Upstart.conf
<xnox> monkeynipples: granting sudo might be a bit "haevy-weight" as granting sudo on "start" command will allow that user to start _any_ job.
<monkeynipples> maybe just restart ? 
<monkeynipples> xnox: i'll look into policykit thanks
<monkeynipples> http://askubuntu.com/questions/229809/allow-non-sudo-group-to-control-upstart-job is a good link for anyone else interested
<ion> xnox: Of course you would limit the parameters to exactly the specific jobname and nothing else.
<monkeynipples> xnox: i tried adding https://gist.github.com/jarradh/1458fe6f105b561683f4 to /etc/dbus-1/system.d/Upstart.conf, rebooted server and tried to run it as testuser stop: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<xnox> hmm... not sure. jodh ^ do you know how to fiddle those settings?
<xnox> or maybe we can poke pitti about it?
<monkeynipples> I don't want to cause a fuss :S
<xnox> monkeynipples: no fuss =) this stuff should just workâ¢ and it doesn't seem like it's documented well enough in the cookbook.
<X-warrior> if upstart is not tracking my PID correctly is it possible to set upstart to use a PID inside a file?
<ion> PID files are horrible and unreliable.
<ion> Can you make the process not daemonize?
<X-warrior> not right now 
<X-warrior> :/
<X-warrior> and the daemon/fork doesn't works
<Jeeves_> Hi
<Jeeves_> I've got a mysqld that's not starting and an upstart that does not accept my explicit call to stop starting mysqld.
<Jeeves_> Any hints?
<SpamapS> Jeeves_: what version of Ubuntu?
<SpamapS> Jeeves_: the mysql upstart job in 10.04 is quite tempermental.
<Jeeves_> 12.04
<Jeeves_> fixed it by chmod -x /usr/sbin/mysqld
<Jeeves_> upstart lets me down 
<SpamapS> Jeeves_: erm..
<SpamapS> Jeeves_: there was nothing in /var/log/syslog, /var/log/upstart/mysql.log ?
<Jeeves_> that mysql couldn't start
<Jeeves_> and it would try to start it again
<SpamapS> Jeeves_: so, it told you the truth, and that is letting you down?
<SpamapS> Jeeves_: /usr/sbin/mysqld not being executable is *not* a normal situation.
<Jeeves_> SpamapS: No, I told it to stop trying to start mysqld, which it refused to do
<Jeeves_> 'stop ' would just hang
<Jeeves_> It's not Upstarts problem mysql doesn't start, it's Upstarts problem that it will not stops trying to start it, even though I ask for it
<Jeeves_> And I know -x on mysqld is not normal. But was the only way to stop mysqld
<SpamapS> Jeeves_: the stop not responding is also not normal
<SpamapS> Jeeves_: did you happen to see what 'status mysql' showed?
<Jeeves_> Kinda lost that in my terminal..
<SpamapS> Jeeves_: so stop will wait 300 seconds for mysqld to respond to its SIGTERM
<SpamapS> Jeeves_: however if it was in respawn/post-start , it would be waiting for that section to exit presumably indefinitely.
<SpamapS> Jeeves_: I think at most, that would have been 30 seconds
<SpamapS> Jeeves_: what version of mysql-server-5.5 do you have installed btw?
<SpamapS> Jeeves_: one other possibility is that there is something on your system 'start on stopping mysql', that will cause stop to hang.
<Jeeves_> the only thing in /etc/init/ mentioning mysql is mysql.conf
<SpamapS> Jeeves_: ok, its hard to debug this w/o knowing the status.. but likely was stuck in post-start
#upstart 2013-04-12
<jodh> long blog post on upstart sessions in Ubuntu Raring: http://ifdeflinux.blogspot.co.uk/2013/04/upstart-user-sessions-in-ubuntu-raring.html
<SpamapS> jodh: o/
<stgraber> jodh: sorry I couldn't find the time to help preparing that article but very nice job!
<stgraber> SpamapS: also, why are you awake that early? :)
<SpamapS> stgraber: there is no logical explanation
<SpamapS> insanity?
<stgraber> hehe, good enough I guess ;)
<jodh> stgraber: thanks! And thanks too for all your contributions this cycle!!!
#upstart 2013-04-13
<ach1m> Hi, I am trying to write an upstart job that "start on started appname". I am on raring and I think I have configured everything correct. I am able to run the job manually.
<ach1m> Would be kind if someone could give me any advice.
#upstart 2013-04-14
<ach1m> Hi, I am trying to write an upstart job that "start on started appname". I am on raring and I think I have configured everything correct. I am able to run the job manually.
<ach1m> Would be nice if someone could give me a hint on how to debug this.
#upstart 2014-04-07
<marianogg9> hi guys, just a quick question. I need to start a job every time the vm is restarted, I've added "start on startup" to the script but it doesn't start when the vm starts
<marianogg9> is there something I'm missing?
<xnox> marianogg9: the job is in the VM? And what do you mean restarted - is it rebooted, or suspended/resumed?
<xnox> or is the job on the host?
<marianogg9> xnox: this upstart script is monitoring a lumberjack service (log shipping service). When the vm where it's located is rebooted or stop/started, it doesn't start automatically
<xnox> marianogg9: can you pastebin the job?
<marianogg9> sure
<xnox> marianogg9: start on startup, might be way too early for it - no filesystems are mounted rw yet potentially.
<marianogg9> xnox: https://gist.github.com/marianogg9/10024411
<marianogg9> then which stanza is more suitable?
<xnox> marianogg9: use : start on runlevel [2345]
<marianogg9> instead of startup you mean?
<FunnyLookinHat> Is there an event automatically emitted / generated upon completion of any upstart task?  i.e. I want to do something once cups.conf has run it's post-start script 
<FunnyLookinHat> all I can think to do is edit cups.conf to emit a special event that I listen for and then try to work with that
<FunnyLookinHat> but I don't want to edit that file  :)
<FunnyLookinHat> Ah - you can just "start on stopped cups RESULT=ok"
<xnox> FunnyLookinHat: yes, that =)
<FunnyLookinHat> xnox, :)  I was getting a bit confused - what I really wanted was "start on started cups RESULT=ok" ... but same difference though
<xnox> FunnyLookinHat: no need for result=ok in that case. "start on started cups" means cups got successfully started and is running.
<xnox> FunnyLookinHat: if it fails to start "started" event is not emitted.
<FunnyLookinHat> xnox, slick thx
#upstart 2014-04-08
<c10ud> hi, I have a service that's choking when the system wildly changes the datetime.. and this happens because my board has no rtc backup battery.. my goal is to just restart that service once the date has been set by ntpdate.. is there an easy way to do this? I'm trying to read upstart docs but nothing useful for me so far
<c10ud> I thought maybe "start on ntpdate stop" but I think that's triggered by ifup.d not upstart?
<raydeo> so I started a custom job and it looks like it got stuck in pre-start... so I eventually ctrl-c and stop hangs as well in the same way. status says "stop/starting". how do I recover from this?
<raydeo> there don't appear to be any PIDs I can kill :-)
<raydeo> is there not a way to tell upstart to just reset all of its state on a job?
<ion> raydeo: Does or did the job use an âexpectâ stanza?
<raydeo> no
<raydeo> the job doesn't do anything, it just has pre-start and post-stop
<raydeo> I've since changed the script, but upstart doesn't appear to care about my changes while it's in this "stop/starting" state
<raydeo> ion: the other day I ran into the "expect" issue and had to run a script to create/kill the PID that upstart thought was there
<raydeo> however this script has no expect/exec/script stanza for me to do that with
<ion> Ok. I havenât encountered that issue then.
<raydeo> this really isn't a good time to reboot.. can't believe there isn't a way to bounce or force the state of a single job to get upstart back in line
<styol> hey there. Is there a way to do custom commands such as "initctl reload [target]"?
<xnox> styol: reload command simply sends a SIGHUP or other signal specified by "reload signal" stanza.
<xnox> styol: if you want custom commands, you should create a new job, which specifies "task" and do anything you like between "script .... end script" as a bonus you can accept variables from events and command line.
<xnox> styol: e.g. start dotask FORCE=yes
<xnox> styol: there is no generic support for custom commands. What do you want to achieve with your custom command? =)
<styol> xnox: oh! didn't realize that was a stanza.. your approach does make sense and should work. I appreciate it
<styol> xnox: while thinking about it, I actually just realized that the start stanza will actually do the same task that i was looking to do a custom command for *facepalm*. It will start as well as reload the configuration file (if already running)
<styol> xnox: since you seem awesome and are around, perhaps one more question ;) related but unrelated, after what run level does /etc/rc.local run? There is a NAS being mounted there and I think, but am not sure, that it is occurring after the upstart job which relies on the NAS being mounted. Guess that should be changed to an upstart job also that has the dependency thing. "start on start [init]" correct?
<styol> *start on started
<styol> I see /etc/rc2.d/S99local which is a symlink to /etc/rc.local -- though it also exists in rc3 - rc5 as well
<xnox> styol: one should not use rc.local
<xnox> styol: networked file-systems should be declared / handled by rcS level and/or upstart jobs - mountall. That way upon mounting NAS, filesystem event would be emitted for that mount point and other upstart jobs can start on remote-filesystems
<xnox> styol: as a workaround you can do
<xnox> styol: after NAS is done, that script should do $ initctl emit nas-is-up
<xnox> styol: and then your upstart jobs can be "start on nas-is-up"
<styol> xnox: yeah working with some legacy, but that sounds like the appropriate solution indeed. Is the `start on start [app]` notation just to depend on another upstart job being started while emit is for a specific event that you can `start on [event]`?
<styol> doh, again -- `start on started [app]`
<styol> oh and there isn't any native way to make an upstart job a CLI command, correct? Just need to create some sort of wrapper bash script or something that does `initctl $action app`?
<xnox> styol: i don't understand what you mean. "started" is one of the  system events which are emitted by upstart itself for upstart jobs only.
<xnox> styol: see $ man 7 upstart-events
<xnox> on your system (or manpage on the web for the same version/release as your system)
<xnox> styol: upstart jobs are declarative, and the actions that initctl can do are predetermined e.g. start, stop, restart, reload, status etc.... all of them are internal to upstart
<xnox> styol: see job filecycle in $ man 8 init
<xnox> styol: but jobs can can pre-start/post-start pre-stop/post-stop where you can run arbitrary shell scripts to e.g. bail starting a job, block on staring some other job, and do anything you like.
<xnox> styol: see http://upstart.ubuntu.com/cookbook/ for best practices it explains a lot of things one can do, to achieve practically anything =)
<styol> xnox: thank you so much, I will checkout the referenced manuals and cookbook. it is much appreciated.
<styol> one thing is that it seems I'm rocking 0.6.5 by default on centos 6.3, though I'm guessing it can be upgraded
<styol> noticed the discrepancy when I attempted to utilize `console log`
<xnox> styol: yeah, use manpages provided with your distribution to check that things you want to use, are in-fact available.
<xnox> styol: e.g. man 5 init
<styol> roger.. just out of curiosity, what are the different numbers for?
<styol> xnox: hrm, a.conf -> initctl emit prepared / b.conf -> start on prepared # doesn't appear to be running the b job (at least I'm not catching any output from pre-start, post-start, or script .. end script
<styol> xnox: I am checking out the man pages and cookbook and it appears I'm doing right, but I suppose I'm not
<xnox> styol: what do you mean catching any output?
<xnox> styol: there is no output generated from "initctl emit" command.
<styol> xnox: pre-start exec echo "pre-start" >> /var/log/upstart.log # as an example
<xnox> styol: it b job already running?
<styol> ah yeah that is fine, it seems though that the b job isn't reacting the emitted event from the a job
<styol> i don't believe so, i moved `start on [2345]` to A and instead put `start on prepared` in B
<styol> xnox: A has script /* stuff */ initctl emit prepared end script with carriage returns appropriately
<xnox> styol: http://paste.ubuntu.com/7224070/
<xnox> styol: i've had "upstart-monitor" running in the background, hence the interractive feedback as to what happened.
<styol> ah that is pretty nice indeed, was wondering ;)
<xnox> styol: if you have $ initctl log-level, you could adjust it to debug.
<xnox> styol: and then in syslog / or somewhere else you should get more events printed.
<styol> seems it has log-priority but not seeing log-level
<xnox> styol: if however b is already running, (like at the end of above) further "$ start a" will not trigger b job at all. 
<xnox> styol: yeah, crank up log-priority debug
<styol> yeah that makes sense indeed, shouldn't be as start on runlevel got replaced by start on prepared
<styol> ah ok
<styol> yeah hmm.. B isn't mentioned at all, lemme try a simplified version real quick
<styol> xnox: interesting, with your example it is causing the original B script to start, but in my real A script its `script /* more */ initctl emit prepared end script`
<styol> original = real
<xnox> styol: note that upstart executes all scripts under "set -e" and "/bin/sh" (not bash, although it might be on your system)
<xnox> styol: comment things out and start with minimal working sample and build up, until you spot mistake.
<styol> xnox: ah good thing to know indeed. Yeah seems it may have been a PEBCAK
<styol> for sure works right from the CLI, now to try a reboot
#upstart 2014-04-09
<styol> xnox: and then yeah, doesn't work on boot
<xnox> styol: i meant make the job file (a.conf) minimal, start with just e.g. "script \n initctl emit prepared \n end script"
<xnox> styol: and log every line somewhere.
<styol> will do now
<xnox> and bit by bit increase it. check the environment, upstart cleanses the environment, thus no typical variables are available. re-declare them.
<xnox> styol: e.g. $HOME is _not_ set.
<styol> xnox: that is one thing I came across with b.conf, decided to just provide the otherwise used environment variable as an argument
<xnox> initctl emit prepared FOO=bar
<xnox> can pass variables.
<styol> xnox: ah right, but the wrapper script being ran by initctl was relying on an environment variable set like so `echo "export AQUA_CONFIG=$CONFIG" >> "/etc/profile.d/aqua.sh"`
<styol> seems it is indeed not available, so i'll just have to dynamically create the upstart job with the config file specified as part of the command
<xnox> styol: i think it's supported to have .override files. e.g. keep you main job as is, but e.g. have "env FOO=bar \n env FOO" in a.override
<styol> xnox: crapola, it must be the NAS mounting because that is the bare minimum.. trying without it now, probably will work
<styol> interesting! that would be nice
<styol> will try that indeed
<xnox> styol: this way you can do e.g. $ start a FOO=different, and FOO will be overriden with value "different" _and_ available inside all stanzas in a, _and_ due to export be part of events emitted from within it.
<xnox>  "env FOO=bar \n export FOO" in a.override (that is)
<styol> xnox: but without providing the argument it should take on bar?
<xnox> check man 5 init, to see if .override file is support, env and export keys.
<xnox> styol: correct.
<styol> delicieus, will check as soon as it done rebooting
<styol> also delicious
<styol> i no can englishes today
<styol> xnox: nutty, never reaches the emitted event http://pastie.org/9009721
<xnox> styol: try "initctl emit --no-wait prepared"
<styol> en route
<xnox>        --no-wait
<xnox>               Applies to the start, stop, restart and emit commands.
<xnox>               Normally  initctl  will  wait  for  the  command  to finish before
<xnox>               returning.
<xnox>               For the emit  command,  finishing  means  that  all  of  the  jobs
<xnox>               affected  by the event are running (or have finished for tasks) or
<xnox>               have been fully stopped.
<xnox> thus e.g. if prepared event blocks then your job just gets stuck there.
<xnox> e.g. if there is a job "start on prepared and anotherevent" then you are blocked waiting for "anotherevent" which might never happen.
<xnox> good night.
<styol> xnox: thank you so so so very much
<styol> it is very much appreciated
<styol> sleep well <3
<styol> xnox: so, I ended up moving the NAS mounting to /etc/fstab where it probably should be, and then within the upstart script I am using while and sleep to perpetually check for the existence of the expected file, which does seem to be working. Many thanks again.
<Trevinho> Hey, one question
<Trevinho> is the dbus service activation (https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032295.html) still working (also in a session)?
<Trevinho> as I can't find a service that seems to use it
<xnox> Trevinho: in recent ubuntu that has been disabled, there are plans to get that back, but it's not back in yet.
<Trevinho> xnox: mh I se... so a workaround might be to use upstart init something as the exec for that dbus service or that won't work?
<xnox> Trevinho: there are plenty of system jobs that start a daemon which happens to export itself on dbus. So yeah - start on started dbus \n exec foobard
<xnox> Trevinho: recent upstarts have upstart-dbus-bridge such that events are generated when things appear/disappear from dbus and one can start/stop jobs according to those events. but that's reactive.
<Trevinho> xnox: well, the fact is that I want the service to start not on dbus, but on name activation
<Trevinho> xnox: so say you can org.foo.bar then the service starts, handled by upstart, so that I can also stop it
<xnox> Trevinho: that's not currently handled.
<xnox> Trevinho: it used to be, and there are plans to introduce it.
<xnox> Trevinho: do it manually =)
<Trevinho> xnox: yes, manually... and to do to do that, can I just add into the dbus .service file an exec= string such as initctl start my-service or that won't work?
<xnox> Trevinho: you can do that.
<Trevinho> xnox: ok
<styol> Hmm.. any ideas why post-stop might be running on `start on runlevel [2345]? There is also `stop on runlevel [06]`, but from what I understand those run levels should be for halt and reboot 
<xnox> styol: post-stop is run as part of the job life-cycle, e.g. after the main process has terminated (because it crashed, exited normally, or the job is being stopped)
<xnox> styol: start on / stop on -> are simply the event trigger that cause changes to the job life-cycle: e.g. do whatever needs to happen to get the job from dormant to running; or from running to dormant again
<styol> xnox: aha, that would explain it since it is somewhat of a wrapper script. Crapola. That being the case, a normal script definition doesn't work for stops which is what post-stop was supposed to solve since it calls the same wrapper script called to start
<xnox> styol: post-stop is always executed when the job is stopped, irregardless as to /why/ the job is stopping.
<styol> totally makes sense
<styol> *since it calls the same wrapper script to stop that was used to start
<xnox> styol: you may be need / want "post-start" and "post-stop" scripts.
<xnox> styol: and read the cookbook to see which states the job go through (normal and task jobs) and which snippets of the job are executed when.
<styol> xnox: gotcha, post-start won't apply to the stop cycle which makes it work like desired, correct?
<styol> start is indeed script end script and therein lies the problem that post-start should solve.. awesome idea
#upstart 2014-04-10
<styol> thanks again xnox, you rock
<dstokes> hi guys. what's the proper way to execute something when an app crashes but hasn't reached the respawn limit. post-stop is also run when the process is manualy stopped so that's not working for me. is there an event i can have another task listen to?
<dstokes> like, maybe i can check $PROCESS on the 'stopped' event?
<dstokes> basically looking for `start on respawned <job>`
<dstokes> guise?
<styol> dstokes: I'm a newbie so I may not have the proper guidance available, but you might be able to `initctl emit your-event-name` within your stop routine and then `start on your-event-name`
<dstokes> styol: afaik there is no way to detect a process failure / respawn in stop routines. only difference in a respawn is that pre-stop isn't run
<styol> dstokes: ah I see what you're saying
<dstokes> easy to detect when the process stops, not easy to make a distinction btwn `stop <job>` and process crashing
<styol> dstokes: this post suggests PROCESS=respawn might be able to be used https://bugs.launchpad.net/upstart/+bug/716802
<dstokes> styol: process=respawn indicates a process that reached it's respawn limit. it's triggered once after n unsuccessful respawn attempts. i'm currently using a task to monitor those failures.
<dstokes> goal now is to detect when apps crash but successfully restart, for debugging purposes
<xnox> styol: dstokes: the events emitted are - stopped/failed JOB='test' INSTANCE='' RESULT='failed' PROCESS='respawn'
<xnox> styol: which is emited after e.g. the main process segfaulted.
<xnox> styol: after that there will be new starting/started events from respawning.
<xnox> wait no, that one is when the respawn limit is reached
<styol> ah i see
<styol> dstokes: ping
<dstokes> yup
<dstokes> respawn does not represent a respawn, but reaching the respawn limit
<xnox> styol: dstokes: for the intermediate failures one gets: started/failed JOB='test' INSTANCE=''
<xnox> styol: dstokes: let me paste the log of events
<dstokes> job failure is indicative of the upstart job failing, not the managed process right? pretty sure i tested that case..
<xnox> dstokes: so without respawn the event i see is - stopped JOB=test EXIT_STATUS=1 PROCESS=main RESULT=failed
<xnox> dstokes: or e.g. - stopped JOB=test RESULT=failed PROCESS=main EXIT_SIGNAL=FPE
<xnox> (floating point exception, core-dump)
<xnox> dstokes: but with respawn one gets less information. You could leave out respawn, and instead have a second job - e.g. monitor.conf which is "start on stopped mainjob" which then can act appropriate and do "$ start --no-wait mainjob" to "respawn" and/or do other clean-up things 
<dstokes> i'm only seeing that event after respawn limit with - stopped JOB=test PROCESS=respawn RESULT=failed
<xnox> dstokes: looks ugly, and i think it's a bug that /less/ info is passed.
<dstokes> maybe i need to check my exit code..
<dstokes> xnox: then you have to hack together your own respawn limit right?
<xnox> dstokes: "so without respawn the event i see is" as in if the main job _does not have "respawn" stanza_ I  see more info in the failed events.
<xnox> dstokes: yeap.
<xnox> i think it's bug that we don't emit as to /why/ we failed.
<dstokes> xnox: sry, main job _does_ have respawn stanza, along with limit
<dstokes> i'm only seeing stopped and stopping emitted at the end of several respawn attempts (when the limit is reached)
<xnox> dstokes: respawn -> only one failed event, when respawn limit reached without info; without respawn -> more details as to why main process failed.
<dstokes> xnox: i see. so that's just the way it is ;)
<dstokes> to workarnd, should be writing my own respawn task
<dstokes> often times a process will fail, then startup successfully. those are the cases i'm after so i can debug why it failed before the logs fill up etc
<xnox> dstokes: it is weird. I'll open a bug about it, but probably will not help much as it will take a while for such a fix to be created.
<dstokes> right, thx for your help anyway. happy to at least confirm that it's not misconfiguration on my end
<xnox> dstokes: oh, i see. I wonder if you can just crank up upstart logging to get that.
<xnox> dstokes: so do you actually want to take any automated scripts/job upon failures? or are you simply to collect data?
<xnox> dstokes: after $ initctl log-level debug (the most debugging)
<dstokes> the ideal scenario is: setup main job to respawn a process when it fails, setup secondary task to curl when the process is respawned succesfully (curl for notification)
<xnox> dstokes: I see - http://paste.ubuntu.com/7232773/
<dstokes> i suppose i could watch the log, but that's a little more involved than i want to get ;)
<xnox> dstokes: i think we can succeed your requirements!
<dstokes> xnox++
<xnox> dstokes: one sec, testing.
<dstokes> for context: main job http://paste.ubuntu.com/7232809/
<dstokes> and associated task: http://paste.ubuntu.com/7232813/
<dstokes> alrdy have the respawn limit task working properly. notifies me when a process fails to respawn (after limit)
<xnox> dstokes: so my "main" job simply does "main() { pause()};"
<xnox> dstokes: that's the process, and then externally i send FPE (kill -8) to it.
<xnox> $ cat /etc/init/test.conf 
<xnox> respawn
<xnox> exec /tmp/a.out
<xnox> that's main job.
<xnox> and here is my "monitor"
<xnox> $ cat /etc/init/monitor.conf 
<xnox> start on stopping test
<xnox> stop on stopped test
<xnox> script
<xnox> 	sleep 2; echo "Main job respawned successfully"
<xnox> end script
<xnox> ..
<xnox> dstokes: so when job under test fails (stopping test) monitor kicks in. If the job is getting normally stopped or reached respawn limit, the monitor will be stopped.
<xnox> dstokes: however, if respawn succeeds and the job stays alive for 2 seconds then in /var/log/upstart/monitor.log i get notification that respawn was successful.
<xnox> dstokes: but the sleep2 needs to be adjusted. You could do better without a sleep
<dstokes> clever..
<xnox> dstokes: e.g. "stop on stopped test or started test"
<xnox> dstokes: and then instead of script, you'd have a post-stop script -> which checks the stop event environment.
<xnox> dstokes: if the reason for getting stopped is "started test" it means a succssful respawn happened.
<xnox> let me code that.
<xnox> dstokes: nah, needs sleep / appropriate matching for respawn limit none-the-less.
#upstart 2015-04-10
<snappy> Is there a way for upstart to manage spawning N processes of a program, associating them with the same process group?
<lnykryn> hi! Is it possible to run initscript with initctl command? My point is that I want pid 1 to actually run the initscript, not user.
