#upstart 2007-04-16
<concept10> Is there anything special I have to do to enable bootchart in upstart?  I see some small changes in the changelog
<concept10> oh, sorry, it wasnt enabled in grub
<mbiebl> concept10: bootchart is independent from using upstart or sysvint.
<mbiebl> Which distro do you use?
<mbiebl> On ubuntu, installing bootchart enables it by default (and the generated graphs are placed into /var/log/bootchart)
<concept10> mbiebl, feisty.. I just 
<mbiebl> On Debian you need to pass the boot parameter init=/sbin/bootchartd
<mbiebl> With feisty this should not be necessary (as long as you use the stock ubuntu kernel)
<mbiebl> Or better, a kernel with an initial ramdisk.
<concept10> I saw that installing updated the init ramdisk but I see no images
<concept10> do I still need to append the boot parameter?
<mbiebl> no, it should work out of the box.
<concept10> mbiebl, could it be that the script hasnt finished?  I still show in my process list root       930  0.0  0.0   1100   196 ?        S    14:19   0:03 /bin/busybox sh /bin/bootchart bottom
<mbiebl> Do you have /etc/rc2.d/S99stop-bootchart ?
<concept10> yep
<mbiebl> If you run that manually, does it stop the bootchart daemon?
<concept10> I should note that I am in recovery mode (single user)
<concept10> and I dont see any bootchart daemons
<concept10> only three busybox bootchart scripts
<concept10> bootchart should take the place of init?
<mbiebl> Try to boot normally into runlevel 2.
<concept10> mbiebl, runlevel 2 is default right?
<mbiebl> In Debian/Ubuntu, yes.
<concept10> I can boot normally in runlevel 2, but GDM freezes.
<concept10> The only way I can get into my system now is recovery mode and start GDM myself
<concept10> so I guess upstart will work when I figure out that problem
<concept10> I meant bootchart
<mbiebl> apt-get install sysv-rc-conf && sysv-rc-conf gdm off
<concept10> mbiebl, does that turn it off for all runlevels ?
<mbiebl> yes
<concept10> I wish there was someway to tell what config file gdm is using.. I guess its using the default one
<concept10> im trying to figure this one out before release so I can report a better bug.  I think it will cause some users systems to fail.
<mbiebl> Before playing with bootchart, I'd investigate first why the system freezes with gdm.
<concept10> mbiebl, yeah, thanks.  Im going to reboot.  Ive been working on this problem for 2-3 days.
<concept10> bbl
<concept10> Hello all.. Does recovery mode boot to runlevel S
<concept10> ?
<mbiebl> concept10: yes
#upstart 2007-04-17
<Peaker> hi, is it possible that in the future, the format of the init scripts and their layout on the file system will be changed?
<Peaker> because it could be nice if it used "make -j" or whatever to allow parallelization of unrelated processes at boot time
<Peaker> (while maintaining the topographical order)
<Peaker> and also it could be nice if the shutdown process didn't shut down things that don't have to be (saving time)... Like shutting down each and every stateless daemon. (But that's another issue)
<Peaker> (or at least parallelize that too)
<tale> Peaker, I believe those things are already designed to work that way, from what I know
<Peaker> well, I know bootup is pretty damned slow (compared to Windows still) so I assumed it must be serial (its hidden under the graphical stuff so I can't tell) :)
<tale> parallelization wasn't enabled at boot time because they wanted to test the scripts more.
<tale> that's what I was told when I asked about Feisty
<tale> it's hard to compare against windows accurately
<tale> an old windows system boots much slower for me compared to a fresh install 
<tale> if you want to speed up ubuntu boots, check the community help
<tale> help.ubuntu.com
<tale> they provide a post in the community section that gives ways to make it faster
<Peaker> its not important to me, really, I was just wondering - and also I think its important for potential users and making a good impression
<tale> it will get there
<Peaker> ok, cool. I was thinking that the problem is probably hundreds of daemon packages that register themselves into /etc/rc*.d/* in ad-hoc ways
<Peaker> and making it parallel requires explicitly specifying the dependency relationships, instead of putting a number inside an rcX.d directory
<tale> right, they should have all the scripts worked out for the next release if everything goes to plans
<Peaker> ah cool so there will be no more of the /etc/rc2.d/* crap?
<Peaker> oh I see how upstart events can be used as a dependency invocation thing
<Peaker> if they are already used that way - what are the /etc/rc*.d/numberedScripts doing there? Are they unused? Or still used for these things that aren't invoked on events
<tale> Peaker, it's my understanding that they are for compatibility at this point and will eventually go away
<Peaker> cool!
<Peaker> the chart png thing is cool too
<tale> you mean bootchart?
<Peaker> ya
#upstart 2007-04-19
<Rudd-O> hello
<Rudd-O> who is the Upstart author?  I'd like to contact him for an interview.
<Rudd-O> hello?
<cortana> patience
<mildred> hi
<mildred> hi
<mildred> I try to make upstart work with ArchLinux distribution and I have a problem. /opt/upstart/sbin/shutdown does not generates a 'shutdown' event ...
<mildred> is it normal ?
<mildred> (so I can't reboot)
<AlexExtreme> the shutdown event is not triggered in the latest version of upstart
<AlexExtreme> how old are the jobs you are using?
<mildred> from yesteday ...
<mildred> so, what event is generated instead ?
<AlexExtreme> a runlevel event is generated
<mildred> it seems to be a 'runlevel 6' when I looked. But I don't like the runlevels (ArchLinux itself is using BSD style init with no runlevels)
<mildred> why ?
<mildred> is there a possibility to make it generate a shutdown event by default ?
<AlexExtreme> a 'runlevel 0' or 'runlevel 6' event is generated depending on whether you reboot or halt
<AlexExtreme> no, it won't
<AlexExtreme> the runlevel name is just for compatibility, you don't *have* to implement runlevels
<mildred> is it related to the compatibility mode in the configure options ?
<AlexExtreme> no, even if you disable it the shutdown event isn't generated
<AlexExtreme> that's just the event that's generated
<mildred> ok, I will do with it, but do you know why the shutdown event was discarted ?
<AlexExtreme> no
<mildred> thanks
<mildred> I'm going to reboot :)
<AlexExtreme> just out of curiosity, why do you want to make upstart work on Arch? the arch guys have clearly said they don't think it's suitable here: http://bbs.archlinux.org/viewtopic.php?id=31546
<mildred> because I think an event based system is better for laptops
<AlexExtreme> ok
<mildred> there are many events and i think it can be better integrated
<mildred> I replied here :) http://bbs.archlinux.org/viewtopic.php?pid=244507
<mildred> thanks for the topic, I'll take a look
<mildred> I don't really seek improved performances
#upstart 2007-04-20
* Starting logfile irclogs/upstart.log
<SlAiD> Md read my private messege \o
<SlAiD> please :p
#upstart 2007-04-21
* ion_ finally got around to setting jabberd back up. ion@heh.fi
<wil_syd> Whats a general purpose shutdown event ? 
<AlexExtreme> the shutdown/halt/reboot utils will emit a runlevel event
<wil_syd> like the opposite of start on startup
<AlexExtreme> 'runlevel 0' for shutdown and 'runlevel 6' for reboot
<wil_syd> ok.. I've got mt-daapd starting at startup. Can you have multiple stop ats ?
<AlexExtreme> yes
<wil_syd> ok.. thanks
<wil_syd> oh.. should have been mutiple stop ons :)
<AlexExtreme> yes ;)
<phlaegel> hi, I'm trying to get upstart to handle my mythfrontend the way I used do it in /etc/inittab (details at http://www.mythtv.org/wiki/index.php/Frontend_Auto_Login), and I'm not sure it's possible yet.
<phlaegel> I've got it mostly working (it starts the frontend, and restarts it if it crashes), but on boot it starts too early (before the mythtv-backend startup).
<phlaegel> Would adding something like 'initctl emit mythtv-started' to the mythtv-backend init script be a way to get it working?
<phlaegel> (and then making the mythfrontend job start on that event...)
<AlexExtreme> yes, that would work
<phlaegel> ok, I'll give that a shot... just wanted to see if that was a good way, or if there was something better. thanks
#upstart 2008-04-15
<stefanDD> hi. can anyone tell me, how the system goes on after doing the initrd scripts?
<stefanDD> hi. is there anyone who can tell me, which script is executed after the initrd-scipt has ended?
#upstart 2008-04-16
<absabs> what's the status of replacement-initscripts
<absabs> http://bazaar.launchpad.net/~keybuk/upstart/replacement-initscripts/changes
<absabs> shows that the latest change is on 2007-02-13
<jyujin> 1;2c1;2c/window 19
<jyujin> sry
<Keybuk> random thought occurred to me the other day
<Keybuk> Upstart runs all processes as session and process group leaders
<Keybuk> (as did sysvinit)
<Keybuk> *but*
<Keybuk> most daemons deliberately try not to be a session or process group leader
<Keybuk> it's annoyingly hard to think of a C filename for the D-Bus code ;)
<ion_> Heh
<ion_> apg is good at generating passwords, perhaps one could use it to generate filenames as well.
<Keybuk> I've been using dbus.c
<Keybuk> but have just spent the morning debugging a bug caused by naming a function the same as one from libdbus
<Keybuk> so clearly I'm going to have to change namespace :p
<ion_> UpstartDBus? A bit long. USDBus? Meh...
<ion_> MyDBus? :-)
<ion_> Rot13 of dbus would be qohf. :-P
#upstart 2008-04-17
<JamesB192> Is there a guide online on using upstart as more than a drop-in sysvinit replacement and if so where?
<Keybuk> JamesB192: not yet, such things will start to appear once 0.5 is out]
<suihkulokki> does there exist recent debian/ubuntu packaging for trunk upstart?
<Keybuk> not at the moment
<Keybuk> though there's no reason the existing packaging wouldn't work
<Keybuk> other than the fact that 0.5 doesn't work yet :p
<ion_> :-)
<suihkulokki> hrmh
<suihkulokki> so trunk is still compatible with 0.3.x jobs, but trunk will not boot anyway
<Keybuk> no, it's not compatible
<Keybuk> in fact, it's the very definition of incompatible, since trunk reverses various defaults ;)
<Keybuk> *sigh*
<Keybuk> the problem with D-Bus, at least it's C bindings anyway, is you have to write so much to get minimum functionality
<suihkulokki> I guess most people are expected to use glib bindings..
<Keybuk> which are nasty :)
<ion_> We could always NIH our own implementation of the protocol. ;-)
<Keybuk> ugh :p
<Keybuk> process 16984: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application.
<Keybuk> *grr*
<Keybuk> so I take it out
<Keybuk> then
<Keybuk> process 16678: dbus_shutdown() called but connections were still live. This probably means the application did not drop all its references to bus connections.
<Keybuk> GRRRRR
<ion_> :-\
<Keybuk> and
<Keybuk> Program received signal SIGPIPE, Broken pipe.
<Keybuk> yet
<Keybuk>  	signal (SIGPIPE, SIG_IGN);
<Keybuk> oh
<Keybuk> wait
<Keybuk> being an idiot
 * Keybuk runs cont
<Keybuk> ok dbus_shutdown is just segfaulting on its own
<soren> Keybuk: I take it you know you should unref, not close connections if they're shared?
<Keybuk> soren: yes
<Keybuk> but how do you make it get rid of its shared connections? :)
<soren> dbus should magically shut it down when the last references is unref'ed?
<Keybuk> it doesn't seem to
<Keybuk> Keybuk: 1 - D-BUs: 0
<ion_> :-)
<Keybuk> Keybuk: 2 - D-Bus: 0
<ion_> And he scooooooreeeeees
<soren> Keybuk: What turned out to be the problem?
<Keybuk> soren: libdbus bugs
#upstart 2008-04-18
<Keybuk> http://people.ubuntu.com/~scott/dbus-1.1.20-exit.patch
<Keybuk> http://people.ubuntu.com/~scott/dbus-1.1.20-bus-addresses-shutdown.patch
<Keybuk> http://people.ubuntu.com/~scott/dbus-1.1.20-shared-connections-shutdown.patch
<ion_> I see you use vim as well. :-)
<Keybuk> vim?
<Keybuk> oh, heh
<Keybuk> I'm strange
<Keybuk> I usually have both vim and emacs open at any one time
<ion_> Don't they try to kill each other in the style of the animation "flash animation fights back"? :-)
<Keybuk> meh
<Keybuk> somewhere along the line, my test case failure for the first patch got lost
<Keybuk> so now it fails by just exiting mid-tests
<Keybuk> Testing nih_dbus_bus()
<Keybuk> ...with session bus
<Keybuk> ...with system bus
<Keybuk> ...with disconnection before registration
<Keybuk> BAD: unexpected exit(), unpatched D-Bus?
<Keybuk> 	at tests/test_dbus.c:369 (test_bus).
<Keybuk> better
<Keybuk> http://bazaar.launchpad.net/~keybuk/libnih/trunk/revision/scott%40netsplit.com-20080418010152-l1gnavvxqqej62jt?start_revid=scott%40netsplit.com-20080418010152-l1gnavvxqqej62jt
<Keybuk> ^ that's the "glue" bit of the D-Bus API committed
<Keybuk> grr
<Keybuk> D-Bus is winning again today
<Keybuk> I don't _quite_ understand what these guids are for yet
<Keybuk> and still have icky valgrind traces from it :p
<Gadi> hi, all.  Is there a way to specify in the event.d file what vt to output to (ie, chvt 3 and exxecutes some program)?
<Gadi> if I do "console output" and then chvt in the script that gets executed, the output still goes to vt1
<Keybuk> Gadi: use a program like openvt
<Gadi> Keybuk: I actually found a way to get what I want by suppressing all rcS/rc2 console msgs with "console none" - I love oneliners
<Gadi> :)
<Keybuk> :-)(
<Keybuk> 0.5 jobs can now have
<Keybuk>   oom killer
<Keybuk> err
<Keybuk>   oom never
<Keybuk> in their definition
<ion_> Great
<Keybuk> pls anything from oom -16 (almost never kill)
<Keybuk> thru to oom +15 (ooh! ooh! kill me! kill me!)
<ion_> How about setting niceness and ioniceness in the job definition as well? (I can't remember whether any of this is implemented already.)
<Keybuk> nice is in there
<Keybuk> ionice isn't though, how do you set that?
<ion_> Well, thereâs ionice(1), but i donât know what it calls.
<Keybuk> ioprio_set
<ion_>        -c     The scheduling class. 1 for real time, 2 for best-effort, 3 for idle.
<ion_>        -n     The scheduling class data. This defines the class data, if the class accepts an argument. For real time and best-effort, 0-7 is valid data.
<ion_> I was thinking of equivalent values in the job description,
<Keybuk> ionice realtime 4
<ion_> Yeah
<Keybuk> of course, there's no prototype for that one yet
<Keybuk> I'll leave that one for now, can you file a wishlist bug to remind me to get to it later?
<ion_> Will do.
<Keybuk> http://rafb.net/p/jkcW3x33.html
<Keybuk> ugh
<Keybuk> heh
<Keybuk> dbus-daemon does it too
<Keybuk> so I'm going to stop caring :p
<ion_> :-)
<Keybuk> I have better things to do than valgrind dbus-daemon and fix their bugs as well as my own :p
<ion_> Heh
<elventear> Is there some source where I can look at all the events that upstart recognizes natively? 
<Keybuk> elventear: events.h
<Keybuk> it's not very many
<elventear> thx
 * Keybuk finishes fixing D-Bus anyway
<Keybuk> (adding another patch to the list)
<Keybuk> in other news, I passed PPL Meteorology today \o/
<ion_> Congrats
#upstart 2008-04-19
<Keybuk> morning
<Keybuk> ion_: around?
 * Keybuk needs to bounce an idea off someone :p
<ion_> keybuk: Yeah
<Keybuk> ion_: so I've been thinking about the whole problem of job environment
<Keybuk> let's use the getty job as an example
<Keybuk>   env SPEED 38400
<Keybuk>   instance $TTY
<Keybuk>   exec /sbin/getty $SPEED $TTY
<Keybuk> we can fire off a couple of these for the system consoles
<Keybuk>   start getty TTY=tty1
<Keybuk>   start getty TTY=tty2
<Keybuk>   start getty TTY=tty3
<Keybuk> and we can figure up one for a slower serial console
<Keybuk>   start getty TTY=ttyS0 SPEED=14400
<Keybuk> environment from the start request overrides that from the job definition, so env sets "defaults"
<Keybuk> so that all works nicely
<Keybuk> now, what happens when another job uses those events
<Keybuk>   start on started getty
<Keybuk> which getty?  there's lots of gettys running
<Keybuk> we do have the INSTANCE variable in that event we could use
<Keybuk>   start on started getty INSTANCE=tty1
<Keybuk> and that happens to work for this
<Keybuk> so using a different example, the dbus session bus daemon service
<Keybuk>   instance $USER
<Keybuk>   exec /sbin/dbus-daemon --session
<Keybuk>   env DBUS_SESSION_BUS_ADDRESS=...
<Keybuk> another job might do
<Keybuk>   start on started dbus-session-bus
<Keybuk> but it doesn't have access to the session bus address
<ion_> Yeah
<Keybuk> since it exists in the job environment of the dbus-session-bus job
<Keybuk> and isn't in the starting/started/stopping/stopped events
<Keybuk> even getty starts to have a useful example
<Keybuk>   start on starting getty TTY=ttyS*
<Keybuk>   exec setserial $TTY $SPEED
<Keybuk> suddenly we have a case where we might want to run setserial if we're starting a getty with a particular $TTY (rather than just instance name) and want the speed
<Keybuk> so I was thinking about adding the whole job environment to the events
<Keybuk> but I don't think that works at all
<Keybuk> in particular, if the job's started on a failed event, any job starting on that would be indistinguishable from the same failed event info
<Keybuk> and it just leads to massive environment creep
<Keybuk> so what I came up with was:
<Keybuk>   env SPEED=38400
<Keybuk>   instance $TTY
<Keybuk>   export TTY SPEED
<Keybuk>   exec /sbin/getty $SPEED $TTY
<Keybuk> ie. a job definition can "export" some of its environment
<Keybuk> and those are the variables that will be added to its starting/started/stopping/stopped events automatically
<ion_> Looks good
<Keybuk> do you think that's better than exporting nothing or exporting everything?
<ion_> Exporting everything would work, too, if the other jobs acting on those events can select what to import instead of having their environment polluted.
<Keybuk> yeah, but I couldn't think of a good syntax from that
<Keybuk> and that would start to mean you need to declare import for everything
<ion_> Yeah
<Keybuk> start on tty-added
<ion_> What you proposed seems good to mee.
<ion_> me
<Keybuk> stop on tty-removed TTY=$TTY
<Keybuk> import TTY from tty-added
<Keybuk> (you'd need the latter to be consistent)
<Keybuk> I kinda like the fact that if you mention an event, you automatically get its environment
<Keybuk> and having consistency between what you can match on and what you can use is nice too
<ion_> Yeah
<Keybuk> of course, _now_ I notice a problem with taking away job ids
<Keybuk> jobs with just "instance" can't be uniquely dealt with
 * Keybuk tries to think of a reason to support unlimited instance jobs
<Keybuk> can't think of a good one
<Keybuk> if people really want them, they can just do something like
<Keybuk> instance $UUID
<Keybuk> start job UUID=$(uuidgen)
<ion_> Yeah
<Keybuk> after racking my brain I can't think of _any_
<Keybuk> if it acts on an event, it needs at least one environment variable to know what to do
<Keybuk> if it acts on a device or path, it can instance on that
<Keybuk> if it writes to the disk, it needs to instance on that path
<Keybuk> etc.
<Keybuk> unlimited instance jobs inherently can't lock anything, or have any side-effects
<Keybuk> and I can't think of anything like that
<ion_> Yeah, i canât think of one either.
<Keybuk> sweet
<Keybuk> I just worked out something that will now work
<Keybuk> assuming that telinit places $RUNLEVEL and $PREVLEVEL in the runlevel event, and sets utmp/wtmp (which is the plan)
<Keybuk> /etc/init/jobs.d/rc:
<Keybuk>     start on runlevel
<Keybuk>     stop on runlevel [!$RUNLEVEL]
<Keybuk>     
<Keybuk>     export RUNLEVEL
<Keybuk>     
<Keybuk>     console owner
<Keybuk>     session leader
<Keybuk>     exec /etc/init.d/rc $RUNLEVEL
<Keybuk> rather than having rc2,3,4,5, etc.
<ion_> Nice
#upstart 2008-04-20
<Keybuk> aha!
<Keybuk> some progress on the binding tool this weekend
<Keybuk> (at some expense in relationship points :p)
<ion_> Hehe
<Keybuk> given http://people.ubuntu.com/~scott/com.netsplit.Nih.Test.xml
<Keybuk> you get
<Keybuk> given http://people.ubuntu.com/~scott/com.netsplit.Nih.Test.h
<Keybuk> given http://people.ubuntu.com/~scott/com.netsplit.Nih.Test.c
<ion_> Great
#upstart 2009-04-14
<Zeqadious> damjan: did those scripts help you?
<pwgen> hi
<pwgen> can someone tell me how i can use the dbus interface on upstart 0.5.1 ? 
<keesj> pwgen: what kind of thing do you want to do?
<keesj> it's all generated code based on the xml files. the xml describes the interface
<pwgen> keesj: i try a dbus call to com.ubuntu.Upstart , but there ist nothing there, how can i find out if upstart is registered ?
<pwgen> or another question . how can i enable DEBUG in upstart 0.5.1 sources ?
<keesj> that's a comiple time option , but what you can to is increase the logging level to quite high (this is also a dbus class)
<pwgen> can i do this by kernel-cmd line or by runtime ? and how ? ..
<keesj> I don't have a running dbus here you should be able to try to type something like this
<keesj> dbus-send --system  --type=method_call --print-reply --dest=com.ubuntu.Upstart /com/ubuntu/Upstart com.ubuntu.Upstart.GetAllJobs
<keesj> initctl log-priority debug (I think)
<pwgen> i tried with mdbus -s com.ubuntu.Upstart and with dbus-inspector . both cann not find com.ubuntu.Upstart .. but ill try it with dbsu-send mompl. 
<keesj> I have not tested this command btw , we don't run the dbus daemon
<pwgen> dbus send result in . ...ServiceUnknown .. (:-(( 
<keesj> dbus equals pain
<pwgen> maybe some probs on initialisation  
<pwgen> but how can i increase the debug level ?
<pwgen> hmm it also says not provided by any .service 
<keesj> didn't the  initctl log-priority debug work?
<keesj> upstart uses syslog to log so you might also need to tweak the verbosity level at the syslog layer
<pwgen> can i send some signals to force reinit ( init -q  ?) 
<keesj> kill 1
<pwgen> and i am runnin on an embedded zaurus with no syslog , logread instead .. 
<pwgen> ahh THX
<keesj> exec /sbin/syslogd -n -C -S -l 8
<keesj> this is what we use a syslog(busybox) (also using logread)
<pwgen> i get some nice logiing info .. 
<keesj>  foreground (-n), small log data (-S), and to shared memory buffer (-C) , using a log level debug (-l 8)
<keesj> pwgen: using oe?
<pwgen> "daemon.debug init: job_class_register: Registered job /com/ubuntu/Upstart/jobs/tty4" lots  of this for all job files .. but still no com.ubutuUpstart .(:-((
<pwgen> yes oe with extra  patch to disable oom writing on booting , while there is no oom ... 
<pwgen> yes oe with extra  patch to disable oom writing on booting , while there is no /proc
<pwgen> but my package may not ship the .service file ( /usr/share/dbus-1/com.ubutu.Upstart.service is not there )
<keesj> I have also a patch to configure the log level in /etc/init.d/init.conf and to fix dbus naming(neither was accepted here) but the future of upstart is unclear if you ask me
<keesj> I replaced init with a shell init script that mounts /proc and performs a exec upstart
<pwgen> hmm that may be another workaround . 
<pwgen> where in the source is the .service file ? 
<pwgen> or what will be executed ( init ? ) for example:  Exec=/usr/sbin/init ?
#upstart 2009-04-15
<Zeqadious> does "start on stopped job ok" still work?
<Zeqadious> I ask because it doesn't seem to here
<sadmac2> Zeqadious: version?
<Zeqadious> 0.5.1
<sadmac2> Zeqadious: start on stopped job RESULT=ok
<Zeqadious> sweet
<Zeqadious> whats the other RESULT?
<Zeqadious> RESULT=failed?
<Keybuk> surprisingly
<sadmac2> Zeqadious: although I'd think that would still work... maybe its changed a bit. There's a way
<sadmac2> other result was failed I think
<Zeqadious> ok
<Keybuk> you can also just shortcut RESULT=failed and just check EXIT_STATUS=* or something
<Zeqadious> I removed all the ok's 
<Zeqadious> i'll put them back now
<Keybuk> start on stopped job EXIT_SIGNAL=11 etc.
 * sadmac2 tries to imagine the task you want to run on segfault and nowhere else
<Keybuk> start on stopped EXIT_SIGNAL=11
<Keybuk> exec apport-auto-file $JOB
<sadmac2> Keybuk: wouldn't you want SIGABRT in there too?
<sadmac2> also SIGILL, SIGFPE, possibly SIGPIPE
<Zeqadious> hmmm "start on started udev-daemon RESULT=ok" should work right?
<sadmac2> it should
<sadmac2> unless it became OK or something like that.
 * sadmac2 doesn't have the code in front of him to check on these things
<Zeqadious> i'll try that..
<Zeqadious> fsck comes after that, but its not starting for some reason 
<sadmac2> Zeqadious: you could do a start on started udev-daemon and then in the job definition do an export > /tmp/somefile and then look at somefile and see what its getting set to
<Zeqadious> export what though?
<Zeqadious> export RESULT > /tmp/$job.result ?
<Zeqadious> oops
<Zeqadious> $RESULT
<sadmac2> Zeqadious: I meant set
<sadmac2> Zeqadious: no arguments
 * sadmac2 begins to realize how many ways unix has to list all the environment variables
<Zeqadious> env
<sadmac2> set does it too
<Zeqadious> really?
<sadmac2> export I think does a superset of it
<sadmac2> yes
<Zeqadious> never tried that
<Zeqadious> so it does
<Zeqadious> i'll check the result now
<Zeqadious> lol, forgot that before fsck the fs is ro
<sadmac2> hmm. just echo it then. stdout should display it
<Zeqadious> yep
<Zeqadious> well it has no result really
<sadmac2> the environment should be small
<Zeqadious> at least there is no variable called RESULT
<Zeqadious> it is
<Zeqadious> UPSTART_EVENTS=started
<Zeqadious> closest thing i can find
<sadmac2> odd
<Zeqadious> is this the correct way to use the expressions with the start on stanza http://zeqadious.homelinux.net/junkbin/upstart-0.5.1-jobs/sysinit/save-dmesg ?
<sadmac2> Zeqadious: maybe... what do you think that will do?'
<Zeqadious> I think it should start when all conditions inside ( ) are met
<Zeqadious> but i may not need the ( ) 
<sadmac2> Zeqadious: they aren't conditions. They're events. It will start when all the things inside () /happen/
<sadmac2> and you need either the \s or the ()s, not both
<Zeqadious> oh?
<sadmac2> oh.
<Zeqadious> it won't tell me that there are unknown stanzas when it sees  and started sysinit/cleanup RESULT=ok on a line all by itself?
<sadmac2> Zeqadious: it assumes the line continues until the closing parenthesis
<Zeqadious> thats great
<Zeqadious> looks a lot nicer 
<Zeqadious> well that doesn't seem to work right. that job never starts and afaik those other jobs are all RESULT=ok
<sadmac2> Zeqadious: are all of them started in the first place?
<Zeqadious> yes
<sadmac2> ok. that's the usual reason these things break...
<Zeqadious> hardest part i'm finding with these upstart scripts is trying to make them robust enough to deal possible breaks
<sadmac2> example?
<Zeqadious> i'm having issues with fsck script for example.  its silently hangs quite often and I can't seem to track why or when.  or like when some script may fail but won't report a failure and so my save-dmesg script never runs but i can't see why :)
<sadmac2> first one sounds like an fsck issue
<Zeqadious> probably
<Zeqadious> aha
<Zeqadious> status job should return something right?
<sadmac> I think so
<sadmac> yes. the manpage confirms
<sadmac> initctl status job
<sadmac> (there's no symlink for status, I don't think)
<Zeqadious> initctl status job returns nothing too
<Zeqadious> it should shouldn't it?
<sadmac> on 0.5 it might only if the job is running
<Zeqadious> returns nothing if the job is running
<Zeqadious> returns nothing if the job isn't running too
<sadmac> weeeeird
<sadmac> what does it return with no argument?
<Zeqadious> I think the problem this indicates is what is making it so difficult for me to write the scripts.  RESULT=ok for any respawning service doesn't work 
<Zeqadious> initctl status returns all jobs with either running or not running
<sadmac> ok, so that works
<sadmac> ah, so the respawn flag kills the RESULT variable
<sadmac> bug.
<Zeqadious> aha
<Zeqadious> also my scripts are all in directories inside jobs.d like jobs.d/service/hald so the job is service/hald
<Zeqadious> but because of the mangle bug status service/hald returns nothing
<Zeqadious> just found that status service_2fhald works though
<sadmac> yeah. that's not a new one.
<Zeqadious> yeah i saw that one in the bug list
<Zeqadious> this is just the first instance where i had to type the mangled form in to get it to work
<keesj> respawn is broken in many ways in 0.5
<Zeqadious> well i filed a bug
<Zeqadious> 5pm works out.  thanks for the help all, i'm going home.
#upstart 2009-04-16
<ion_> gg, my ISP silently took 191,70 â¬ from my bank account. Having some money to buy food would be nice. :-P
#upstart 2009-04-17
<pwgen> hi
<Keybuk> hi
<pwgen> upstart can read some init.conf. are there sample for this file or have i read the code to find out hot to configure upstart ?
<Keybuk> there is no init.conf
<pwgen> i am on version 0.5.1 . 
<Keybuk> pwgen: http://upstart.ubuntu.com/getting-started.html
<pwgen> 0.3.9 examples should also work with 0.5.1 ?
<Keybuk> with some tweaking
<pwgen> and the most important question , how  do i get the upstart connected to dbus-daemon ? 
<Keybuk> chicken-and-egg right now ;)
<pwgen> i have a running openembedded ( zaurus )  with upstart 0.5.1 and a systembus script, that starts dbus , but i have only org.freedesktop.DBus runnung no com.ubutu.upstart ..
<Keybuk> just connect the tools directly to upstart
<Keybuk> it has its own socket
<pwgen> how can i connect the tools directly ? 
<pwgen> and how to increase debug level ? 
<Keybuk> DBUS_SYSTEM_BUS_ADDRESS=unix:abstract=/com/ubuntu/Upstart dbus-send --system...
<Keybuk> --debug
<pwgen> i have a dbus daemon running/started  by upstart , so i can do dbus calls, but the upstart isn't registered  at the daemon, so i can try sending to com.ubuntu.Upstart, but there will neve be an answer because upstart is not registered ..(:-((
<pwgen> will there be  in future support for dbus ? or will this part of development stalled ?
<Keybuk> Upstart communicates using the D-Bus protocol
<Keybuk> you just have to connect to it
<Keybuk> it doesn't communicate through the bus daemon yet
<pwgen> ok i have to leave now ... until later ...
<pwgen> back
<pwgen> Keybuk: i tried dbus-send --system --print-reply --type=method_call --dest=com.ubuntu.Upstart / com.ubuntu.Upstart.GetVersion -> res .. was not provided my any service file ..(:-((
<Keybuk> did you set the environment variable first?
<pwgen> no ..  pleas can you paste the env again . i am on a different irc client  
<Keybuk> <Keybuk> DBUS_SYSTEM_BUS_ADDRESS=unix:abstract=/com/ubuntu/Upstart dbus-send --system...
<pwgen> thx
<pwgen> result with setting the env is: failed to connect to  to socket /com/... connection refused 
<Keybuk> you sure you're running 0.5?
<pwgen> 0.5.1 
<Keybuk> netstat -an | pastebinit
<ion_> pastebinit â¥
<pwgen> "unix 2 [ACC ] STREAM LISTENING 21 1/init " and 2 dbus-daemons are listening on unix sockets
<pwgen> ahh, upstart is listening on /com/ubuntu/upstart with small "U"  
<Keybuk> oh, heh
<pwgen> but i got : Failed to open ... .. Method "helo" with signature "" on interface org.freedesktop.DBus  doesn't exist 
<pwgen> s/helo/Hello/
<pwgen> the dbus-send is getting to the init .. when i increase the loglevel with initctl log-priority debug i get output from the init ..
<Keybuk> oh, you might not be able to use dbus-send :-/
<pwgen> i can send to the org.freedesktop.DBus.GetId and get a result ( string "numeric id" )
<sadmac2> Lennart wants to get rid of /usr and put everything in /
<ion_> ++
<sadmac2> the traditionalist in me is fighting it, but I did always sense some duplicity in the FHS
<Keybuk> ++
<Keybuk> /Libraries
<Keybuk> /System
<sadmac2> intriguing. We'll see if he can hammer it through.
<Keybuk> someone will go "won't SOMEBODY think of the RHEL!" and it will all end
<sadmac2> Keybuk: it says a lot about me that I dislike /Libraries for aesthetic reasons :)
<Keybuk> you don't like the capital L ? :)
<sadmac2> too user friendly
<sadmac2> computers stop being sexy when they stop being intimidating
<ion_> As long as our filesystem is case-sensitive, no capital letters, please.
<Keybuk> does the same apply to women?
<pwgen> hmm moving to / will overwrite /sbin/init with upstart init , and that will be interesting because a lot of  packages need init ( sysV)
<sadmac2> Keybuk: depends on the woman :)
<pwgen> Keybuk: http://pastebin.com/m5e4d1b8c netstat and loginfo 
<sadmac2> git bisect â¥
<Keybuk> pwgen: looks fine to me
<Keybuk> pwgen: initctl works, right?
<pwgen> yupp i could change the loglevel by initctl 
<Keybuk> pwgen: then it works
<Keybuk> initctl talks D-Bus over that socket
<pwgen> ahhh 
<ion_> sadmac: Yeah, bisect ftw.
<pwgen> for my understanding  upstart provides its own dbus daemon, listening on /com/ubuntu/upstart , 
<sadmac2> pwgen: upstart doesn't provide a dbus daemon. Its just an endpoint
<pwgen> ok by setting the env to /com.ubuntu.. i can make a direct call to its interface , initctl use this direc call, but how can i make a call using the dbus daemon ?
<sadmac2> pwgen: as of now you can't unless you start dbus in initrd (please don't)
<pwgen> embedded system here , with no initrd .   So , there is no way of using python-dbus to call to upstart and do some actions , i am right ?
<sadmac2> pwgen: python dbus should be able to do the same sort of direct connect... I'd expect anyway
<pwgen> bus = dbus.SystemBus() is failing  with "UnknownMethod: Method "Hello" with signature "" on interface "org.freedesktop.DBus" doesn't exist"
<sadmac2> pwgen: right, you won't do that.
<sadmac2> you'll need some other call
<pwgen> so i have to use a binary wrapper to do upstart dbus calls .
<sadmac2> no. you have to use the python api differently
<pwgen> do have some sample or docs about that ?
<sadmac2> I don't
#upstart 2009-04-18
<damjan> yey, success, first boot of ArchLinux with upstart :)
<damjan> if I have "start on xxx" in a job, how do I make it start? initctl emit xxx ?
<damjan> well, actually I have "stop on xxx"
<damjan> hmm.. got it.. I had more than one "stop on ..." seems only the last was honoured
#upstart 2010-04-20
<Caesar> Oh Keybuk...
<mbiebl> Keybuk: around?
<sadmac> Keybuk: well since you're so popular in the last 5 minutes, I want to talk to you too :)
<JanC> lol
<Keybuk> Caesar: hey
<Caesar> Keybuk: I think I figured out the answer to my question
<Caesar> It was something along the lines of "don't do that" :-)
<Keybuk> what was your question OOI?
<Caesar> Keybuk: I was trying to write an Upstart job that would DWIM on Hardy and Lucid
<Caesar> Then I remembered /etc/event.d vs /etc/init, so the probably all became rather moot
<Caesar> I guess my meta-question is does Lucid's Upstart only accept a single "start on"/"stop on" line in the job file, whereas Hardy's would handle multiples?
<Keybuk> ah
<Keybuk> yeah
<Keybuk> Hardy's OR'd them together and had no support for AND
<Caesar> Ah
<Caesar> Change is such a PITA
<Keybuk> Lucid supports "and" & "or" as explicit operators
<Caesar> Yeah, found that in init(5)
<Caesar> Couldn't find much about the job spec in Hardy
#upstart 2010-04-21
<Keybuk> mbiebl, sadmac: what did you two want anyway? :)
<sadmac> Keybuk: I just wanted in on the joke ;)
<Keybuk> sadmac: I hate you
<sadmac> Keybuk: good. Hate keeps a man alive
<Keybuk> :D
<Keybuk> sadmac: I thought of you when I was j/o earlier
<Keybuk> no, wait, that's not what I mean
<Keybuk> I thought of you when I filed https://bugs.launchpad.net/upstart/+bug/567691
<sadmac> Keybuk: go far enough west of my location and they'll hang you for comments like that. Or south. Or east. Really anywhere a bit further from downtown Raleigh...
<sadmac> Keybuk: here it only makes my penis harder... no wait... 
<Keybuk> they'd probably hang me in downtown Raleigh too
<Keybuk> but ironically
<sadmac> Keybuk: they'd kill you as an example of what less tolerant people might have done.
<Keybuk> also https://bugs.launchpad.net/upstart/+bug/567693
<Keybuk> Caesar will like that one
<sadmac> Keybuk: /etc/sysconfig is...something else.
<Keybuk> is it?
<Keybuk> what do you use for that kind of thing?
<sadmac> Keybuk: its any sort of configuration that is parsed and put into effect directly by init scripts. Usually that ends up being environment variable formatted for ease, but it also has, for example, iptables rules
<sadmac> Keybuk: also the definition has gotten loser as other parts of the system have had to parse things in there (networkmanager for example)
<sadmac> Keybuk: actually now that I read the ticket again it is effectively the same thing. The analogy I drew at first was more to rc.local
<sadmac> which is something else entirely
<Keybuk> right
<Keybuk> so I was right ;)
<Keybuk> we use /etc/default for that
<Keybuk> but I've been persuaded by everyone (including you) that Upstart needs an equivalent
<Keybuk> except it'd be an empty-by-default directory
<sadmac> Keybuk: ugly, nasty thing to implement
<sadmac> once I finally get out from under this parser thing I need to set up an upstart-next branch on launchpad and make with the gutting.
 * Caesar likes https://bugs.launchpad.net/upstart/+bug/567693
<Keybuk> sadmac: so, I'm confused; did Upstart make it into RHEL 6 or not?
<sadmac> Keybuk: yep. its in there.
<Keybuk> ah, I see it mentioned in "Discontinued Packages"
<Keybuk> which version went in?
<sadmac> Keybuk: 0.6
<Keybuk> \o/
<Keybuk> phew
<sadmac> Keybuk: you're saying phew. I'm the only person in RH's support organization who understand's Upstart
<Keybuk> ;-)
<Keybuk> yeah
<Keybuk> because it makes getting LSB on board MUCH EASIER
<Keybuk> I was fearing you shipping 0.3 - it would have put back LSB adoption of Upstart to after RHEL 7
<sadmac> is LSB still relevant?
<sadmac> the attitude of the public on that subject seems to shift a lot.
<Keybuk> it's relevant to killing off init scripts
<Keybuk> since the LSB still mandates them
<sadmac> though if they follow RHEL they might use 0.6 as the standard, which is slightly undesirable.
<Keybuk> sure, but 0.6 in RHEL now means we can at least start moving
<sadmac> true
<sadmac> and if we actually manage this backward compatibility stunt we might be able to coax 0.10/1.0 into 6.x
<Keybuk> that was the idea ;-)
<sadmac> KVM went in in a minor. I don't see why we couldn't.
<Keybuk> I *really* intend that to work; you should be able to update Upstart on RHEL 6 or Ubuntu 10.04 LTS and things should carry on working
 * sadmac is glad plautrba gets to deal with the problems in the meantime.
<notting> kvm probably had a bit more customer demand 
<sadmac> notting: I thought it was more engineering bile. I always figured we did it so we could hope to push the customers of xen and kill it dead that much sooner.
<sadmac> cuz, y'know, xen sucks
<JanC> you mean, xen is owned by a competitor?  ;)
<sadmac> JanC: no. I mean xen sucks.
<ilmari> that's why rh didn't buy them?
<JanC> at least it sucks less than hyper-v -- I mean, it actually works  ;)
<wasabi_> So that's pretty neat. It's cool to see something that I spent so much mental effort thinking about make it into RHEL.
<wasabi_> Rock on fellows.
#upstart 2010-04-22
<markl_> how do i launch upstart?  do i need to tell the kernel to run upstart instead of init?
<markl_> trying to make openvz play nice with upstart.  i am ending up with a run level of UNKNOWN because there is no inittab on this ubuntu 10.04 vm
<markl_> ah ok upstart provides /sbin/init.  ok now i am really sad
<wasabi_> why sad?
<markl_> because it is ending up at runlevel unknown and i'm not sure what to check next
<markl_> but at least i get plymouthd :)
<markl_> w00t
<markl_> is there a way to get logging out of upstart's init?
<markl_> since it isn't launching syslog
<markl_> init 2 seems to at least do something
<sadmac> markl_: you could go into /etc/init.d/rc and set a default runlevel
<sadmac> markl_: normally that file gets it out of inittab
<sadmac> markl_: but ultimately this is an ubuntu question not an upstart question
<markl_> sadmac: yeah this problem will overlap 3 different projects, upstart, ubuntu, openvz.  fun stuff!
<markl_> sadmac: is there a good faq that covers this kind of thing?
<sadmac> markl_: not exactly. there's manpages etc. There's more documentation than it seems, but its not terribly easy to index a lot of the time.
<sadmac> markl_: mostly the manpages though.
<markl_> my main question is why rc-sysinit.conf isn't setting it
<markl_> isn't that the correct place to set the default runlevel?
<sadmac> markl_: thats an ubuntu decision
<markl_> ok let's pretend as a mental exercise that i'm creating my own distro and i want to use upstart; what would the best way be to set it?
<sadmac> markl_: that begs the question: do you even want to have runlevels?
<markl_> for bootup
<markl_> yes i would prefer them
<markl_> it was my understanding that the kernel runs init, which will start with rc-sysinint.conf
<markl_> kind of like how the old init started with inittab
<sadmac> markl_: runlevels are the way sysv does it. upstart doesn't have them "by default." You can use specific configuration and some brute force to *simulate* them, and upstart ships some tools that will deal with utmp and stuff like that to make it easier, but they aren't stock and the init daemon itself doesn't understand them.
<markl_> is this what ubuntu does?
<sadmac> markl_: yep. Fedora does it too, but the implementations are slightly different.
<markl_> of course :)
<JanC> I suppose other upstart-users like android probably don't use runlevels
<sadmac> I'd have to look but I'd bet not
<sadmac> markl_: so when upstart starts, it emits the "startup" event, thus triggering anything that has "start on startup" in its conf file.
<markl_> this is specifically an ubuntu problem; it runs init and starts up but without a runlevel.  ideally it would be cool if init had its own log file or something
<sadmac> markl_: rc-sysinit.conf would be one of those I'd imagine
<markl_> so if my event.d directory is empty, is that a bad sign?
<sadmac> markl_: it'll log to syslog, or console if that's not around.
<markl_> no console
<sadmac> markl_: ...depends on the version of upstart. newere upstarts use /etc/init.d
<sadmac> (0.6 and later)
<markl_> 0.6.5-4
<sadmac> yeah, then I'm surprised you have an event.d
<markl_> ok maybe the page i found with google was outdated
<sadmac> almost certainly
<markl_> well it includes a script to convert inittab to upstart
<sadmac> upstart doesn't have any support for inittab, but most configurations that emulate sysvinit will parse bits of inittab for compatibility stuff. just the default runlevel in fedora's case
<markl_> ok thanks, this is very helpful
<JanC> newer versiosn use /etc/init/ (not init.d !)
<sadmac> then rc-sysinit.conf or rc.conf or whatever the job is that does that parsing on ubuntu sets the runlevel and runs /etc/rc (which is the same thing it was in sysvinit. just a bash script for rulevel transitioning)
<sadmac> JanC: right. my fault.
<sadmac> and that's how most distros build their sysv layer.
<markl_> i have both /etc/init and /etc/init.d.
<sadmac> markl_: yeah, init.d is something else :)
<sadmac> init.d contains all the sysvinit scripts
<JanC> init.d is for sysvinit scripts that get run by the sysvinit compatibility stuff
<sadmac> (so not really an upstart thing per se. sysvinit holdover)
<markl_> ok cool, thanks for being so tolerant of 100% total n00b questions :)
<JanC> markl_: you might want to read "man 5 init"
<markl_> hmm, so rc-sysinit isn't a script as such, is it?
<markl_> if i just remove /dev/console, will it create a log file for me?
<sadmac> markl_: no
<sadmac> markl_: advise serial console
<markl_> no serial ports
<sadmac> markl_: start syslog earlier then
<markl_> this is a vm, there is no console at all.  i need a way to write to a file to see why it is ignoring rc-sysinit.conf
<JanC> you can get a serial console over USB too of course
 * sadmac 's virtual machines all have consoles...
<sadmac> serial or video...
<JanC> (USB is a serial port)
<JanC> openvz doesn't use a virtual machine AFAIK, but uses some container-like technology?
<JanC> they probably implemented something similar though
<markl_> yes it basically starts init in a chroot
<markl_> but with lots of fun kernel mods to control memory etc better
<markl_> and the vm's typically run without getty or any sort of console
<markl_> kind of like driving a stick whereas the other vm's are an automatic
<JanC> markl_: AFAIK something similar ('lc' or "linux containers") is being implemented in the mainline kernel nowadays
<markl_> yeah, the main gripe with VZ is that their kernel patch is gigantic with no hope of linus accepting it all
<markl_> so they are moving things into the main kernel as time goes on, which lxc is trying to use
<JanC> the LC people did cut up their patches in small chunks for linus to approve one by one  ;)
<markl_> yep, smart move
<JanC> or lxc
<markl_> i'm glad that parallels is getting openvz out for 2.6.32 (rhel6, ubuntu 10.04, debian squeeze)
<markl_> this may be silly but i'm trying to create a 10.04 template so i can get the kernel patch to work on ubuntu's lucid kernel
<markl_> kind of a chicken & egg problem at the moment
<JanC> markl_: about the upstart problem, you can try to log stuff yourself
<JanC> add some "echo blah >> logfile" stuff in the job configs
<markl_> ok i'll give that a try.  it actually boots up and I can do: init 2
<markl_> so i'm really close
<diegows> hi
<diegows> is there a way to execute an event on reboot/shutdown with upstart? I need to execute a script on reboot/shutdown before anything else (for example, before killing the xsession_
<diegows> )
<JanC> diegows: before killing the X-session, why not do that with X session-management then?
<diegows> I haven't found the right place to do that
<diegows> gdm executes script on PostSession but X is killed before
<diegows> and with upstart is a more generic solution i think
<JanC> on most systems, X is started by gdm, not by upstart...
<diegows> aha
<JanC> maybe this is useful: http://en.wikipedia.org/wiki/X_session_manager  ;)
<diegows> that's ok
<diegows> but something is killing gdm/X and i'm sure is upstart who is doing that
<diegows> so it should have a place to put an script before that event
<Keybuk> "on stopping gdm" ?
<diegows> i think I tried that and didn't work
<diegows> but i'll try again 
<diegows> just in case
<diegows> :-_
<JanC> that will start after X is stopped I assume?
<Keybuk> that will start before gdm is stopped
<JanC> he want to run something before X is stopped, so I suggested using X session management  ;)
<diegows> yeah, but X sessino mgmt doesn't have a place to insert a script before logout
<Caesar> Hey Keybuk wanna hear something funny
<Keybuk> Caesar: sure
<Caesar> It's not so funny now
<Caesar> But it was at the time
<Caesar> We have a custom rsyslog package that (currently) doesn't have an upstart job
<Caesar> And we default to confold for everything
<Caesar> So we had to get the preinst to remove the Ubuntu rsyslog's upstart job
<Caesar> But that didn't get the idea of the job out of Upstart's head
<Caesar> So I kept trying to kill it, but it kept coming back
<Keybuk> right
<Keybuk> Upstart won't forget about it until you stop it ;)
<Caesar> the stop command has a good time when upstart knows about the job, but there's no job file
<Caesar> stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
<Keybuk> huh that doesn't make sense
<Keybuk> if Upstart is respawning, it should still have an object
<Keybuk> just tested that here, and it worked
<Caesar> Hmm
<Caesar> I can only report what I was seeing
 * Caesar longs for Puppet to become knowledgable of Upstart
<Keybuk> :)
#upstart 2010-04-23
<Caesar> Hey Keybuk so what is the expected behaviour when an Upstart job gets removed?
<Caesar> i.e. unlinked
<Keybuk> depends
<Keybuk> is the job still running?
<markl_> should rc-sysinit.conf start on startup?
<markl_> mine says start on filesystem and net-device-up IFACE=lo
<markl_> i'll bet this is why i'm not getting a runlevel, the filesystem part is "failing"
<sadmac> markl_: fix the filesystem part
<markl_> what if i use mount -a instead of mountall --daemon?  
<markl_> mountall seems to be failing badly
<sadmac> markl_: you should debug mountall. Keybuk and ion are probably the only two people in the world qualified to speak on it.
<Keybuk> change the exec line in /etc/init/mountall.conf to have --debug
<Keybuk> what error message do you see on the splash screen?
<Keybuk> it should let you skip the failing filesystems or drop to a shell
<markl_> heh
<Keybuk> sadmac: slangasek knows the code as well ;)
<markl_> well it's a little more complicated than that; i'm making an openvz template.  which means no console at all; i really need to get upstart to write its debug info to a file
<Keybuk> oh
<Keybuk> upgrade your kernel
<Keybuk> 10.04 LTS needs 2.6.32 minimum
<Keybuk> mountall isn't the only thing that will fail with an earlier version, it's just the first thing that you hit
<Keybuk> mountall, upstart, udev, ureadahead, libdrm, X, plymouth, etc.  all depend on features not found in older kernels
<markl_> ah fun
<Keybuk> (and yes, I know OpenVZ is a huge pile of messy patches and there's no newer kernel version for it - I consider this an OpenVZ problem - and not the only problem with OpenVZ either)
<markl_> what are some of the others, just out of curiosity?
<Keybuk> the fact the kernel has several well known security vulnerabilities?
<Keybuk> the fact it doesn't provide a POSIX userland?
<markl_> do you have info on the current vulnerabilities?  they typically keep up with the red hat kernels
<markl_> not a whole lot on google about it
<markl_> except hypervm, lots about that
<sadmac> markl_: why not kvm or linux containers then?
<markl_> maybe some day, openvz is just too cool and mature.
<markl_> i like the efficiency, and lxc is just not usable yet
<markl_> it does suck that the vz kernel patch is so massive that linus would never accept it
<markl_> isn't kvm like xen?  where you have to boot up a whole new kernel?
<sadmac> markl_: yes. what's the problem?
<markl_> http://www.hpl.hp.com/techreports/2007/HPL-2007-59R1.html
<sadmac> ok
<markl_> http://www.brianmadden.com/blogs/videos/archive/2009/08/20/Hypervisors-vs.-OS-Virtualization-Smackdown_2C00_-a-video-from-BriForum-2009.aspx
<markl_> xen-like systems are good when you don't care about efficiency
<markl_> but if you need a console, or to mix different operating systems, then it is necessary
<sadmac> markl_: that's a strong statement
<sadmac> markl_: I can tell you that 5% overhead is usually expected on the RHEL virt stack
<markl_> plus a ton of wasted memory
<sadmac> not for long
<sadmac> the page de-duplication stuff should fix that
<markl_> yeah, i use it when i need to bring up a windows machine, it is cool for that
<sadmac> what do you need all these containers for then?
<markl_> i keep each service on its own vm; test environments, different build enviroments for different clients
<markl_> i can still use different distros at least
<markl_> and it's great for bringing up a new vm quickly, since installing is just a tar command (or snapshot if you use a san)
<sadmac> that applies to most virt technologies
<sadmac> (well, not a tar command, but san snapshotting or copying the image file)
<markl_> give it a try next time you are bored and looking for a toy to play with
<markl_> one guy in the channel had like 1000 vm's going on his machine 
<markl_> hosting companies have been using it most over the past years
<markl_> anyway, a real upstart question; should i be able to put "echo" in the script/end script section of one of the .conf files?
<markl_> e.g. instead of mountall
<markl_> e.g. echo "foo" > /tmp/foo
<markl_> ok that seems to work.  plymouth starts up but that is the only service
<sadmac> markl_: from what Keybuk just said I doubt this will ever work, or that it will make your life easier once it does.
<sadmac> markl_: unless you want to forward port it might be time to look for an older OS or a different container system
<markl_> this is a fun way to at least get familiar with upstart.  how does "emits" work?  it looks like many of these scripts seem to do an exec
<sadmac> markl_: emits means a job may emit other events by way of its scripts. I think its used to prevent some odd races but in general its just nice to let upstart know.
<Keybuk> emits doesn't do anything
<Keybuk> it's just documentation
<Keybuk> there so you can run perl over /etc/init and make dotty
<sadmac> Keybuk: ah. didn't it prevent some sort of potential hang at one point?
<Keybuk> no
<Keybuk> markl_: I have the OpenVZ guys some hints for getting an "ubuntu lite" booted on it over 6 months ago
<Keybuk> s/have/gave/
<markl_> they are way too into rhel/centos unfortunately
<Keybuk> RHEL 6 uses Upstart
<Keybuk> and tbh, it's not Upstart that's the issue here
<markl_> cool
<Keybuk> it's De-HALificiation
<Keybuk> the kernel feature that let us remove HAL was only added in recent releases
<Keybuk> so any distro without HAL is going to hit the exact same error you hit
<Keybuk> (iirc. mountall fails because of an assertion error opening a "udev" netlink socket?)
<markl_> well the question i have is that rc-sysinit is waiting for "filesystem"
<markl_> does that mean that whatever mountall.conf execs has to return a 0 code?
<markl_> so that the "emits filesystem" happens
<markl_> ?
<Keybuk> no, whatever mountall.conf execs has to communicate with Upstart via D-Bus and ask for a "filesystem" event to be emitted
<Keybuk> ignore the "emits" lines
<Keybuk> (upstart does)
<Keybuk> they mean as much as the "author" and "description" lines ;)
<markl_> ah ok gotcha
<Keybuk> usually replacing mountall.conf with something like
<Keybuk> script
<Keybuk>   initctl emit virtual-fielsystems
<Keybuk>   initctl emit loacl-filesystems
<Keybuk>   initctl emit remote-filesystems
<Keybuk>   initctl emit all-swaps
<Keybuk>   initctl emit all-filesystem
<Keybuk> end script
<Keybuk> does most of the job
<markl_> ok looks like i need to read up on initctl, ty!!
<Keybuk> (but with better spelling)
<markl_> heh
<Keybuk> but you also need to obviously mount things
<Keybuk> mount -a will probably work inside a vz, since you don't have to wait for the hardware
<markl_> yeah i just need /proc
<Keybuk> though bear in mind you need everything from /lib/init/fstab as well
<markl_> ok cool, good to know
<Keybuk> that should at least get you up to getty ;-)
<markl_> does anything read /lib/init/fstab or is it there for documentation?
<markl_> heh :)
<markl_> i think i could do what i need now if i ifup the network and start ssh by hand.  but that would be taking the easy way out :)
<markl_> hmm, when i try to execute mount it bombs out of the mountall.conf
<markl_> is there a restriction on what commands i can run in there?
<markl_> ah, i see!  if you execute a command that doesn't return a 0, upstart will stop executing your script
<markl_> hmm well /proc is already mounted before mountall is even called
<markl_> so i'll just make a mountall_vz.conf that does what you suggested up there.
<markl_> i am not a fan of PFM
<markl_> how important are "expect daemon" and "task"
<markl_> and does "initctl emit" require a dbus process?  it looks like 10.04 doesn't install any sort of dbus
<markl_> hmm: # initctl emit virtual-filesystems
<markl_> initctl: Event failed
<markl_> ok on that note, bed time
<markl_> morning
<markl_> does initctl without --system require the lo interface to be up?
<markl_> also, what does it mean if initctl freezes when doing something like: initctl emit filesystem
<markl_> ok i'm starting to dig into the source to figure out "initctl: Event failed".  Does this mean that the init process sent back a response?  How can I get details on why it failed?
<sadmac> markl_: it means that the event was supposed to make some job start, and that job failed to start'
<markl_> ah ok so it is not just delivering the event notification, it actually gets a result back.  cool
<markl_> ok how does the init process know what to do with an event named "filesystem" ?
<markl_> does it just run all of the confs that are set to start on filesystem?
<Keybuk> yes
<markl_> Keybuk/sadmac: good morning, long time no chat!
<markl_> what time zone are you guys in?
<Keybuk> markl_: I'm in US/Pacific at the moment; normally UK though
<markl_> cool, i live in utah, not too far away
<markl_> no ocean in between, at least
<markl_> it is interesting that your election is getting so much coverage over here
<jMCg> A couple of months ago I talked with @developer about upstart and Linux Capabilities. Now I run into pam_cap -- since doing a quick and dirty hack with su/sudo wouldn't do it: http://dpaste.com/186954/ -- I was wondering how the plan to implement caps in upstart looks exactly, since this pam_caps seems like an easy way around...
<Keybuk> there isn't a plan
<Keybuk> that isn't to say there couldn't be a plan
<sadmac> Keybuk: in frisco again?
<Keybuk> sadmac: I'm in SF yes
<sadmac> Keybuk: you seem to get over there an awful lot
<Keybuk> part of the job
<ion> keybuk: Do you know whether youâll get more time for Upstart in the next cycle?
<Keybuk> ion: I can't see how I could possibly get any *more* time for Upstart in the next cycle
<Keybuk> since I've arranged to be 100% working on Upstart for it
<ion> Heh
 * sadmac can't get the caffene into his head any faster
<sadmac> I don't remember the last time I was awake
<sadmac> Keybuk: what's in SF that Canonical keeps sending you to go see?
<Keybuk> sadmac: this visit was the Linux Foundation Collaboration Summit
<Keybuk> that was last week
<Keybuk> then there was a volcano
<Keybuk> so now I'm not going home until the 29th April
<sadmac> Keybuk: not into ash?
<Keybuk> I avoid cloud wherever possible ;)
<sadmac> Keybuk: I'm going be in SF in late June I think.
<sadmac> Keybuk: perhaps you'll find a reason to be there as well. There MAY be auto racing, and I MAY be dressed as The Stig. No promises.
<Keybuk> lol
<jMCg> There, I added a rant on lunchpad... Or dinnerpad..mmm...
<jMCg> https://answers.launchpad.net/upstart/+question/45946
<Keybuk> a rant on twitter is usually equally effective
<Keybuk> as is shouting into the wind on a rainy winter's night
<Keybuk> (I don't think anyone reads answers.lp.net :p)
<Keybuk> jMCg: https://bugs.edge.launchpad.net/upstart/+filebug
<markl_> if i want to register an event "foo" in /etc/init, do i just add a "start on foo" line?
<markl_> appears to work this time, ok cool
<markl_> ok what is the point of plymouth, just to show a fancy graphical screen on bootup?
#upstart 2010-04-24
<ion> It handles multiple programs wanting to interact with the user simultaneously.
<markl_> ion: i see, hopefully i can dpkg -r it
<ion> Sure, if youâre willing to remove mountall along with it, and upstart along with mountall. Assuming youâre running Ubuntu.
<markl_> i don't need mountall but apparently i do need upstart
<markl_> i need to boot up without a console
<markl_> this is a weird dependency, why can't i use upstart without plymouth and mountall?
<markl_> this is definitely a house of cards, hmm
<Keybuk> yes, boot is a great big house of cards
<Keybuk> so careful with those matches!
<markl_> heh
<markl_> i'll just give the tablecloth a yank
<markl_> which is pretty much a good description of openvz's boot process i guess :)
<markl_> does initctl emit ever time out if there's no response?
<markl_> i at least got it to a 0 runlevel instead of unknown, i think i'm almost there
<Keybuk> no response?
<Keybuk> you'll always get a response from init
<Keybuk> (unless init dies, in which case the kernel will PANIC :p)
<Keybuk> of course
<Keybuk> if the task started by your event doesn't complete
<Keybuk> that response may come as a result of the heat death of the universe
<Keybuk> but that's a response too
<Keybuk> albeit a final one
<markl_> heh
<markl_> ah, it was the console output statement
 * markl_ smacks forehead
<markl_> so are these things like getty supposed to be easy to disable like it was with inittab?
<markl_> or should i make my own upstart package?  that wouldn't be too painful
<ion> Comment out the âstart on...â line.
<Will|> lo
<archayl> hello
<archayl> how am i supposed to make a script to startup my vbox vm?
<archayl> and save the state, then close it on shutdown?
<archayl> nvm
<archayl> tq
<Will|> is it possible to have a script run when upstart witnesses an abnormal exit?
<Will|> or when a respawn-limit is hit
#upstart 2010-04-25
<sadmac> Keybuk: autotools question for you
<Keybuk> sure
<sadmac> Keybuk: error: âPACKAGE_NAMEâ undeclared (first use in this function)
<sadmac> Keybuk: that's declared by automake typically, right? how does it get missed?
<Keybuk> by Autoconf acutally
<sadmac> Keybuk: the process I'm going through is main.strap.c is built into nih_parse_tool.strap, which is run on main.nihparse to make main.iter1.c, which is built into nih_parse_tool.iter1 ...
<sadmac> Keybuk: the strap version builds. the iter1 version fails on that. The main functions between the two are nigh identical.
<sadmac> iter1 is set up just like strap in Makefile.am. Only difference is the source doesn't exist at first.
<Keybuk> did you include config.h ?
<sadmac> ... X(
<Keybuk> C can be funny like that ;-)
<sadmac> Keybuk: especially C inside of other syntaxes
<sadmac> and especially inside of other custom syntaxes, and especially when that syntax is describing how to parse itself and the C is describing how to process it.
#upstart 2011-04-18
<chras> got a quick question im having a hard time finding an answer to, which is, is there an equivilant to 'normal exit 0 1' that i can use for pre-start (or any) scripts
<chras> by default, any non 0 exit code in a pre/post/etc-script will cause it to abort
<SpamapS> chras: set +e
<SpamapS> Not verified
<SpamapS> but I'm assuming that will work
<chras> hm, i never thought of that
<chras> its worth trying
<chras> nah thats the oppisate effect
<chras> -e is for quit upon non-0 exit
<chras> but yeah, not reading lemme try +e
<chras> yeah i tested that, and it worked fine, didnt know that upstart ran scripts with -e by default, but it guess it makes sense
<chras> good catch thanks
#upstart 2011-04-19
<sgflt> if i run a shell script through exec in an upstart job, does upstart keep track of all created processes and "track" those?
<hallyn> seen on #lxcontainers:
<hallyn> <KBme> does anyone know how I can tell debian init to start shutting the system down on a kill signal?
#upstart 2011-04-20
<jMCg> That feels.. wrong.
#upstart 2011-04-21
<Keybuk> .SECONDEXPANSION:
<Keybuk> $(bin_PROGRAMS) $(sbin_PROGRAMS): $$($$@_SOURCES:.c=.o)
<Keybuk>         $(LINK.o) $^ $(LDLIBS) -o $@
<Keybuk> ^ automake in ordinary GNU make :p
#upstart 2011-04-22
<jMCg> Keybuk: how does it work? Why does it work? And: Even if it makes automake obsolete, it doesn't really make for understandable code :-/
<Keybuk> jMCg: $@ is the make variable for "the target"
<Keybuk> so $@_SOURCES for init expands to init_SOURCES
<Keybuk> $($@_SOURCES) is thus "the contents of $(init_SOURCES)"
<Keybuk> the .SECONDEXPANSION bit tells automake to expand the objects of a target twice, and in the second time variables like $@ are set
<jMCg> Keybuk: unintentionally, I use that...
<jMCg> see: https://scm.brainsware.org/svn/webstack/linux/Makefile
<jMCg> Keybuk: ah.. my innitial understanding was that you didn't use automake.
<Keybuk> that isn't automake
<Keybuk> sorry
<Keybuk> "tells MAKE to expand"
 * jMCg tries to reparse.
<jMCg> Ah, okay, that explains the escaping of the $.
<Keybuk> now for the advanced class
<Keybuk> http://paste.ubuntu.com/597191/
<Keybuk> work out what *that* does
<Keybuk> and why it's awesome :D
<jMCg> Keybuk: what's $1?
<jMCg> Oh.
<Keybuk> so:
<jMCg> It's Whatever $$@ gets expanded to.
<Keybuk> dep_dir turns src/foo.c into src/.deps/
<Keybuk> and dep_file turns src/foo.c into src/.deps/foo.mk
<jMCg> Why do you have an .mk file for each .c file?
<Keybuk> both are written using Make functions so they work if you pass them multiple arguments
<jMCg> GNU Make, anyway.
<Keybuk> so $(call dep_file,src/foo.c tests/bar.c baz.c) returns src/.deps/foo.mk tests/.deps/bar.mk ./.deps/baz.mk
<Keybuk> the next bit is the implicit compile rule
<Keybuk> it says any .c file can be turned into a .o file using CC (gcc, clang)
<Keybuk> -MMD -MT $@ -MT src/.deps/foo.mk -MP
<Keybuk> is an operative bit there
<Keybuk> it means: AS WELL AS compiling the .o file, generate src/.deps/foo.mk
<Keybuk> that is a Makefile snippet that lists all of the .h files that gcc found
<Keybuk> so it might look like:
<Keybuk> src/foo.o: src/foo.c src/common.h src/log.h
<jMCg> ACK.
<Keybuk> and then
<Keybuk> -include $(call dep_file,$(SOURCES))
<Keybuk> means include every .mk file for every defined file in $(SOURCES)
<jMCg> What's -include?
<Keybuk> -include means "ignore error due to not existing"
<Keybuk> so the first time you type "make" none of these .deps files exist
<Keybuk> so make doesn't know which headers are deps
<Keybuk> but that's ok
<Keybuk> none of the .o files exist either ;-)
<jMCg> I suppse you define $(SOURCES) somewhere above.
<Keybuk> so the first time you compile, make's brain is populated with all of the .h deps
<Keybuk> so the next time, it rebuilds based on what you changed
<Keybuk> yeah, $(SOURCES) is put together elsewhere using $(foreach ...)
<Keybuk> the one other strange bit is the stamp madness
<jMCg> That's bordering insane -- but then, so is autocrap.
<Keybuk> each .o file depends on the equivalent src/.deps/stamp file
<Keybuk> and that rule is simple, it makes the .deps directory and touches the stamp file in it
<Keybuk> this means there's only one mkdir call for each .deps directory
<Keybuk> rather than one for each C file
<Keybuk> not strictly necessary, but it looks better in the make V=1 output :p
<jMCg> Keybuk: how long did you work on upstart's Makefile?
<Keybuk> oh, that stuff?
<Keybuk> on the shuttle this morning
<Keybuk> so about an hour
<jMCg> I hereby declare you my personal hero of the hour.
<jMCg> Would you very much mind removing all the autocrap from trafficserver: https://svn.apache.org/repos/asf/trafficserver/traffic/trunk/ - please?
<jMCg> Instead of reading the GNU m4 handbook and subscribing to the libtool-users mailinglist, maybe I should have read the GNU make handbook instead.
<Keybuk> heh, I don't hate autotools
<Keybuk> I'm listed in AUTHORS after all
<Keybuk> but Upstart simply doesn't need any of the portability stuff
<Keybuk> we can assume GNU make and GCC or clang
<Keybuk> and Linux
<Keybuk> and Automake's requirements to list every single binary was *really* causing me problems with maintaining the ever-growing test suite
<Keybuk> by switching to GNU Make turned up to 11, I can just have a single TESTS = ... that lists every binary
<Keybuk> and where I need it linked to .o files from the source, add
<Keybuk> tests/blah: src/blah.o src/foo.c
<Keybuk> and everything else is automatic
<jMCg> http://www.varnish-cache.org/docs/trunk/phk/autocrap.html << regarding portability: we're down to a handful of unices anyway, so portability isn't that much of an issue.
<Keybuk> agree
<Keybuk> Linux + OS X
<Keybuk> and those are largely GNU Toolchain
<Keybuk> hell, I build Upstart on OS X on my MBP half the time when testing random bits
<jMCg> Solaris 11 will be moving to gmake and much of the GNU Tool chain - well, I suppose they will keep their compiler.
<jMCg> And maybe, one day, FreeBSD will have moved to clang -- but they will still have the rest of the GNU chain.
<Keybuk> Solwhatnow?
<jMCg> The thing we use at $work.
<Keybuk> oh, that Oracle thing
<Keybuk> I thought they were pushing Red Hat ;-)
<Keybuk> well, Oracle Ripped Off Linux
<jMCg> Well, there's a couple of things in Solaris I'd really love to see in Linux.
<ion> I want a good port of zfs on Linux or the 2018 release of btrfs.
<jMCg> SMF is, by now, I believe, suprior to upstart.
<jMCg> ion: +1
<ion> (Also, i want it now.)
<jMCg> Well, actually there's only two things missing: switching users/groups without using *ugly* "hacks" - and reducing privileges(5) (on Linux: Capabilities(7)) so you don't have to start a daemon as root.
<jMCg> That really rocks.
<jMCg> I can run Tomcat on port 80 without feeling dirty.
<JanC> wasn't there some talk about some BSDs switching to PCC ?  ;)
<Keybuk> jMCg: really? what do you think SMF does better than Upstart?
<jMCg> JanC: long, long time ago. I think they've hopped on the LLVM bandwagon, because that one's actually moving.
<Keybuk> SMF was pretty basic last time I looked
<jMCg> Keybuk: 02:18:46 < jMCg> Well, actually there's only two things missing: switching users/groups without using *ugly* "hacks" - and reducing privileges(5) (on Linux: Capabilities(7)) so you don't have to start a daemon as root.
<Keybuk> jMCg: yeah, just got that
<Keybuk> +1 then ;-)
<Keybuk> that's coming in one week
<jMCg> About a year ago, I asked you if there's a chance these will get into upstart and you gave an ~18 month estimate :)
<jMCg> whoa.
<Keybuk> I have a patch from someone that adds all the useful bits
<Keybuk> but that person refused to sign the CLA
<jMCg> Pity.
<Keybuk> and I promised the Canonical CTO that I would continue those negotiations until the end of April
<Keybuk> so 1st May, bzr merge ... ;-)
<JanC> lol
<Keybuk> I've suggested what I think is a sensible compromise between the positions
<Keybuk> it's up to them
<jMCg> When someone gives you code - on the ML or via launchpad, don't they basically automatically give up all rights?
<Keybuk> jMCg: no, Geneva Convention means they still own copyright
<jMCg> I kinda figured that was the position with apache, but I try not to care too much about CLAs. I just write and commit happily away.
<Keybuk> Apache has a signed CLA
<Keybuk> which I find unusual, since the Apache Licence already specifies everything necessary
<jMCg> But they are highly paranoid about IP.
<jMCg> s/they/we(?)/
<Keybuk> I guess
<jMCg> http://monster-island.org/tinashumor/humor/howinst.html < "By breaking this seal, ..."
<JanC> the Geneva convention doesn't say anything about copyright really  ;)
<Keybuk> err
<Keybuk> Berne
<JanC> it's an international treaty about the treatment of war victims
<JanC> ;)
<Keybuk> to be fair, Berne and Geneva are both cities in Switzerland
<Keybuk> and you can see how I got there
<jMCg> By air plane?
<Keybuk> haha, yes, train no more
<jMCg> hmm.. any chances that new patchset will make it into Natty? :O
<JanC> jMCg: natty releases before the 1st of May  ;)
<jMCg> And 10.10 comes with: ii  upstart                                               0.6.6-4                                               event-based init daemon
<jMCg> That's sad :-/
<Keybuk> aye
<Keybuk> it could be worse
<Keybuk> 11.04 could come with a version of Upstart that was invented by Ubuntu, and doesn't match any upstream release at all ;-)
<jMCg> ugh.
<jMCg> Keybuk: can you link the bzr branch that contains your Makefile?
<Keybuk> it's not in a branch, it's just on my laptop at the moment
<Keybuk> on the shuttle trip home, I shall make po/pot generation work
<Keybuk> and then maybe tomorrow morning, "make dist"
<bencc> when removing and purging a package I still have processes running so I think I don't stop it correctly in my upstart script
<bencc> http://dpaste.com/534618/
<bencc> why doesn't my server being stopped?
<JanC> I'd say it's more likely something is wrong in the packaging...
<hallyn> When I have something wiating on 'mounted MOUNTPOINT=/', then mountall stops after emitting that signal, until the wiating job has finished.  I'm just curious - is that done by upstart, for any job which says 'emit X', or is mountall doing that specially?
<JanC> hallyn: is that job a task ?
<JanC> the DBus method EmitEvent has a Boolean 'wait' parameter, and if the waiting job is a task, waiting will wait until the task is run
<JanC> "initctl emit" also has an option --no-wait that you can use
<hallyn> ah, i see.
<hallyn> yeah it's a task
<hallyn> so mountall must do a --wait
<hallyn> JanC: thanks
<JanC> well, mountall probably uses the DBus API directly, but yeah  âº
<hallyn> so is there any way, from an upstart job, to say 'start on x and y' where only the later one of x and y will be waited upon?
#upstart 2011-04-24
<bencc> can I tell upstart not to restart a job?
<bencc> I have a job that already have a script that monitors it
<steffen_b> dont put respawn in the job ?
<bencc> steffen_b: checking my upstart script 
<bencc> steffen_b: respawn should be outside of script, pre-stop... right?
<steffen_b> yep
<bencc> so I'll comment it out. thanks
<bencc> I feel a little guilty when using upstart because it is so much easier than init.d scripts
<steffen_b> yes indeed
<steffen_b> but general perception is
<steffen_b> i dont know how this upstart works
<bencc> that's why debian guys don't want it by default
<steffen_b> at least this is what i get from our users (yavdr)
<steffen_b> well , there is plenty of room for improvement in upstart (or the way ubuntu is using upstart)
<bencc> what would you improve?
<steffen_b> so from debian perspective i can understand it 
<steffen_b> check the shutdown handling 
<steffen_b> missing 'user' still compared to start-stop-daemon 
<steffen_b> missing states 
<steffen_b> if you get into the details , you get your hands dirty quickly 
<steffen_b> but i cant judge if its ubuntu or upstart 
<bencc> ok
 * steffen_b is also just upstart user 
<steffen_b> in a ubuntu based linux distro 
<bencc> if my server start script run in the background, how do I use it with upstart?
<bencc> I see the wiki but it mixes old and new releases
<bencc> http://upstart.ubuntu.com/wiki/Stanzas
<bencc> I guess I need to use daemon and than to tell it how to find the pid
<steffen_b> i would say dont use a start script seperate from ubuntu job 
<steffen_b> argh
<steffen_b> upstart job i mean
<steffen_b> upstart
<steffen_b> :D
<steffen_b> one second
<steffen_b> http://upstart.at/
<bencc> maybe I'll remove the part that run it in the background
<steffen_b> http://upstart.ubuntu.com/cookbook/
<steffen_b> far better then the wiki
<bencc> thanks
<steffen_b> if the server you try to start has a mode to run in foreground
<steffen_b> then use that in the job 
<steffen_b> if possible
<steffen_b> easier to get it right then 
<steffen_b> having hard time with natty shutdown at the moment 
<bencc> ok
<steffen_b> someone here who can provide me some helping hand to track it down ? 
<bencc> start myserver and stop myserver works
<bencc> but when I'm trying "restart myserver" I'm getting stop/waiting after ~2 seconds
<bencc> why is that?
<JanC> bencc: are you sure stop & start both work correctly?  (restart does exactly that, so there shouldn't be any difference)
<steffen_b> good practice is to use ps -ef 
<steffen_b> and compare it to initctl list or status myserver
<steffen_b> if pid is matching main process all is fine
<steffen_b> if you use script section for the main process
<steffen_b> make sure you use exec 
<steffen_b> so script and daemon get the same pid
<bencc> JanC: they are working. not sure how I can check if they work correctly
<JanC> just one example of what could go wrong: what if upstart thinks myserver is stopped while it's still shutting down so that when it's restarted too fast some resources that myserver needs are still in use?
<JanC> checking logs might be useful
<bencc> JanC: how can I check the logs?
<bencc> myserver is supposed to halt until it really stops
#upstart 2012-04-16
<JshWright> having some trouble overriding the default ctrl+alt+delete behavior in Ubuntu 10.04
<JshWright> I've replaced the 'exec' command in /etc/init/control-alt-delete.conf with my script (which I've tested on its own)
<JshWright> if I use initctl emit control-alt-delete, it works fine, but physically pressing those keys doesn't do a darn thing
<SpamapS> JshWright: man 7 control-alt-delete says that upstart should emit it *if* the keys are pressed on the console. Are you sure they're being pressed on the console?
#upstart 2012-04-17
<alienth> hey folks, any solution for firing a script that forks 3 times?
<SpamapS> alienth: sure.. don't do that. ;)
<SpamapS> alienth: why does it need to fork (and exit) 3 times?
<alienth> SpamapS: so, the situation is i'm trying to upstart memcached
<alienth> memcached doesn't take a config file, so it uses a wrapper perl script, which forks, and then calls a daemon
<SpamapS> alienth: heh, that weird perl script is a fail :)
<SpamapS> alienth: there's really no need. Just run memcached directly
<SpamapS> alienth: I actually wrote an upstart job for memcached a few months ago but never got around to getting it into Ubuntu
<dcorbin_work> I have simple upstart script: https://gist.github.com/2405988  In circumstances we haven't figured out yet, jboss is shutting down gracefully, and then appears to restart 10-30 minutes later.  How can I verify that upstart is or is not involved in this?
<SpamapS> dcorbin_work: start on starting enttek-inventory
<SpamapS> dcorbin_work: I'd suspect that enttek-inventory is starting back up ;)
<SpamapS> dcorbin_work: I wonder, why don't you 'stop on stopped enttek-inventory ?
<dcorbin_work> SpamapS: I'm sure it could be better.  The real issue is figuring out why it's stopping in the first place.  Is there an upstart log that tracks the events?
<SpamapS> dcorbin_work: you can do 'initctl log-priority info' and you'll get all the job status changes in syslog
<JanC> also see http://upstart.ubuntu.com/cookbook/#debugging
<SpamapS> dcorbin_work: also if it is stopping gracefully thats not really in upstart's realm. It will only respawn on a non-normal exit.
<dcorbin_work> SpamapS: it is stopping gracefully.  But my expectation is that the stopping is no through upstart.  I'm just having to track it down.  Sadly, we've 40+ servers (and growing) and it's only happend 3 times in the last few months.
<SpamapS> dcorbin_work: you can always change the notion of 'normal exit' to not include '0', so 'normal exit 99' would only not-respawn on exit code of 99. I think. You'd need the 'respawn' keyword too.
<dcorbin_work> SpamapS: The problem we're facing is that it's getting shutdown in the middle of a "process" that won't restart automatically, even if jboss is respawn. i.e., respawning isn't enough to fix it for us.  We'll see what logging shows us.
<SpamapS> ahh yeah thats probably not upstart's fault :) I bet you'll see 'exitted with 0 status'
<dcorbin_work> SpamapS: I'm 99% sure it's not upstart, I just don't have any other good places to eliminate yet. :) 
<mirth> does anyone know when autovacuuming runs and if it will lock the db if done during production hours?
<SpamapS> mirth: either thats the wrong window, or somebody spliced your upstart man pages with your postgres man pages. :)
<mirth> heh...i typed swapped username and channel name when joining :)
<mirth> usually use 'upstart' as my nick
#upstart 2012-04-19
<djszapi> jodh: ping
<jodh> djszapi: hello
<djszapi> jodh: I am not getting my upstart job logged
<djszapi> there is certainly issues with it and I have used console log
<djszapi> but there is no /var/log/upstart/foobar.log entry.
<jodh> does the directory /var/log/upstart/ exist?
<djszapi> I do not see anything related: http://paste.kde.org/459902/ this is my upstart job: http://paste.kde.org/459908/
<djszapi> nope
<djszapi> it does not exist
<djszapi> on this pandaboard
<djszapi> upstart 1.3-0ubuntu12~linaro2
<jodh> djszapi: http://upstart.ubuntu.com/cookbook/#stanzas-by-category
<jodh> djszapi: console log didn't get introduced until 1.4.
<djszapi> by default or altogether ?
<jodh> djszapi: if you run "init-checkconf foo.conf" you should get a msg about invalid stanza as "console log" won't be understood.
<jodh> djszapi: the feature was added in Upstart 1.4 and you are running Upstart 1.3
<djszapi> init-checkconf cannot be run as root
<djszapi> and I am not supposed to have another user for this.
<djszapi> at any rate, I trust you.
<djszapi> jodh: shall I use console output ?
<djszapi> and 2>&1 ?
<jodh> djszapi: I suggest you read http://upstart.ubuntu.com/cookbook/#debugging
<jodh> djszapi: it's all in there
<jodh> djszapi: correct - init-checkconf runs as a normal user.
<djszapi> jodh: what is wrong about this: http://upstart.ubuntu.com/cookbook/#console-output
<jodh> djszapi: nothing - there are many options. It's your decision :)
<djszapi> jodh: what do you recommend ?
<djszapi> there is some operational issues with my binary
<djszapi> it works if I run manually.
<djszapi> but it does not function if it is run by upstart
<djszapi> the binary is running and all that jazz, but no proper effect on the functionality.
<djszapi> it opens a serial port, and begins to listen to that
<jodh> djszapi: I'd recommend reading http://upstart.ubuntu.com/cookbook/#debugging then.
<djszapi> and if there is a data, it parses.
<djszapi> and act accordingly, that is all. What I now see, it does not act as expected.
<djszapi> so needs to be debugged.
<jodh> yes - see also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<jodh> which might be the answer in your case. You'll just have to try it.
<djszapi> that is a complete no go
<djszapi> I would like to separate the logging out for my stuff
<djszapi> I would not like to grep in a bunch of stuff
<djszapi> and that is what console output is for, afterwards.
<jodh> I think you have misunderstood - the 'grep' is an example in the section above. *You* don't need to grep, you need to test your script with '/bin/sh -e'.
<djszapi> I do not understand
<djszapi> Please note that I do not use script
<djszapi> and there is no "failing" either.
<djszapi> what I would actually like to get, is a 2>&1 like operation, and console output seems to be designed for that.
<djszapi> as in: exec /usr/bin/foobar-commandline receive > /var/log/foobar.log 2>&1
<jodh> djszapi: you can do exactly that if you want to.
<djszapi> what happend with Scott ?
<djszapi> one or two years ago I had the discussions with him.
<djszapi> he stepped down as the upstart maintainer ?
<jodh> yes - he is now working at Google.
<djszapi> I know that, but I did not know he stepped down from the upstart maintenance.
<djszapi> interesting, after the launch: stop foobar; start foobar and the "foobar" binary works just fine...
<djszapi> what is the difference ?
<djszapi> the serialport is opened by that process after the launch, so I do not really understand.
<djszapi> jodh: is the serialport available for writing for such a job ?
<djszapi> jodh: the modem is not set up on the serial port :(
<djszapi> while the upstart job is running, just later.
<djszapi> how can that be ?
<djszapi> since the modem does not respond to the commands that time I send out.
<djszapi> so I guess the modem is not set up, but why ?
<djszapi> I had the impression "start on runlevel [23]" should be just fine
<djszapi> jodh: what should trigger the start of my job instead of the initlevel thingie ?
<jodh> djszapi: you should probably add 'and X-device-added a=b c=d' for the modem device. See http://upstart.ubuntu.com/cookbook/#upstart-udev-bridge, upstart-events(7) and upstart-udev-bridge(8).
<djszapi> jodh: I have honestly no ideas about the subsystem :/
<jodh> djszapi: what device does your app open? /dev/ttyS0?
<djszapi> /dev/ttyUSB0
<djszapi> PL2303 (usb-serial converter)
<djszapi> jodh: http://paste.kde.org/459968/
<djszapi> perhaps usbdev ?
<jodh> so, have your job 'start on tty-device-added DEVPATH=*ttyUSB0'
<djszapi> E: SUBSYSTEM=tty
<djszapi>  udevadm info --export-db | grep -B 2 -A 2 /dev/ttyUSB0
<djszapi> from this output
<djszapi> this one then ? start on (tty-device-added)
<djszapi> stop on (tty-device-removed)
<djszapi> hmm, the documentation does not mention the DEVPATH
<djszapi> just inside the log, but not for the "start/stop" lines.
<jodh> I've given you the answer above. I'm guessing you either don't have your usb device plugged in or you didn't run udevadm as root?
<djszapi> well, the documentation does not mention any DEVPATH examples.
<djszapi> the documentation only speaks about the log wrt those.
<jodh> ?
<djszapi> show me the documentation example for the DEVPATH usage.
<djszapi> these are the examples: start on (graphics-device-added or drm-device-added)
<djszapi> start on (graphics-device-added or drm-device-added)
<djszapi> 1) Both contain brakcets
<djszapi> brackets*
<djszapi> 2) None of the presents the usage of DEVPATH
<djszapi> jodh: did not help
<jodh> djszapi: what did not help? Please be specific.
<djszapi> jodh: http://paste.kde.org/459974/
<djszapi> what I told above
<djszapi> same symptom
<djszapi> the modem was not able to reply to the message sent out while running the relevant binary from the upstart job.
<jodh> djszapi: I suggest you (1) comment out the 'stop on' and make the job 'start onrunlevel [23] and  tty-device-added DEVPATH=*ttyUSB0'.
<jodh> djszapi: also, comment out respawn.
<djszapi>  init-checkconf /etc/init/piruag.conf 
<djszapi> ERROR: failed to ask Upstart to check conf file
<djszapi> respawm is very important
<jodh> djszapi: do this before running init-checkconf as presumably you're running on a console: eval `dbus-launch --auto-syntax`
<djszapi> jodh: I am now having only two lines: 1) start onrunlevel [23] and  tty-device-added DEVPATH=*ttyUSB0 2) exec /usr/bin/foobar-commandline receive
<jodh> djszapi: ...?
<djszapi> File /etc/init/foobar.conf: syntax ok
<djszapi> jodh: what is not clear ?
<jodh> djszapi: so what happens now? does the job work with the 2 lines or not?
<djszapi> testing
<djszapi> jodh: I think the point is not ttyUSB0
<djszapi> jodh: IMO, the point is that this specific modem is set up at that time.
<djszapi> if they are the same, then ok.
<djszapi> jodh: that way, it does not even run after the bootup
<djszapi> probably no space between on and runlevel
<djszapi> and I have just copied and pasted your line. :-)
<djszapi> jodh: that line actually broke the initscripts
<djszapi> even ssh does not work from outside anymore :(
<djszapi> jodh: get it back, sorry but no ... my binary does not even run anymore with that "start on runlevel..." etc line
<djszapi> are you sure brackets are not needed or other quirk ?
<jodh> djszapi: init-checkconf will tell you if the file is valid.
<djszapi> jodh: at any rate, the binary is not even started this way
<djszapi> any ideas ?
<djszapi> too bad upstart is this hard to use :/
<jodh> if your app isn't setting the modem, sounds like you need to find out what is. If it is being configured by an Upstart job, you can make your job 'start on stopped <thing>' since at that stage the modem will presumably be configured. If it's being done by a sysv script, then 'start on stopped rc'.
<djszapi> I have no clue what you are talking about.
<djszapi> my application does configure the modem, but it should obviously available for commands. As for me, upstart seems to be either broken or quite undocumented.
<jodh> djszapi: it is neither.
<djszapi> well, it does not work
<djszapi> and I do not find in the documentation either how it is supposed to work either.
<djszapi> as for me, it is time consuming either way as a "customer".
<djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
<djszapi> end script
<djszapi> this logged nothing, so even this part of the documentation is hilariously broken
<jodh> djszapi: incorrect - that tells you the either you have a corrupt .conf file (your paste is incorrect in that 'echo' should be on the line below), or your job never started.
<jodh> djszapi: have you tried "start <job>" on a booted system maybe? do you get a log file then?
<djszapi> no log, no
<djszapi> even after start stuff
<djszapi> jodh: ^
<djszapi> start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)
<djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
<djszapi> end script
<djszapi> exec /usr/bin/...
<jodh> djszapi: as stated above, that is incorrect syntax: the first 'script' should be on a line on it's own, as shown in the cookbook and as documented in init(5).
<djszapi> no
<djszapi> documentation shows this: start on (graphics-device-added or drm-device-added)
<djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
<djszapi> end script
<djszapi> have you actually checked the documentation ?
<djszapi> also: init-checkconf /etc/init/piruag.conf 
<djszapi> File /etc/init/piruag.conf: syntax ok
<djszapi> s/piruag/foobar/
<jodh> djszapi: what you have pasted above is therefore *not* what is in piruag.conf as it is invalid. the cookbook is correct. Maybe your web-browser is mis-rendering it. It views perfectly for me in ff and chromium.
<djszapi> huh ?
<djszapi> your irc client is wrong then
<djszapi> since it was a simple copy/paste
<djszapi> please do not argue about useless things
<djszapi> let us just nicely proceed
<djszapi> I would not like to spend yet another few hours with upstart to run a simply binary lol
<djszapi> once tty is set up properly.
<djszapi> s/simply/simple/
<djszapi> I do not understand why this hard to use an initiscript.
<djszapi> this is a perfectly valid syntax made according to the documentation (TM): http://paste.kde.org/459992/
<jodh> djszapi: right - your problem is that you've specified both a 'script' section and an 'exec'. That's not valid, or rather the last valid entry will be selected (the exec), hence you won't get a log.
<djszapi> init check returns /valid/
<djszapi> fix the check.
<jodh> djszapi: put the call to /usr/bin/foobar-commandline at the end of the script section and comment out the exec section.
<jodh> djszapi: it's valid, but not what you want.
<djszapi> what is the point of upstart if it is this hard to run a binary once the serial port is set up  ?
<jodh> it isn't hard - you just need to read the documentation. If the documentation is unclear or needs more examples, please raise bugs so we can rectify the situation.
<djszapi> well, you did not even provide any working solution so far
<djszapi> so it seems to be even hard for you.
<djszapi> so what can I say as a newcomer...
<jodh> djszapi: I don't have a modem and I didn't write your application :)
<djszapi> it has nothing to do with my application
<djszapi> it expects a modem set up
<djszapi> which is obviously a sane thing if you wanna configure it ....
<djszapi> http://paste.kde.org/460028/ -> this is the env
<djszapi> quite poor from what I can say.
<djszapi> anyway, I have no clues...
<djszapi> any help is welcome...
<djszapi> otherwise I need to admit it is incredibly hard from upstart, and not worth spending the time with.
<jodh> djszapi: so your application runs correctly from the command-line on a booted system?
<djszapi> like I said in the very beginnig, of course...
<djszapi> even from upstart ...
<djszapi> not during the boot, but I said it many times really :)
<djszapi> so clearly, the modem is not up and running
<djszapi> and still, the last line I got for the "start on ..." is broken
<djszapi> the binary is not even executed anymore
<djszapi> jodh: ^
<SpamapS> djszapi: what release of Ubuntu are you on?
<djszapi> upstart 1.13
<djszapi> (like I said in the beginning)
<djszapi> why should the ubuntu version matter ?
<SpamapS> djszapi: I wasn't here in the beginning. Please try to be a bit more polite.
<SpamapS> djszapi: There is no such thing as 1.13
<djszapi> weird, I see you were online.
<djszapi> of course there is.
<SpamapS> 1.5 is the newest release of upstart
<djszapi> 1.3-0ubuntu12~linaro2
<djszapi> yes, 1.3
<SpamapS> Ok, 1.3 not 1.13 :)
<djszapi> it drives me crazy :/
<SpamapS> djszapi: so if you add this to your exec line, you can get the error messages from your command logged to syslog:
<SpamapS> 2>&1 | logger -t pickatag
<djszapi> that is not gonna work without console log IIRC
<djszapi> console output
<SpamapS> djszapi: you may also want to increase the log priority to 'info' so that you can see upstart events being processed. 'initctl log-priority info'
<SpamapS> djszapi: you don't have syslogging?
<SpamapS> djszapi: ok, change that to this then:
<djszapi> I do have syslog
<djszapi> but I would rather prefer a dedicated log just for this.
<SpamapS> >> /run/mylog.log 2> /run/myerr.log
<djszapi> -> /run ?
<djszapi> you mean /var/log/ ?
<SpamapS> choose whatever you want
<djszapi> -> /run does not really fit the lfsh
<SpamapS> ok, you get the idea.
<djszapi> http://paste.kde.org/460052/
<SpamapS> djszapi: yeah that should work
<djszapi> ok, it does not
<djszapi> like I said before
<djszapi> especially because console output is not there.
<djszapi> and even if I was putting there, I would have the same information, I already do have.
<djszapi> the modem does not respond.
<djszapi> most likely because it is not set up
<djszapi> so I do not understand what addition we would gain in here.
<djszapi> Any ideas pushing the topic forward ?
<djszapi> what I need is not the logging of my application, I already know where it fails.
<djszapi> I would need to know what to trigger the application for.
<djszapi> the documentation does not just work, period.
<djszapi> nor the aforementioned ideas.
<djszapi> I do not understand why one needs to spend many hours to run a binary once the serial port and the modem in there are ready. :/
<djszapi> it should be this simple: I would like to run my daemon once the system is fully set up: ok, use this.
<djszapi> should be just one option.
<SpamapS> djszapi: where does it fail then?
<djszapi> huh ?
<SpamapS> djszapi: is there hardware missing?
<djszapi> have you actually read what I wrote ? :-)
<SpamapS> djszapi: sounds like the device added event is emitted by udev too soon.
<djszapi> sorry, but really getting frustrated. I would not like to spend /enormous/ amount of time to run a binary once the system is fully set up.
<SpamapS> djszapi: I'm done. Good luck with upstart. You will get no help until you can be nice.
<djszapi> you have not clearly read what I wrote.
<djszapi> I wrote that the modem does not respond back then while trying to configure it.
<SpamapS> Ok, I typed that while you said sorry.
<SpamapS> djszapi: so that tells me that you need an event for when the modem is ready, not when the serial port is added
<djszapi> I would need a common event which tells the system is up!
<djszapi> now you can run anything.
<djszapi> everything is set up.
<SpamapS> "system is up" is hard to define.
<djszapi> I do not care about low-level stuff, like a certain specific device is run
<SpamapS> mobile systems have resources that come and go.
<djszapi> with the certain specific vendor and so on ids.
<djszapi> this is quite low-level.
<djszapi> super low-level
<djszapi> "system is set up" -> done
<djszapi> run the binary
<djszapi> what is so hard about it ?
<SpamapS> runlevel 2 should be that the system is ready to run anything statically onfigurable
<SpamapS> configurable rather
<djszapi> like I said, runlevel 2 did not work.
<djszapi> getting no replies from the modem
<SpamapS> Right, so there is something not-static that you are dependent on.
<djszapi> meanwhile if I make a stop myjob; start myjob, I do get replies
<djszapi> either an "OK" or an "ERROR".
<SpamapS> djszapi: perhaps try 'stopped udevtrigger and runlevel [23]'
<djszapi> it is quite static, trust me :)
<SpamapS> djszapi: udevtrigger will flush all events that the kernel knows about at system boot.
<djszapi> I am not sure udevtrigger stopping check is a good point for that.
<djszapi> Like I wrote: "start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)" does not even run the binary anymore
<djszapi> so it is already a broken check.
<djszapi> extending a broken check... I do not expect anything working.
<djszapi> start on (stopped udevtrigger and runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)
<djszapi> I do not expect it to work either.
<SpamapS> djszapi: it will delay the start a bit... perhaps until the modem is ready
<SpamapS> djszapi: Otherwise, the modem needs to be polled
<djszapi> no way
<djszapi> if I stop and start, it runs fine
<djszapi> without doing that, it does not appear.
<djszapi> so no, sorry.
<SpamapS> djszapi: let me put it another way. What actual event would you expect to signify that the modem is ready?
<djszapi> modem is continously ready
<djszapi> since it gets power supply, and not turned off.
<djszapi> so I would expect once /dev/ttyUSB0 is available, it should work oob
<SpamapS> djszapi: so perhaps there's a bug in the code that emits the event about ttyUSB0 being ready when it isn't
<djszapi> I do not understand why I am having these troubles if it is super simple by using SystemV.
<SpamapS> djszapi: because systemv takes 5x longer to start
<SpamapS> djszapi: its still a race, its just that one car is WAY slower than the other :)
<djszapi> I do not feel it funny, sorry for that...
<SpamapS> djszapi: you can try putting yourself way after rc runs.. 'start on stopped rc RUNLEVEL=[23]'
<SpamapS> djszapi: but thats really just slowing down the race a bit. Not solving the issue.
<djszapi> huh ?
<SpamapS> djszapi: perhaps also try 'respawn' which will retry a few times
<SpamapS> djszapi: you need an event that is reliable. Your ttyUSB0 event is clearly not reliable. :-P
<djszapi> jodh said to remove the respawn...
<djszapi> you have nothing to prove that saying.
<djszapi> really.
<SpamapS> I don't, because you won't show me the output of your program
<djszapi> ubuntu should drop upstart to the trash :)
<djszapi> it is unusable even for simple cases like this.
<SpamapS> djszapi: this has nothign to do with upstart.
<djszapi> ofc it does.
<djszapi> since it works with other systems like aforementioned.
<SpamapS> djszapi: upstart is operating properly... as I said, you just don't have an event you can rely on.
<djszapi> that makes no sense, sorry.
<djszapi> stop/start works fine!
<SpamapS> djszapi: so if I tune up my engine and get my car to go 220mph, but that makes the tires melt.. its the engine's fault?
<djszapi> huh ?
<SpamapS> djszapi: upstart is just the point where you're interfacing with the plumbing of the entire system
<SpamapS> djszapi: stop/start works fine because the device has had enough time to initialize
<djszapi> I joined this channel more than three hours ago
<djszapi> and still not solved
<djszapi> like...wtf ?
<SpamapS> djszapi: well you've been really difficult. I'm trying to help.
<SpamapS> djszapi: lets back up, because I want to make sure I'm as helpful as possible.
<djszapi> I have not realized I would have any solution for the issue, really.
<SpamapS> djszapi: you have this job which uses 'start on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0  .. right?
<djszapi> to run a daemon after the system is fully up takes more than three hours :(
<SpamapS> djszapi: and you refuse to try adding 'stopped udevtrigger' right?
<djszapi> not right
<SpamapS> djszapi: and upstart tries to start the program, but the program fails with some kind of error about the serial port not being ready, right?
<djszapi> no, the program does not fail
<SpamapS> ahh
<SpamapS> <-- misunderstood
<SpamapS> djszapi: ok, so the program never starts?
<djszapi> and, no, I am now trying this as recommended: start on stopped rc RUNLEVEL=[23]
<djszapi> it does start
<SpamapS> djszapi: and its in 'stop/waiting' after the system fully boots?
 * djszapi ponders how many hours have to wasted yet for upstart :(
<djszapi> be*
<djszapi> SpamapS: again: the binary runs with start on stopped rc RUNLEVEL=[23], but the modem does not respond with either "OK" or "ERROR" like after running stop/start
<djszapi> tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work
<djszapi> the daemon did not even run
<SpamapS> djszapi: is it possible that the modem doesn't initialize itself until the first time you run the program?
<djszapi> huh ?
<djszapi> like I said, the modem is fully powered
<djszapi> it is configured
<djszapi> it is working
<djszapi> the running ubuntu stuf makes it not responding
<SpamapS> djszapi: what I'm saying is, could it be that the modem won't respond to the first program that talks to it.
<djszapi> during the bootup for probably some false bootup sequence.
<djszapi> I do not see how that would be possible really.
<djszapi> if I do not try to run the program, but I run after the bootup
<djszapi> everything is alright.
<SpamapS> djszapi: ok so it still is just a race.. and we need to find the event that means "the modem is active"
<djszapi> again, again and again: I need to run my program once the system is set up !
<SpamapS> I would have expected tty-device-added to be that
<djszapi> darn upstart, it is not possible to do such a basic thing...
<SpamapS> djszapi: systems are mobile
<SpamapS> djszapi: tty devices come and go
<SpamapS> djszapi: 'stopped udevtrigger' is "when all the hardware that is plugged in at boot time is initialized"
<djszapi> well
<SpamapS> djszapi: perhaps take out the tty-device-added part
<djszapi> 19:58 < djszapi> tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work
<SpamapS> djszapi: so     start on runlevel [23] and stopped udevtrigger
<djszapi> I am not sure it is a good thing to base a system on a such a brittle tool.
<SpamapS> djszapi: the tool is actually quite strong. the events are just not easy to understand, because parallelism is hard.
<djszapi> I do not care about the events
<djszapi> have you still not realized ? :)
<djszapi> I would like to run my binary once everything is set up!
<djszapi> I do not care about premature optimization.
<djszapi> which causes -3-4 hours from more people's life.
<SpamapS> djszapi: I actually fully understand that. I want there to be more clear, simpler events like 'boot-hardware-initialized'. I created the event 'static-network-up' for this reason.
<SpamapS> djszapi: I also think that runlevel 2 should probably be delayed until after 'stopped udevtrigger' .. but people want the boot to proceed without waiting for all the hardware
<djszapi> I am not the people.
<SpamapS> djszapi: then you must understand the events. :)
<djszapi> no
<djszapi> Again, I would like to run a binary once everything is set up!
<SpamapS> djszapi: that is runlevel [23] and stopped udevtrigger
<djszapi> did not work
<djszapi> modem does not respond.
<SpamapS> hmmm... one thing..
<SpamapS> I notice udevtrigger uses post-stop to run 'udevadm settle'
<SpamapS> so perhaps the events will still be going after that event
<SpamapS> *argh*
<djszapi> Upstart, to the trash!
<SpamapS> djszapi: I have to go soon.. but I think this is worth a bug. It should be possible to ask for a job which waits for udevadm settle to finish.
<SpamapS> djszapi: let me make this clear. This has nothing to do with upstart. It is just a deficiency in the system plumbing available on top of upstart in Ubuntu.
<SpamapS> djszapi: upstart is doing everything right. Ubuntu has just failed to expose the events in a way that makes sense.
<SpamapS> I am surprised that your tty-device-added doesn't work
<djszapi> is there *ANY* workaround ?
<djszapi> put a sleep into the script ?
<djszapi> but that is blocking.
<djszapi> unless the kernel events are async.
<djszapi> which is probably the case.
<slangasek> if the goal is to delay the startup of the job, sure, you can use a sleep
<djszapi> in any case, sleep would be blocking.
<slangasek> what do you mean by "async"?
<SpamapS> djszapi: a sleep might work. You can also try putting 'udevadm settle' right before it running the program (or in a pre-start)
<SpamapS> djszapi: sleep would be blocking, exactly, thats why it might work ;)
<djszapi> can you tell me the line exactly?
<slangasek> pre-start exec sleep 10?
<djszapi> ohh it is just sleep 10
<djszapi> pre-start ?
<djszapi> why is that ?
<SpamapS> slangasek: any ideas on an event for 'when all the hardware currently plugged in is available'
<slangasek> djszapi: or you can put it at the top of the 'script'
<SpamapS> djszapi: so that when you respawn you don't run it again
<slangasek> SpamapS: I was thinking 'stopped udevtrigger' should do this, but I have the same uncertainty you do about whether post-stop scripts are required to complete before starting jobs that are 'stop on'
<djszapi> http://paste.kde.org/ -> slt ?
<slangasek> I think you missed the last part of that link
<djszapi> http://paste.kde.org/460106/
<slangasek> I don't think you need both the udevadm settle *and* the sleep... but certainly that should be enough
<djszapi> sorry, bruteforce for everything...just work...
<slangasek> I would expect that to work
<slangasek> btw, the 'console output' is irrelevant there, I think you've misunderstood what that does: that tells where to send stdout/stderr from the job script, but you're redirecting all of that to files anyway
<djszapi> so no harm either...
<slangasek> yes
<djszapi> I guess "udevadm settle" is better to have than random sleep amount ?
<slangasek> SpamapS: so if 'on stopped udevtrigger' doesn't catch the udevadm settle, we should probably split the trigger and settle out into separate jobs for dependency purposes
<slangasek> djszapi: yes
<slangasek> did it work for you when using both?
<djszapi> slangasek: yes
<djszapi> now cleaning up
<SpamapS> slangasek: indeed, I was thinking we might also just emit another event after the udevadmsettle.. 'stopped udevadm' or 'stopped udevtrigger' is very hard to read. :-P
<SpamapS> something like boot-devices-ready ?
<djszapi> http://paste.kde.org/460112/ -> Anything to improve on this ?
<djszapi> can I use exec + pre-script at all ?
<djszapi> or just script + pre-script ?
<slangasek> djszapi: ok.  then I also suggest dropping the 'runlevel [23] and' from the start condition
<slangasek> because a) it should be redundant, and b) it can cause the job to deadlock in certain corner cases involving runlevel changes, so it's best to not have it
<slangasek> SpamapS: 'coldplug-finished'?
<slangasek> or 'udev-coldplug-finished'
<slangasek> which is more explicit about what you get than 'boot-devices'
<SpamapS> slangasek: still feels very "I know about plumbing"
<djszapi> slangasek: could you please my worry about ?
<slangasek> djszapi: yes, 'pre-start exec udevadm settle' would be fine there
<djszapi> comment on*
<slangasek> and would be more idiomatic
<djszapi> that was not my question...
 * SpamapS suspends to save battery
<djszapi> my question was related to the exec mybinary...
<djszapi> + pre-script...
<slangasek> djszapi: ah, right - yes, that's also allowed
<slangasek> in general, it's preferred to use 'exec' instead of 'script' if you only have one command because it spares you a needless shell execution
<slangasek> but you can intermix them freely
<djszapi> I have been said above I cannot.
<slangasek> must have been a misunderstanding; you can
<slangasek> and SpamapS and jodh certainly both know that :)
<slangasek> SpamapS: I can see the point that a more generic name would be appropriate... particularly since that means we can adjust the underlying implementation as needed to fulfill that interface contract
<djszapi> slangasek: did not work
<slangasek> djszapi: pastebin the one that didn't work, please?
<djszapi> see above
<djszapi> runlevel [23] -> this was removed from that
<slangasek> ok
<slangasek> well, re-add it then if you must :/  that's not ideal, but it's more important that it work
<djszapi> I am not saying that is the culsprit
<slangasek> btw, what does your disk partitioning scheme look like?
<djszapi> the original working got a decent cleanup
<djszapi> my worry is that if it works only with hard coded sleep :(
<djszapi> that would be a pity
<djszapi> so that would defeat the robust system purpose.
<slangasek> true, it would; and we've tried hard to avoid using sleep in our startup scripts because sleep only hides a race, it never fixes it
<djszapi> we can agree upon this.
<slangasek> this is exactly why you'll find resistance to the idea that SysV is doing anything right - it's not, it's just much, much slower ;)
<djszapi> slangasek: only sleep helps
<djszapi> I have put back everything except sleep
<slangasek> clever
<slangasek> that means there's a kernel bug
<slangasek> because calling 'udevadm settle' following 'stopped udevtrigger' guarantees that the kernel's queue of coldplug events is empty and udev has processed them all
<slangasek> actually, wait, it doesn't guarantee there's a kernel bug either, because USB in particular can have devices show up on the bus for the first time *after* coldplugging
<slangasek> djszapi: I would suggest editing /etc/init/udevmonitor.conf to comment out the 'stop' rule, then reboot, then call 'service udevmonitor stop' by hand after boot
<slangasek> then post /var/log/udev somewhere
<djszapi> I do not have time for that, sorry.
<slangasek> ... unless you prefer to stick with the 'sleep' option
<slangasek> ok
<djszapi> hacking the base system upside down is even worse than any sleep
<slangasek> fundamentally, this scores one of the weaknesses of relying on any sort of a static event to tell you the devices are all up... because upstart can't actually be sure they are, because the kernel and udev aren't sure that they are
<slangasek> s/scores/underscores/
<djszapi> tell me a better way
<djszapi> which is working, really.
<slangasek> which is why the tty-device-added would have been the better solution, but you ran into problems there
<djszapi> that is broken
<slangasek> and to understand why it wasn't work, I'd need to see a udev log
<djszapi> give me a foobar.conf
<djszapi> and command set
<djszapi> I can spend half an hour with this
<djszapi> not more.
<djszapi> if you think that helps you, I can help
<djszapi> but I do not have more time, sorry.
<slangasek> if you have a solution that works for you, let's not spend any more time on it
<djszapi> sleep 30 -> this is the current solution
<djszapi> but super fragile.
<slangasek> the only way it would help me is to give me the satisfaction of knowing your job was written the Right Way ;)
<djszapi> there is no right way
<slangasek> but to make any progress I definitely need to see a complete udev log
<djszapi> we went through those, none of them worked.
<djszapi> give me a start line
<djszapi> I can spend half an hour
<djszapi> warning: not more
<djszapi> /etc/init/udevmonitor.conf -> stop rule: commented
<slangasek> right
<slangasek> then reboot
<djszapi> no matter what start line ?
<slangasek> yes
<djszapi> in my job ?
<djszapi> yes what ?
<djszapi> start on runlevel [23] and stopped udevtrigger
<djszapi> this is the current start line
<slangasek> then, once booted and you can confirm that your tty is present in /dev/, run 'service udevmonitor stop' and post /var/log/udev
<slangasek> yes - to give you a better start line for your job, I first need the debugging info from udev
<slangasek> which requires a reboot just to get that
<slangasek> so ignore your own job for now, we just need the complete udev log
<djszapi> I am paid for this job, I cannot ignore ;)
<slangasek> the purpose of this reboot is to *just* get the udev log
<slangasek> whether the job starts or not on this reboot is irrelevant to this question
<djszapi> root@linaro-ubuntu-desktop:~# service udevmonitor stop
<djszapi> udevmonitor stop/waiting
<djszapi> root@linaro-ubuntu-desktop:~# 
<djszapi> you got I was joking right ?
<slangasek> heh... sorry, sometimes it's hard to get the humor on IRC
<djszapi> ->/var/log/udev is HUGE
 * djszapi is intalling wgetpaste
<djszapi> heh not available, darn...
<slangasek> pastebinit :)
<djszapi> how ?
<djszapi> scrolling over a large file is not possible
<djszapi> time and buffer wise
<slangasek> there's a "pastebinit" command in the Ubuntu archive
<djszapi> here you go anyway: http://paste.pocoo.org/show/584182/
<djszapi> done by wgetpaste from the host
<djszapi> after scp'ing the file in question
<slangasek> ok
<djszapi> pastebinit is not a vailable on my linaro ubuntu for the pandaboard, sorry.
<slangasek> well, it's in the Ubuntu archive ;)  but ok
<slangasek> are you using an initramfs when booting?
<djszapi> no clue, sorry.
<slangasek> ok
<slangasek> I'll assume you are then
<slangasek> udev starts at 9.82s after boot.  kernel sees ttyUSB0 at 13.35s after boot.  That may or may not be enough time that coldplugging has missed the event
<djszapi> dmesg | grep initramfs
<djszapi> [    0.372070] Trying to unpack rootfs image as initramfs...
 * slangasek nods
<djszapi> what next ?
<slangasek> so I would expect 'start on tty-device-added DEVNAME=ttyUSB0' to do the right thing
<slangasek> is that one that you tried?
<djszapi> nope
<djszapi> tty-device-added DEVPATH=*ttyUSB0
<djszapi> I tried that one.
<djszapi> Note the star.
<slangasek> yeah
<slangasek> that should *also* have worked
<djszapi> then yep, I tried.
<djszapi> went nowhere usable.
<djszapi> can I restore the stop rule in here: /etc/init/udevmonitor.conf ?
<slangasek> yes
<djszapi> http://paste.kde.org/460154/ -> this essentially right ?
<slangasek> oh, actually, I see that the tty subsystem event comes before the usb-serial subsystem event
<djszapi> oh ?
<djszapi> PL2303 usb-serial converter
<djszapi> that resides between the pandaboard and the modem.
<djszapi> because the pandaboard and the modem both have male serialport connection
<djszapi> and I have not bothered with fixing that.
<djszapi> since I had a usb-serial converter by off-hand.
<djszapi> both should work anyway...
<djszapi> so what can we do if any ?
<slangasek> whoops, no, we don't get a usb-serial udev event anyway, only a kernel event
<slangasek> and that udev event is emitted after both the kernel events
<djszapi> well
<djszapi> I am now trying the start on tty-device-added DEVNAME=ttyUSB0 line
<djszapi> let me know if you need any logs.
<djszapi> after a boot
<slangasek> no logs, though I'm interested to know if that works
<djszapi> lol
<slangasek> oh wait
<slangasek> DEVNAME=/dev/ttyUSB0
<djszapi> yeah ?
<slangasek> so DEVNAME=ttyUSB0 will definitely fail
<slangasek> sorry
<djszapi> right, that is why I have been recommended by the stars
<djszapi> though hard coding is not that bad in this special case
<djszapi> since it is always like that
<djszapi> ttyUSB0 is right under /dev
<djszapi> if not, many stuff will break in the world :D
<slangasek> yeah; either DEVNAME=*/ttyUSB0 or DEVNAME=/dev/ttyUSB0 should work
<slangasek> and if those don't work, I think this is a kernel driver bug
<djszapi> now: start on tty-device-added DEVNAME=/dev/ttyUSB0
<djszapi> phantastic...
<slangasek> because we should not be seeing these events before the driver is initialized and ready for use
<djszapi> there is already a pl2303 kernel bug
<djszapi> I did not even bother to report it
<djszapi> since I have no clue where to report that
<djszapi> and I do not wanna spend hours for finding where to report
<slangasek> I could tell you where based on 'uname -r'
<djszapi> 3.1.1-26-linaro-lt-omap
<djszapi> linaro just wraps upstream IMO
<slangasek> in a manner of speaking
<slangasek> in the case of the pl2303 bug, that's probably true
<slangasek> this bug may be an omap-specific usb bug though
<djszapi> perhaps
<djszapi> but the other bug was appearing on my Lenovo Thinkpad 510 laptop
<djszapi> two connected usb-serial
<djszapi> second did not work
<djszapi> not even with stty -F :)
<djszapi> in any case
<slangasek> https://bugs.launchpad.net/linux-linaro to report issues with the omap kernel
<djszapi> my binary is not even run (according to "ps aux | grep foobar") after the start on ... line.
<slangasek> hmm, really?
<djszapi> really.
<djszapi> that is what I said above as well
<slangasek> I think you should just revert to the 'sleep' for now then, sorry
<djszapi> http://paste.kde.org/460160/
<slangasek> hmm
<slangasek> I don't know why that's not working
<djszapi> I wonder how long sleep I should put in there.
<djszapi> not to get a brittle system
<slangasek> nor do I
<djszapi> start on runlevel [23] and stopped udevtrigger
<djszapi> do I need both before a sleep ?
<djszapi> or just the second ?
<slangasek> probably the second is enough
<djszapi> let me try.
<djszapi> sleep 20 is now what I do
<djszapi> trying atm with 10 secs.
<djszapi> I just wonder what the border is. :-)
<djszapi> I will not use this low value for sure.
<djszapi> (in the end)
<djszapi> slangasek: second is enough, yeah.
<djszapi> slangasek: what should be the stop line ?
<djszapi> jodh, SpamapS and slangasek: thank you for your help
<slangasek> stop line> I don't know, when do you want it to stop? :)  'stop on runlevel [016]' would be typical
<marcoceppi> I've written an upstart script, and the script requires a HOME environment, I have a user for the daemon to run as, how do I let upstart script know where HOME is and pass that env on to the exec command?
<marcoceppi> I tried adding evn HOME="/home/user" to the upstart script with no luck
<slangasek> s/evn/env/ ?
<marcoceppi> slangasek: yes typo in chat, not a typo in the config
<slangasek> ok, just checking
<marcoceppi> here is the current upstart script
<marcoceppi> (if it helps)
<marcoceppi> http://paste.ubuntu.com/937599/
<slangasek> it's possible you also need to 'export HOME'
<slangasek> I'm not sure what the semantics of env vs. export are, honestly
<slangasek> I'm not convinced the manpage describes the current behavior accurately
<slangasek> hmm... but I see other jobs on the system that use that just fine
<marcoceppi> I'll give export a quick try
#upstart 2013-04-16
<loki77> hi - I'm trying to convert postgresql 9.1 to using upstart.  It works fine for the most part, but my post-start script hangs forever, and basically makes it so I can't do anything with the job, whenever there's an issue with starting postgres.  I tried having it fail after 10 retries, but I couldn't figure out how to then let upstart know that the job had failed from within post-start, as exit 1 doesn't seem to do what I'd hoped.. an
<xnox> we should add to the topic "Please pastebin jobs if need help troubleshooting them"
<xnox> wait he posted to mailing list. That's fine then.
#upstart 2013-04-17
<twb> As at Ubuntu 10.04 (upstart 0.6.5-8), where do default ulimits come from, when they're not set in the init job?  Is it just /etc/security/limits.conf like normal?
<twb> Apparently I have a python daemon that's cracking the shits about only being allowed to open 500 files at once, and I can't see where that's being set on my server.
<twb> Hm, /proc/N/limits says $user is lying, since that limit is set to 1024/4096
<salty-horse> hi. this is a bit off-topic. does start-stop-daemon allow two separate services that use the same <command> in "start-stop-daemon --exec <command>" ?
<xnox> salty-horse: sure, why wouldn't it? each invocation of start-stop-daemon doesn't know about any other invocations.
<xnox> salty-horse: make sure you use more parameters to identify which instance is which (e.g. using pidfiles, etc)
<xnox> jodh: awesome inotify branch !
<jodh> xnox: thanks :)
<salty-horse> xnox, thanks! so should I use --pidfile instead of --exec? what if both commands have the same --exec but different --pidfiles? would that be enough to differentiate them? or does it make no sense to have several "matching" flags?
<xnox> salty-horse: "--exec foo --pidfile minifoo.pid" and "--exec foo --pidfile bigfoo.pid" are different and thus correct one will be stopped/reloaded/restarted/etc
<xnox> salty-horse: but e.g. I'd rather recommend you to use upstart & it's support for instances =)
<salty-horse> xnox, in my case, each so called "instance" has different flags. does this still fit the definition of upstart instances?
<salty-horse> I'm specifically trying to run both a mongodb "regular server" and a mongodb "config server". someone copied the upstart conf file, and modified it, but now both files have the same --exec, and only one of them has a --pidfile. so they stepped on each other's toes and I could not start both at the same time
<salty-horse> I sense setting a --pidfile on both is the simplest solution
<xnox> salty-horse: it should, but it all depends on your usecase. E.g. /etc/init/network-interface.conf defines "instance $INTERFACE" thus one gets a running job per each configured network interface. There are other examples, just grep for "instance" in /etc/init/
<xnox> salty-horse: using a human-identifiable "instance $NAME" will get you what you want, e.g. "production", "staging", "testing", "dev" ...... mongodb servers =)
<xnox> but it kind of assumes that you can structure all your mongodb servers in a homogenic way. E.g. for each of them you start up with --config /etc/mondonbd/$NAME.config
<xnox> or shell you have shell to select what ever you need based on the instance name =)
<xnox> (e.g. any options, ports, etc....)
<salty-horse> xnox, from what I'm reading about isntances, they require an extra parameter on the startup command. I'd rather not deal with variables. I want a simple "service NAME start"
<xnox> salty-horse: then create different jobs for each one. Or you can create wrapper jobs: e.g. configmongodb.conf will simply have "start mongodb NAME=config", and all the common-logic will be in the mongodb.conf
<xnox> salty-horse: that way you aid maintainance, by not repeating the same snippet in each job.
<xnox> salty-horse: or have normal jobs, without instances, but source shell in pre-start script if there is anything significant to share between each mongo jobs.
<salty-horse> that seems overkill for my current problem, but I appreciate the knowledge for future configurations. if a job only has "start ..." does upstart still knows how to shut it down correctly?
<xnox> salty-horse: good point. i think one would also need similar stubs for "stop/restart/reload mongo NAME=config" then in pre|post-start|stop =( 
<salty-horse> :)
<xnox> possibly something like 5-6 lines in total for the whole conf.
<xnox> cause one would simply test what the goal is in "pre-start" & "pre-stop" & "post-start"
<xnox> *sigh*
<salty-horse> thanks a bunch. sorry for depressing you about upstart inflexibility. at least now you can add a new keyword that does that magic
<xnox> salty-horse: nah, it's ok =) if I complain about upstart, I'm the one who has to implement features in it ;-)
<leandrosansilva> Hello. Is it possible to create custom events? I created a service called service1 and put the code "emit my_event" and I also created another one called service2 and put "start on my_event". But, when I start service1, service2 doesn't start. Probably I'm doing something (everything) wrong, but what?
<leandrosansilva> Currently I'm reading the upstart cookbook, but there's much do be seen there
<xnox> leandrosansilva: instead of emitting & catching events you can simply do: "start service2" in service1.conf, or in service2.conf "start on started service1"
<xnox> leandrosansilva: can you please pastebit full jobs. Did you declare that service1 emits events using "emits" stanza? http://upstart.ubuntu.com/cookbook/#emits
<leandrosansilva> The problem this is just a test. I really don't need these services. In fact I need to start a service as soon the network starts (it's a daemon which needs to access some external services on the local network), and I'd like it started on event static-network-up, but it didin't work
<leandrosansilva> and I don't want to change the networking service
<leandrosansilva> oks, just a minute
<xnox> leandrosansilva: please note that once an event is emitted - it's gone, adding new jobs will not "magically notice the event"
<xnox> you can download upstart-gui to monitor the events emitted on the buses.
<leandrosansilva> So I think I must solve my problem in another way
<leandrosansilva> what I need is just this: my daemon must start just after the network is up
<xnox> leandrosansilva: please paste your jobs, or describe your problem.
<leandrosansilva> and I wouldn't like to change networking.conf to start my daemon there
<xnox> leandrosansilva: "start on (local-filesystems and net-device-up IFACE!=lo)"
<leandrosansilva> my idea is making my daemon (called capturad) depends on networking
<xnox> that means start onces file-systems got mounted & there is any kind of network connection (non-localhost only)
<xnox> leandrosansilva: documented at http://upstart.ubuntu.com/cookbook/#normal-start
<leandrosansilva> oh, it's easier than I thought
<leandrosansilva> I'll try this
<leandrosansilva> a moment...
<xnox> leandrosansilva: well you need to reboot to test / generate those events properly =))))
<leandrosansilva> hum.. So it may be the problem
<leandrosansilva> I haven't restarted
<leandrosansilva> xnox, wIth a simple daemon, "start on (local-filesystems and net-device-up IFACE!=lo)" seems to work. Let me check with the real daemon. Anyway, thanks a lot for your help!
<xnox> no problem
<leandrosansilva> xnox, I've tested with the real daemon and it worked correctly. Thx again
#upstart 2013-04-18
<tjaalton> hey, there's this nasty bug in lightdm upstart job that causes it to race with plymouth-splash. it's kinda easy to fix, but not for the case where plymouth is on the initrd (like when cryptsetup is used) because it won't emit events to the later phase
<tjaalton> so the plan is to create a job that emits an event "on startup or started plymouth-splash"
<tjaalton> but is there a 'generic' event for when the system has passed initrd phase?
<stgraber> passed the initrd phase => startup
<stgraber> upstart only starts when we switch from the initrd to the real system, so "startup" would currently work. Maybe one day we'll have upstart in initrd, then that will no longer be true.
<tjaalton> well, that didn't seem to work or I failed in some other way
<tjaalton> start on startup or started plymouth-splash
<tjaalton> emits plymouth-splash-running-4-shure
<tjaalton> and in script; "exec initctl emit --no-wait plymouth-splash-running-4-shure"
<tjaalton> but debug log didn't show any sign of that
<tjaalton> maybe I'll just try harder this time..
<jodh> tjaalton: there is no generic "passed initrd" event as upstart doesn't know about that phase of the boot - it happens before upstart starts.
<tjaalton> jodh: ok, the bug in question is https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/982889 and comment #120 is what I'm trying to accomplish
<tjaalton> jodh: should that be possible?
<xnox> jodh: tjaalton: don't we emit something to plymouth to indicate that we passed initrd....?
<tjaalton> xnox: doesn't work when plymouth was started from initrd
<tjaalton> the bug is trivial to fix for the normal case, but the special case makes it.. special
<jodh> xnox: we pass "update-root-fs --read-write" to plymouth when the disk is writeable.
<xnox> jodh: yeah. which is quite late for this bug, isn't it?
<xnox> quite racy with's lightdm starton.
<jodh> tjaalton: I think what slangasek actually means in #120 is for this secondary job to check for a "plymouth" process running (or "plymouth --ping" returning successfully).
<tjaalton> jodh: yes, maybe it's the details that got me confused then
<tjaalton> like, when to run that job
<tjaalton> and should it just sleep N until plymouth is running and then emit the event?
<tjaalton> maybe it shouldn't have any preconditions, just check for plymouth and be done with it
<jodh> tjaalton: that's the only way it could work I think - check "status plymouth-splash" and check "plymouth --ping" return code.
<tjaalton> alright I'll give it a go
#upstart 2013-04-19
<Tor-Mentor> Hi! im having some wierd problems with my scripts and bash_completion. Service does not autocomplete my scripts but initctl does. Does it depend on the content in the scripts somehow?
<jodh> Tor-Mentor: /usr/sbin/service is *not* an upstart command - it's a SysV one. However, to make life more familiar, links are created from /etc/init.d/$foo to the corresponding upstart jobs in /etc/init/ to allow you to continue to use that command.
<jodh> Tor-Mentor: hence, if you want the bash completion, please use initctl.
<Tor-Mentor> aahh thanks. That clears that one up! 
<tjaalton> do you folks see anything alarming on this job http://pastebin.com/2bZu24yG
<jodh> tjaalton: you don't need the "console output". It's possible your job will never detect plymouth-splash running though I think as your job is probably going to start after plymouth-splash.
<tjaalton> jodh: oh right, that was cruft..
<jodh> tjaalton: also, your job is going to run that ping in a very tight loop.
<tjaalton> ugh, yes :)
<jodh> tjaalton: are you looking to put this change into raring?
<tjaalton> jodh: if possible, yes
<tjaalton> ok added 'sleep 0.1 after fi
<jodh> tjaalton: ok - if this goes in though and other jobs are changed to make use of the new event, I lot of testing is going to have to happen in the next week :)
<tjaalton> jodh: yeah..
<tjaalton> only lightdm for now I think
<jodh> tjaalton: ok. Are QA aware they'll need to test this?
<tjaalton> not yet
<tjaalton> slangasek suggested to use 'start on startup or started plymouth-splash' and it worked this time (didn't before for some reason)
<jodh> tjaalton: just spotted another problem: you 'if' and 'while' reference 'STARTED' where it should be '$STARTED'.
<tjaalton> this can go in plymouth in any case
<tjaalton> testing lightdm can be done as an sru
<tjaalton> duh
<tjaalton> good thing lp timed out when adding it to the bug..
<tjaalton> :)
<tjaalton> it's a monster bug with 100+ dupes
<tjaalton> ok, the upstart job is now good enough, thanks for your help :)
<elmo> jodh: hey is there an ETA for the upstart dbus bridge  and/or anything already written?
<jodh> elmo: no concrete eta, although I was hoping to have something for 'S'. No code yet. We have a dconf/dsettings bridge that's almost complete.
<elmo> jodh: ok, cool, just curious, most of my ideas for user upstart jobs would trigger off of dbus
<slangasek> AIUI a dbus bridge is not currently a priority for the desktop team
<slangasek> we'll double-check that with them next month, though
<elmo> FAOD, my curiousity is entirely idle/spare time and not professional :)
<slangasek> elmo: so you're not writing a job that runs 'juju deploy' based on an incoming indicator-message event? ;)
<elmo> yes, that's my plan for juju auto scale
<elmo> pagerduty + ubuntu webapps + indicator-osd + upstart-dbus-bridge + user upstart job -> juju add-unit
<elmo> :-P
<elmo> (oh god, that's so horrible, I want to bleach out my own mind)
 * slangasek giggles
<elmo> no, FWIW, I mostly want to be able to see things like network changes and screen lock/unlock events, which AFAIK are announced most usefully on DBus
 * slangasek nods
<xnox> slangasek: that quote on the wiki, got me scared =)
<slangasek> xnox: is your entire life RSS-driven? :)
<xnox> slangasek: ssshhh
<xnox> slangasek: have you seen this yet http://youtu.be/A25VgNZDQ08 that was my reaction when I heard the news about google reader shutdown.
<slangasek> funny thing is, I had just started using Google Reader on my phone two weeks before the announcement
<xnox> slangasek: yeah, I'm waiting for newsblur to scale, their mobile app is good enough. They are scalability issues, since they got effectively DDOSed after google reader announcement.
 * xnox ponders if Blogger and Feedburner are the next to get the cut. Cause clearly people should blog by doing "public posts on G+"
<slangasek> "It may amaze you gentlement that Orkut is still up and running" -hahaha
<slangasek> xnox: right... except for the days that G+ is failing to add stuff to your stream
<slangasek> (I had a ~16h outage where people I'm following were not having their posts showing up in my stream - right before the google docs outage)
<xnox> ouch.
<xnox> well..... I can't tell the difference on my G+ feed really. Half of it is cats, the other half is people playing ingress.
<slangasek> you should follow more interesting people
<slangasek> like jodh
<slangasek> O right, all his G+ posts are links to his blog which you already have in RSS ;)
<xnox> =))))
<xnox> i follow people who reshare interesting rss feed posts via google reader instead =)
#upstart 2014-04-15
<spike> is there a recommended blueprint for starting tomcat 6 as a non-root user with upstart on RHEL?
<spike> limited to the repo supplied 0.6.5 release sadly
#upstart 2014-04-16
<CADBOT> Hi
<jonafan> how do you save the logs for an upstart service forever
<jonafan> every time i search for this i get some dumb nodejs crap
<dstokes> you just trying to save the output of your service to a log? (not sure what you mean by 'forever')
<dstokes> jonafan: ping
<jonafan> yes
<dstokes> use io redir? `exec some_process > /var/log/output.log 2>&1`
<dstokes> whoops, should probably use >> instead to append
<jonafan> okay that'll work
<jonafan> >>s for both, right?
<jonafan> this is a very exciting day for me now
<jonafan> i restarted the process and the pid it ended up with is 1337
<dstokes> jonafan: `exec some_proc >> /var/log/output.log 2>&1`
<jonafan> aw man, there goes 1337
<dstokes> redirects stderr to stdout and stdout to file
#upstart 2015-04-14
<goku417> Hi everybody !
<goku417> I have a question for all of you, I wonder how I can make my script run after the network is up... I tried everything like "start on started net-device-up" and "start on static-network-up"
<goku417> and it still sends me that my script can bind with the ip who is associated with the interface
#upstart 2015-04-15
<philm88> Hi all, I'm trying to get upstart to launch my kiosk-mode service on boot. Essentially, it starts a minimal window manager, starts firefox and uses xdotool to simulate pressing F11 and putting firefox into fullscreen mode. It's that last part I'm having issues with. - I can't get xdotool to work in the context of an upstart conf. I suspect it could be becuase DISPLAY isn't set at that point, but not sure how to confirm that. Do
<philm88> it's also probable that I'm just trying to do things with upstart that it wasn't meant to do
#upstart 2015-04-16
<tomprince> Is there some way to provide a service configuration that isn't automatically enabled.
#upstart 2016-04-19
<dz0ny_> http://upstart.ubuntu.com/wiki/Stanzas < rate limit reached for all requests
<timmy_tofu> I've put a little conf (that just echos) as a session job in ~/.config/upstart/ on an EC2 instance, but it isn't found. The same config works on my local machine, though. I tried initctl reload-configuration, but that didn't help (errored as user, run but changed nothing as sudo)
<timmy_tofu> And it works as a traditional upstart task placed in /etc/init/ and run with sudo start - any idea how I can go about figuring out why it work work as a session job as it does locally?
<timmy_tofu> It's something to do with not being in an X environment, but I dunno if I'll be able to solve that: initctl: Unable to connect to session bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
<timmy_tofu> I see some instructions in the cookbook, but the cure looks worse than the disease, so I'll just make it a system job
#upstart 2016-04-21
<owen1_> what's wrong with my script? http://paste.ubuntu.com/15958047/ sudo stop neo => stop: Unknown instance:
<owen1_> 'sudo start neo' seems toworks fine
<owen1_> to work fine
<owen1_> i modified my script since it's a service and not fire and forget - http://askubuntu.com/questions/759706/how-to-write-upstart-script-for-a-background-service-db
#upstart 2016-04-22
<cristian_c> hi
<cristian_c> I've to convert a sysv/upstart daemon to a systemd service
<cristian_c> I've read the migration documentation but I need to get information about some field values of the .service file
<cristian_c> I need to know what value to use in Type= field and what value in After= field
<cristian_c> Any ideas how to retrieve these?
<dz0ny_> cristian_c: study https://wiki.archlinux.org/index.php/systemd
<dz0ny_> this is the best resource on systemd
<dz0ny_> and arch has aur where you can probably find already written service file for your app
<cristian_c> dz0ny_: i've read the systemd ebook psankar 'systemd for administrators' from part 1 to part 8
<cristian_c> dz0ny_: is this your link you have suggested me: https://wiki.archlinux.org/index.php/systemd ?
<cristian_c> dz0ny_: could you post again what you have written in this channel before?
#upstart 2016-04-23
<cristian_c> hi
<cristian_c> I've to convert a sysv/upstart daemon to a systemd service
<cristian_c> I've read the migration documentation but I need to get information about some field values of the .service file
<cristian_c> I need to know what value to use in Type= field and what value in After= field
<cristian_c> Any ideas how to retrieve these?
#upstart 2016-04-24
<cristian_c> hello
<cristian_c> I've to convert a sysv/upstart daemon to a systemd service
<cristian_c> I've read the migration documentation but I need to get information about some field values of the .service file
<cristian_c> I need to know what value to use in Type= field and what value in After= field
<cristian_c> Any ideas how to retrieve these?
<cristian_c> .
#upstart 2017-04-19
<MindSpark> hello
<MindSpark> https://paste.ubuntu.com/24415331/
<MindSpark> when I stop this service, I get unknown instance
<MindSpark> and the jobs don't get stopped
<MindSpark> can someone help me?
#upstart 2017-04-21
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<ko_lo> o/
<ko_lo> I'm playing around with upstart (1.12). I'm trying to add a new job as an unprivilegied user. I added it to ~/.config/upstart/save.conf
<ko_lo> I checked the file with init-checkconf and it's ok
<ko_lo> but I can't initctl check-config (Inalid job class: save)
<hallyn> did you set UPSTART_SESSION before running it?
<hallyn> (running initctl check-config save, that is)
<hallyn> ko_lo: ^
#upstart 2017-04-22
<ko_lo> hallyn: I've to set it befire running initctl or running initctl set it for me?
<ko_lo> because I didn't set it, I wasn't aware of it
<ko_lo> so in order to init the job, I need to set thos var, fo the initctl checkconf thing and then it should work?
<hallyn> ko_lo: as an example, I have ~/bin/start_upstart_job as http://paste.ubuntu.com/24431042/  
<hallyn> it's possible that unity desktop sets it for you.  i'm running different wm so i have to do it all by hand
<ko_lo> yeah but my goal is to have it run as desktop-start
<ko_lo> so if I follow this, it will be started by the script? or I'm mossing something
<ko_lo> https://0bin.net/paste/zaUN7E9bb+v1jcyC#A4Pb7ubYX2CkBI9kt4fiN1dLQB46ifxq6apOWGuOULe this is my script
<ko_lo> I want to run it when the user end his session. internet told me to use upstart but perhaps I got the whole thing wrong :)
<hallyn> your bin requires js
<ko_lo> ywah it's unvrypted client side. hold on I'll upload somewhere else.
<ko_lo> http://paste.ubuntu.com/24431724/
<hallyn> ko_lo: hm.  looks fine - though maybe you want to make it 'start on starting desktop-stop', that way desktop-stop won't actually start until your job is done?
