#upstart 2006-09-18
<mbiebl> Keybuk, hi
<Keybuk> ello
<mbiebl> I currently studying the code and noticed, that "pid file" does not yet have any effect.
<mbiebl> init/job.c -> job_run_process always uses the pid returned from fork.
<mbiebl> If job->pidfile is specified it should parse the given file for the pid file instead.
<mbiebl> I also don't understand, why "pid file" can only be specified together with respawn.
<Keybuk> right, it's not implemented
<mbiebl> Imho it would also make sense together with exec.
<Keybuk> was supposed to only make sense with daemon :p
<mbiebl> Yeah, but a daemon can also be started with exec, or not?
<Keybuk> yes
<mbiebl> I also think, that a reload and maybe also a restart utility would be great.
<Keybuk> there's no implementation for reload yet
<mbiebl> It should also be possible to specify in the job description file a custom reload function.
<Keybuk> probably yes
<Keybuk> actions are in the todo somewhere
<Keybuk> got to get events and jobs right first though
<mbiebl> Sure ;-)
<mbiebl> Oh, another thing, more from the packaging perspective:
<mbiebl> in postinst you call kill directly. Maybe it would be safer to specify the complete path as kill is a bash builtin
<mbiebl> iirc lintian also moans about that.
<Keybuk> why would you need to do that?
<Keybuk> what's wrong with the builtin?
<mbiebl> They could behave differently and you don't notice as long as you run bash.
<Keybuk> they'd at least behave consistently
<Keybuk> it's /bin/sh
<Keybuk> so kill must behave like POSIX kill
<Keybuk> kill -TERM 1 is therefore legal
<mbiebl> Is it guaranteed that the bash builtin kill behaves exactly as /bin/kill?
<mbiebl> I'm not sure.
<Keybuk> yes
<Keybuk> what's bash got to do with it anyway?
<Keybuk> /bin/sh on Ubuntu is dash
<mbiebl> Well, if the builtin and /bin/kill behave exactly the same, then the point is moot.
<Keybuk> indeed
<mbiebl> You seem confident so I take this point as resolved ;-)
<Keybuk> well, if a shell installs itself as /bin/sh and doesn't implement the POSIX-specified behaviour of kill, then that's a bug in that shell
<Keybuk> if the user replaces /bin/sh with a non-POSIX shell like zsh, and complains; then the bug can just be rejected :p
<mbiebl> As you already have feature freeze for edgy I was wondering if you also plan to migrate initscripts or parts of initscripts to upstart jobs.
<Keybuk> not in edgy
<Keybuk> beta freeze is only a few days away! :P
<Keybuk> and have other bugs to be fixed for that
<mbiebl> yeah, bug fixing should always have top priority, even if it's not so much fun :-)
<Keybuk> fortunately there don't seem to be any upstart bugs
<mbiebl> That speaks for your coding skills
<Keybuk> well, no major ones anywhere
<Admiral_Chicago> i'm on Knot 3 and i did an apt-get update
<Admiral_Chicago> initscript is a package that is being updated
<Admiral_Chicago> is that right?
<jbailey> Keybuk: The only two problems I had were 1) The upgrade also included glibc and I was still running the hack'd upstart.  It wasn't taking signals, glibc locked in postinst. =)
<jbailey> 2) In single user mode, terminal type seems to be not set correctly, and "reboot" command didn't work.
<jbailey> Although from a command prompt now, C-M-Del seems to get registered correctly now.
<Keybuk> jbailey: isn't glibc supposed to work unconfigured? :)
<Keybuk> hmm, will test the single user mode thing
<Keybuk> reboot should work even better than sysvinit (no pesky "unable to obtain runlevel" type thing)
<jbailey> Keybuk: It does.  It was that the postinst I think HUPs pid 1 or something like that.
<jbailey> Keybuk: So I killall'd that, then dpkg --force-depends -i upstart*deb
<jbailey> Reboot, finished upgrade ;)
<Keybuk> oh, and you had the hack'd upstart that didn't work? :p
<pepsiman> Keybuk: single user doesn't run bash
<jbailey> Right. =)
<Keybuk> pepsiman: err, yes?
<pepsiman> it did in dapper
<Keybuk> actually it ran sulogin in dapper ;)
<pepsiman> yes, and sulogin looked at /etc/passwd in dapper
<Keybuk> right
<Keybuk> can probably hack that
<Keybuk> or just use the real sulogin
<pepsiman> bug 60965
<jbailey> Keybuk: Path of least resistance: use the real sulogin.
<Keybuk> pepsiman: yes, I saw it
<jbailey> Solve that problem sometime in +1 =)
<Keybuk> jbailey: yeah, was planning to move that to sysvutils too, just hadn't got around to it yet
<Keybuk> was gonna do that along with fixing check*
<jbailey> Cool.
<jbailey> So for ppc64, I think it's properly cooked now.  I should test on the older kernel as well, I s'pose.
<jbailey> Actually, I'll focus on getting my HD working with the stock edgy kernel so I don't have to roll my own.  Easier.
<Keybuk> jbailey: oh, I see why shutdown doesn't work in single-user mode
<jbailey> Keybuk: Cool.  Need something in Malone, or is this good enough?
<Keybuk> not sure it's actually fixable :-/
<Keybuk> not for edgy, anyway
<jbailey> Err...
<jbailey> Need to have *some* way of getting back to a full state.
<jbailey> exit didn't work either, IIRC
<Keybuk> exit should work
<Keybuk> it's making exit work that's causing shutdown to not work
<Keybuk> oh, hmm
<Keybuk> exit doesn't work either
<Keybuk> meh
<Keybuk> yes, bug me
<jbailey> Two bugs or one?
<Keybuk> only one of them will be fixable
<Keybuk> reboot is more important, so I'll fix that
<pepsiman> init: sulogin process (3353) killed by signal 9
<pepsiman> System halted.
* pepsiman wonders why poweroff wasn't killed that time
<Keybuk> hmm? poweroff shouldn't get killed?
<pepsiman> that was the 4th attempt at poweroff
<Keybuk> jbailey: the reboot bug is that there's currently no way for upstart to tell the difference between sulogin being killed by a signal or the user typing "exit"
<pepsiman> how did sysvinit tell the difference?
<Keybuk> runlevel change
<pepsiman> ah
<Keybuk> it's a bug, or at least a lack of an implementation in upstart that causes this bug
<Keybuk> but it's not something I can implement before Beta Freeze
<jbailey> Keybuk: rewind a sec for me?  what kills sulogin with a signal?
<Keybuk> which is IN THREE DAYS TIME
<Keybuk> PANIC!!!!
<jbailey> Is that a sideeffect of runlevel change?
<Keybuk> jbailey: sendsigs ;)
<Keybuk> and killing sulogin forces a runlevel change, stopping the running reboot
<jbailey> Oh.  Weird design.
<Keybuk> well, how would you have done it?
<jbailey> I'm not sure. =)
<Keybuk> I couldn't remember what happened with sysvinit if you ran telinit from the shutdown process :p
<theCore> upstart is so boring... there is barely any bugs to find :)
<mbiebl> Keybuk: debian/control: system-services: Is there a reason why you explicitely depend on util-linux?
<mbiebl> util-linux is essential, so it shouldn't be necessary to add this dep.
<Keybuk> I don't remember, no
<mbiebl> Would make one lintian error less.
<Md> mbiebl: are there any news about the sysvinit split?
<Keybuk> heh, I entirely got out of the habit of running lintian when I was maintaining dpkg
<Keybuk> don't think I've ever used it since
<mbiebl> Md: It's currently sitting in NEW.
<Keybuk> jbailey: looks like there's already a bug for the single-user problem
!Rez:*! :Hi, xFallenAngel would like to inform you that they have created ##google-apis for discussion of GAPIs (http://code.google.com/apis.html), if you are interested we would urge you to join. Thank you for using freenode and have a good day!
#upstart 2006-09-19
<Ingmar^> i'm having some issues with the cpu frequency modules not loading correctly
<Ingmar^> anyone able to help ?
<Ingmar^> running an Intel Pentium M 1.6 gHz
#upstart 2006-09-20
<vladanian> I've got an upstart question -- I'd been running it on edgy for a few weeks and it was working fine, but for the past couple weeks I've gotten hung up at boot on, "upstart: Error reading control message: Invalid message received."  Anyone encounter this?
<johnnybuoy> why is upstart good for me?
<johnnybuoy> hmm
<vladanian> In case anyone's interested, I've filed a bug: https://launchpad.net/products/upstart/+bug/61322
<johnnybuoy> this is kewl! init IS a bit old
<johnnybuoy> the problem: so is *nix :(
<johnnybuoy> the whole net thing in *nix is a hack
<johnnybuoy> prtty good hack, but still a hack
<johnnybuoy> but GO upstart
<mjg59> 23:47 < johnnybuoy> the whole net thing in *nix is a hack
<mjg59> ?
<johnnybuoy> hmm
<johnnybuoy> makers of UNIX admitted this, I fell on it when exploring a novel OS from them (the authors of UNIX): plan9
<johnnybuoy> UNIX was not designed with networks in mind, networks came later
<mjg59> I think it's hard to say it's a hack, given how well it works
<johnnybuoy> good hack
<johnnybuoy> but hack
<johnnybuoy> it *does* work well
<johnnybuoy> but it wrks beter in plan9 :)
<mjg59> In what ways?
<johnnybuoy> well, for egzample it only has one protocol for everything, but I'd think #plan9 would be a better place for this discussion
<che> the topic isnt accurate anymore... 0.2.7 is up
* ..[topic/#upstart:mbiebl] : Upstart 0.2.7 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/doc/getting-started.html | https://wiki.ubuntu.com/UpstartDesignChanges | irc logs: http://people.ubuntu.com/~fabbione/irclogs
<johnnybuoy> hello! how do I know if a service is started or not? with upstart I don't get the scrolling stuff when starting the pc.
<_ion> Upstart jobs: status jobname
<_ion> init.d scripts: /var/log/boot
<johnnybuoy> ok, thanks! Oh and great job all! my pc starts a *lot* faster now with upstart
<mbiebl> johnnybuoy: probably a placebo effect. atm upstart should be appox. the same speed as sysvinit.
<johnnybuoy> :D
<johnnybuoy> okok
<mbiebl> None of the init scripts was converted to upstart jobs yet, the boot procedure is basically the same (maybe the missing output makes it abit faster)
<johnnybuoy> tha problem is I do status fbsplash, and it doesn't know
<mbiebl> If you want comparable bootup times, install bootchart+bootchart-view
<johnnybuoy> what is that?
<mbiebl> bootchart - Boot process performance analyser
<johnnybuoy> ah ok.
<johnnybuoy> but now I don't have init...
<johnnybuoy> I can't compare :)
<johnnybuoy> I think it must be a little faster...
<mbiebl> If you are happy with upstart, that's all that matters ;-)
<johnnybuoy> or maybe that upgrade last night ..
<johnnybuoy> :)
<johnnybuoy> yes, very.
<mbiebl> Md: ping
<johnnybuoy> I'd like to know what jobs are started tho
<johnnybuoy> status don't work
<mbiebl> initctl list
<johnnybuoy> ahh
<johnnybuoy> maybe
<johnnybuoy> I don't get it
<johnnybuoy> this is not it
<mbiebl> You probably want to read /var/log/boot or remove "quiet" from the boot options.
<johnnybuoy> ah ok!
<johnnybuoy> that might be it
<Md> mbiebl: pong
<johnnybuoy> /var/log/boot: (Nothing has been logged yet.)
<johnnybuoy> :(
<mbiebl> Got a problem with one of your udev rules in /etc/udev/udev.rules
<mbiebl> Specifically the dm rule that prevents /dev/dm-X from being created.
<mbiebl> This breaks gnome-mount when used with luks encrypted partitions.
<mbiebl> johnnybuoy: Install upstart-logd
<Md> mbiebl: discuss this with the maintainers involved in dm. feel free to Cc me
<johnnybuoy> it's doing it right now, i think
<johnnybuoy> ok, thanks
<mbiebl> I talked to the hal dev (davidz and kay) and the said there is no good reason not to have /dev/dm-x
<mbiebl> I asked you, because /etc/udev/udev.rules is part of the udev package.
<Md> mbiebl: yes, but I do not know how dm works. I am sure that I added that rules for a reason (and every other distribution did too), so I will not remove it unless somebody can explain with authority why it's not needed anymore
<mbiebl> Redhat does not.
<Md> ok. still, I will not change the package in a way I do not understand so please look for a rationale
<mbiebl> The rational is, that cryptsetup itself does not need /dev/dm-*
<mbiebl> So it was removed with this udev rules.
<mbiebl> But 3rd party apps, like gnome-mount, rely on /dev/dm-*.
<Md> I think there was much more than cryptsetup
<Md> are you really positively sure that having udev create the devices will not break other dm components?
<mbiebl> According to kay and davidz it should not hurt (otherwise redhat would be busted anyway)
<mbiebl> I can ask the dm maintainer first if you prefer that.
<Md> ok, I will change this in the next upload today or tomorrow
<Md> yes, please ask him as well. just to be sure
<mbiebl> Ok, will do.
<Md> I added that rule may 30. I think there was a reason, but I really cannot remember it
<_ion> keybuk: grep respawn /etc/event.d/logd
<Keybuk> the // thing?
<_ion> Yep. :-) Not that it really matters.
<Keybuk> yeah, common side-effect of --exec-prefix=/
<maro_> hi :)
<maro_> do you know if upstart is supposed to completely replace sysvinit, or is it a long-term solution to depend on sysvinit-utils?
<Keybuk> maro: the things in sysvutils/sysvinit-utils are things that aren't really part of init
<Keybuk> so there's no particular reason for upstart to provide its own implementation of them
<maro_> hm, true :)
<maro_> are there examples of no-rc-compat setups yet?
<Keybuk> not yet
<Keybuk> we're doing the "release early and release often" thing, we're still at "early" :p
<Keybuk> the idea of doing the rc-compat stuff is that it proves the daemon works, while still letting us revert to sysvinit at a moment's notice if it doesn't
<maro_> ok, perhaps I can be the first then ;)
<Keybuk> go for it :)
<maro_> already did a full minit migration once, still have a graph somewhere
<maro_> minit is one-way depedency based though, so this will probably be a bit harder... anyway: http://borkware.net/~mark/minit.png :)
<Keybuk> heh, cute
<maro_> doesn't look that complex on a graph, but imagine every service being a directory containing a symlink to the executable, a file for parameters, optional (empty) "respawn" and "sync" files...
<maro_> running 'tree' in there gives me 63 directories and 211 files ;)
<Keybuk> yeah, djb-style config sucks :p
<maro_> djb-style does in general ;)
<Keybuk> *shrug* I still use qmail
<maro_> I wonder how hard it will be to make scripts for upstart ala the one I did to draw the graph
<maro_> (100 lines of sh)
<Keybuk> quite easy I should think
<maro_> we'll see :)
<maro_> anyway, need to get some sleep - sleep tight when the moon hits your timezone :)
<maro_> ah, just saw your reply on the list - sounds good :) - off now
<Keybuk> I tend to sleep when the sun is up :p
#upstart 2006-09-21
<johnnybuoy> hey all!
<Keybuk> hey
<fdsd> hey guys, is there a howto on how to disable startup daemons, like gdm..
<johnnybuoy> !upstart
<Keybuk> fdsd: is gdm being run by upstart, or just by sysv-rc?
<Keybuk> johnnybuoy: ?
<fdsd> Keybuk, no idea
<Keybuk> fdsd: which distro?
<fdsd> Keybuk, i need to turn off everything not need to just boot to the shell
<fdsd> edgy knot3
<Keybuk> you can disable gdm by renaming the /etc/rc2.d/S13gdm symlink to /etc/rc2.d/K13gdm
<fdsd> ok
<fdsd> Keybuk, no easy thing like in gentoo rc-update del gdm default?
<Keybuk> not in Ubuntu, no
<fdsd> ok
<Keybuk> (this has nothing to do with upstart, of course)
<fdsd> usplash is a pain in the neck in edgy
<fdsd> ugg
<johnnybuoy> well, yeah...
<johnnybuoy> it don't work, no?
<thom> (you could use update-rc.d)
<Keybuk> thom: except that always does exactly the wrong thing
<Keybuk> and results in an upgrade restoring the symlinks
<thom> right, because there's no way you can signal to make it persist without removing the init script
<johnnybuoy> really?
<johnnybuoy> hmm
<johnnybuoy> that's no good...
<kakalto> has upstart been tried under gentoo yet?
<Keybuk> I believe someone has, yes
<kakalto> succeedingly?
<Keybuk> haven't heard
<Keybuk> either way
<kakalto> any ideas what it would require for me to attempt to work it?
<Keybuk> usual, see the getting-started doc
<kakalto> cool
<kakalto> thanks
* Signon time  :    Fri Sep 15 06:01:04 2006
* Signoff time :    Thu Sep 21 08:34:09 2006
* Total uptime :    6d  2h 33m  5s
* Starting logfile irclogs/upstart.log
-ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
<Steven_Shiau> anyone know how to switch the default runlevel to 1 or 3 or other than 2 when edgy alpha3 boots ?
<Steven_Shiau> since now it's upstart, and /etc/inittab is no more.
<Keybuk> edit /etc/event.d/rc-default
<Keybuk> the default runlevel is 2
<Keybuk> and 3 is identical to it
<Keybuk> (assuming you have a fresh install, there's no particular reason you should bother with runlevels at all)
<Steven_Shiau> Thanks. that's true, but sometimes I need special runlevel to do special thing
<Keybuk> *nods*
<Keybuk> so for fresh install, edit /etc/event.d/rc-default and change "telinit 2" to "telinit 3"
<Keybuk> for upgrades, you will still have /etc/inittab and that will still be used
<Steven_Shiau> thanks. The version I am using is:  upstart        0.2.7-1
<Steven_Shiau> but I did not find /etc/inittab, so do you mean later version or ?
<Keybuk> I mean upgrades from dapper
<Keybuk> if you installed edgy fresh, you won't have an /etc/inittab because it's deprecated
<Keybuk> but if you upgraded from dapper, /etc/inittab will still be there, and the default runlevel specified in that will still be used
<Steven_Shiau> oh, ic. actually I did a fresh install.
<Keybuk> you could also, in edgy, do "echo id:3:initdefault: > /etc/inittab
<Steven_Shiau> got it. appreciate that
<Steven_Shiau> so in the future, upstart will still respect the /etc/inittab ?
<Keybuk> for edgy it will, yes
<Keybuk> edgy+1 will not respect runlevels as much
<Steven_Shiau> ic. tkx
<Steven_Shiau> another question, how can I see more messages when my edgy box reboot or boots ?
<Keybuk> take "quiet" off the kernel command line
<Steven_Shiau> yes, I already did that.
<Steven_Shiau> and no usplash at all
<Steven_Shiau> but it seems that the messages are still less than before
<Keybuk> you may need some updates due today
<Steven_Shiau> for upstart 0.2.7-2 ?
<Keybuk> upstart, lsb-base and sysvinit will all need updating
<Steven_Shiau> got it.
<Steven_Shiau> my last question
<Keybuk> shoot
<Steven_Shiau> I need to run a script (/etc/rc2.d/S99firstboot) when edgy boots so that people can enter some number to choose some config, etc. It works in dapper. However, now with edgy alpha3, I can not do it.
<Steven_Shiau> since all the service just run, and won't wait for me to enter
<Steven_Shiau> Is that possible to do that ?
<Keybuk> yes
<Keybuk> exec </dev/console >/dev/console 2>&1  at the top of the script
<Steven_Shiau> in my S99firstboot ?
<Keybuk> yes
<Steven_Shiau> great!
<Steven_Shiau> That finishes all my questions. Appreciate that.
<Keybuk> alternately write the firstboot as an upstart job (/etc/event.d/firstboot) run when the rc script finishes (start on rc3/stop) and on the console (console output)
<Steven_Shiau> excellent!
<Steven_Shiau> that's the benefit of upstart!
<Keybuk> well, at the moment we're just using it to replace sysvinit and not do anything extra
<Keybuk> to prove the daemon works
<Steven_Shiau> But it will be better in the future
<Steven_Shiau> definitely
<Seveas> Keybuk, there was an impromptu lightning talk session here at EuroOscon - I pimped upstart, hope you don't mind 
<Seveas> people were impressed by it
<Keybuk> has anyone had much experience with gtk-doc-tools, linuxdoc-tools, or doxygen, etc.?
* LarstiQ has some experience with doxyge.
<Keybuk> how do you find it to use?
<LarstiQ> rather ok, though more burdensome than epydoc with docstrings.
<Keybuk> epydoc is a python thing?
<LarstiQ> yes.
<mbiebl> Keybuk: Since you use binary:Version now in debian/control, you should add a versioned build-dep on dpkg-dev (>= 1.13.19)
<_ion> doxygen is quite nice.
<Keybuk> mbiebl: could you file a bug for me?
<mbiebl> Will do
<Keybuk> on the ubuntu source, obviously
<mbiebl> sure ;-)
<mbiebl> #61693
<Keybuk> thanks
<Keybuk> hope to start moving towards 0.5 this weekend
<_ion> Cool.
<mbiebl> What features are planned for 0.5?
<Keybuk> https://wiki.ubuntu.com/UpstartDesignChanges
<_ion> (topic)
<mbiebl> We should probably put out some more sophisticated examples then.
<mbiebl> So that people get a feeling how to write upstart jobs.
<Keybuk> how do you mean?
<Keybuk> once 0.5 is out?
<mbiebl> Yes, explaining, which features/keywords already work e.g.
<Keybuk> yes, I agree
<wasabi__> The hardest part of those changes I think will be faking a call stack
<wasabi__> for event blocking
<Keybuk> event blocking?
<wasabi__> Well, if an event can fail, then it must return a failure status.
<wasabi__> And to do that, it must document which jobs were effected by it
<wasabi__> And those jobs themselves can emit events that invoke other jobs.
<wasabi__> Meaning they themselves wait for the results of those events;.
<Keybuk> that's the question, do we want to wait for resulting events, or just jobs?
<wasabi__> Well, before the results of an event can be known, all the jobs must complete.
<Keybuk> define "complete"
<wasabi__> transition to the stage that the emitted event caused them to set as a goal
<wasabi__> or fail.
<Keybuk> right, so that doesn't require event chaining
<Keybuk> e.g. if that job emits an event, then that's not part of the goal or "complete"-ness
<wasabi__> If I emit do-some-stuff, whcih causes a job to move from stop to start, do-some-stuff's result cannot be known until that job has finished entered started.
<wasabi__> During which, it might have issued it's own events, which it itself is waiting on.
<Keybuk> yes, that's true
<wasabi__> So, it's a pretend call stack, managed with a main loop.
<Keybuk> except you don't actually need the call stack
<wasabi__> Yeah. Never said you did. It just behaves as one.
<wasabi__> Which is interesting from an academic POV. :0
<Keybuk> the job is waiting on an event inside a process
<wasabi__> Well, for instance, if a job transitions from STOPPED to STARTING, upstart itself emits job-name starting
<wasabi__> The results of which could fail.
<wasabi__> And should prevent the job from continuing.
<Keybuk> should it, why?
<Keybuk> I don't think it should
<wasabi__> Really?
<wasabi__> Because being able to write a new job that effects the startup process of another job, is interesting.
<Keybuk> yes, but it's possible by just adding "stop on event-failed job-started job-name" :)
<wasabi__> Lets you modify the first job without changing its file, resulting in easier management (upgrades to the job's package don't need to deal with changes to the job file)
<wasabi__> Hmm.
<pepsiman> wasabi__: the word is "affects"
<wasabi__> Heh.
<wasabi__> I'd prefer to make it as unneccassary as possible for an admin who desires to attach conditionals to a job installed by a package, to edit that jobs file himself. Not required, but it seems a worthy goal.
<wasabi__> Easies package upgrades.
<Keybuk> but then you have strange problems
<wasabi__> Well, upstart has or will have an api like thus:
<Keybuk> where the author of some job never expects anything to handle its events
<Keybuk> and something does
<wasabi__> evt = event_new("job-starting", job.name); wait for evt to exit
<wasabi__> Well. That's true.
<wasabi__> I suspect though the interference on the original job would be small, since you'd only be able to attach to built in events.
<wasabi__> And those would only be able to return success/fail, to abort or continue.  Nothing that can modify the original job's state in any breaking way.
<Keybuk> I just don't think that a job should be affected by other jobs unless it wants to be
<Keybuk> the worst example I can think of is mount-filesystem ;)
<wasabi__> Heh.
<Keybuk> you'd end up failing the entire system if a singel job that reacted to that event failed :p
<wasabi__> Oooh.
<wasabi__> Good point.
<Keybuk> anyway, gonna go to sleep :)  been up for 30H or so
<Keybuk> nite
<wasabi__> wow nite
<johnnybuoy> hello!
<johnnybuoy> can I get help for upstart in edgy here?
<LarstiQ> what help would that be?
<johnnybuoy> can I get ttys working, or is this a known bug?
<LarstiQ> it sounds familiar, let me see if I can find anything
<johnnybuoy> /etc/default/console-properties is set properly, i think
<LarstiQ> johnnybuoy: my ttys seem to be working fine in edgy fwiw, and I don't see anything relevant in my backlog
<johnnybuoy> hmmm
<johnnybuoy> many ppl in ubuntu+1 have this prob.
<LarstiQ> johnnybuoy: you have  startup-tasks and system-services installed?
<johnnybuoy> LarstiQ, and no messages when booting without usplash
<johnnybuoy> hmm
<johnnybuoy> nope.
<johnnybuoy> is it not a dep?
<LarstiQ> johnnybuoy: I think the messages would be  upstart-logd\
<LarstiQ> johnnybuoy: a Recommends
<LarstiQ> johnnybuoy: could you try that and report if it works?
<johnnybuoy> LarstiQ, upstart-logd is installed
<johnnybuoy> LarstiQ, ok
<johnnybuoy> what if my pc doesn't boot?
<johnnybuoy> hmm?
<LarstiQ> I doubt that will happen
<johnnybuoy> I have those packages
<johnnybuoy> both
<johnnybuoy> all three ;)
<LarstiQ> I'm out of ideas then
<johnnybuoy> hmm
<johnnybuoy> :(
<johnnybuoy> it's scary, cause what if X fails me?
<johnnybuoy> i don't even know how to control upstart :(
<johnnybuoy> does it have anything to do with
<johnnybuoy> /etc/event.d/tty* files?
<LarstiQ> you could install sysvinit for the time being, if that makes you feel safer
<johnnybuoy> cat /var/log/messages |grep tty gives me only one tty...
<johnnybuoy> ttyS1
<johnnybuoy> what is LSR safety check?
<LarstiQ> johnnybuoy: see /var/log/boot
<LarstiQ> johnnybuoy: what I've personally also done is remove quiet and splash from the kernel arguments
<johnnybuoy> LarstiQ, I tried that, but now splash works fine, do you think that splash is responsible for me not having ttys?
<LarstiQ> johnnybuoy: it does do nasty things with your console, yes
<johnnybuoy> hmm
<johnnybuoy> ok
<johnnybuoy> I'll try with splash disabled
<johnnybuoy> brb
<johnnybuoy> hmm :)
<johnnybuoy> usplash *does* do strange things with the console :(
<mjg59> What sort of strange things, and what kernel arguments are you using?
<johnnybuoy> vga=791 splash = silent and quiet are the relevant kernel arguments, I guess
<mjg59> Lose vga=
<johnnybuoy> really?
<mjg59> Yes
<johnnybuoy> ok, brb :)
<johnnybuoy> whoyesss!!!
<johnnybuoy> thanks! removing vga=* kernel param I get usplash and tty...
<johnnybuoy> :)
* johnnybuoy very happy
<johnnybuoy> THX
<dippie> hello
-ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
!christel:*! Hi all, we just had a minor connectivity issue with one of our servers. Affected users: ~3000. All should be back to normal. Have a great day!
!alindeman:*! Hi all!  You may notice some bots around the net attempting to exploit a bug in some routers (whereby they crash on a malformed DCC SEND string).  We're doing our best to mitigate the visibility of these bots, but if you're still being affected (i.e., disconnected) by them, please consider upgrading your router firmware ( http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1068 ) and/or connecting to freenode on a non-IRC port, such as 8001.  Thanks!  I
#upstart 2006-09-22
!alindeman:*! And, as always, if you have further questions, please feel free to message an on-duty staff member ( /stats p )
<maro_> evening :)
<Steven_Shiau> is there anyone know how to move the login prompt after /etc/rc2.d/S99xxx service ? Since when I removed "quiet" and "splash" in grub kernel parameters, the output of those services of runlevel 2 is in a mess.
<Steven_Shiau> or is that possible to move the output of runlevel 2 services to console 2 or other consoles ?
<Steven_Shiau> forgot to say, I am using upstart 0.2.7-1
<Steven_Shiau> in Ubuntu Edgy alpha3 with updated packages
<Steven_Shiau> oh, upstart 0.2.7-3 is released, I upgraded that, and now it's better
<Steven_Shiau> The output of services in runlevel 2 now looks better
<johnnybuoy> hmm
<johnnybuoy> there is a problem in edgy mdadm-raid script...
<johnnybuoy> anyone know about upstart scripts?
!alindeman:*! Regional server split; we're looking into it
-ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
<sciboy> Hello fellas.
-ChanServ(ChanServ@services.)- [#ubuntu-server]  Ubuntu Server Discussions (development and support)
-ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
<maro_> would it be possible to make a job for running update-pciids daily when the network is up?
<Md> maro_: do you instert new PCI cards in your system every day?
<Md> s/instert/insert/
<maro_> that was just an example
<Md> yes, you can
<maro_> it could be abstracted into "is it possible to do an action on a event if a condition is true"
<maro_> and a sample event.d file would trigger a huge "thank you!"
<maro_> or even better, a directory with sample event.d entries (other than the rc compat things) :)
<_ion> upstart doesn't implement cron/at functionality yet.
<maro_> ah, I'll wait for the spiffy features then - thanks :)
<_ion> Keybuk said he's hoping to start developing the 0.5 branch this weekend IIRC. I'm not sure whether the cron/at functionality is going to be in 0.5, though.
<_ion> I hope so. :-)
<maro_> cool - me too :)
<_ion> Perhaps i can even contribute some code, if my health allows.
<maro_> you're sick? :(
<_ion> Well, i've been unable to work for almost two years. Very rarely i have enough energy to be able to concentrate enough to create a small, simple patch for some project.
<maro_> :/
<Keybuk> _ion: my vague thoughts are that 0.5 would be a "roughly feature complete" version
<Keybuk> it may be a long cycle, as it's what we'd ship in edgy+1 eventually
<Keybuk> and would be what I'd expect other distros to think about shipping
<LarstiQ> sounds about perfect to hack up one weekend ;)
<_ion> keybuk: Sounds good.
<wasabi> Keybuk: We were talking yesterday about the event failure status chaining. I do think that the event's "exit" status shouldn't be known until the event, and all jobs that follow, directly or indirectly, is known... but that status doesnt' reflect on whether the system has "failed" to startup.
<wasabi> Whether "startup" fails or not has no bearing on what services were started as a result of triggering it.
<wasabi> They're still started.
<Keybuk> wasabi: I'm not sure I follow what you mean
<wasabi> Well, we were considering the idea of being able to wait for an event to be "done.
<wasabi> So, something like initctl trigger foo && echo done
<wasabi> can work.
<wasabi> So it doesn't just finish immediatly.
<wasabi> Also, to get the return fail/success of an event, delivered back over the control socket.
<wasabi> ie you create an event, the socket tells you the id, then later tells you the success/fail of the id.
<Keybuk> right
<wasabi> Can an event really be considered completely handled if there are still processes running because of it?
<Keybuk> it's an interesting question
<Keybuk> depends on whether the process is a service or a task, I guess?
<Keybuk> the ultimate goal of a service is just to be started
<wasabi> Consider job2 with "start on job1 starting". When job1 moves to starting, upstart itself issues that event. Causing job1 to start.
<Keybuk> but the ultimate goal of a task is to be started AND get back to stopped again
<wasabi> Err, job2 to start.
<wasabi> job2 may be something like a custom script an admni wanted to run BEFORE a given service starts.
<wasabi> I think in most cases you would desire job2 to complete before job1 proceeds.
<Keybuk> I disagree
<Keybuk> the admin should modify job1, no?
<Keybuk> they're adding a new pre-requisite to it?
<wasabi> Well, you might say that, but I see that it's a bit non ideal because it makes any upgrade to job1's job file require human interaction.
<wasabi> That's not a big deal though.
<wasabi> What if the "admin" is another package that desires to start before one?
<wasabi> The other package can't modify job1's script in it's post-inst,t hat'd be messy.
<Keybuk> if you can come up with a use case for that ... ?
<wasabi> Impossible to revert, would screw up upgrades of job1.
<wasabi> Yeah thinking. ;)
<wasabi> I have a few ideas, but I can think of them being started in other ways. I'm just not sure which is better. Take xsp... the Mono web server.
<wasabi> It's basically a stand alone daemon, which receives requests that originate thorugh apache.
<_ion> Actually not being able to do a three-way merge is package manager's fault.
<wasabi> Also, I guess tomcat is the same here.
<_ion> Re: human interaction during upgrades.
<wasabi> Those are services which ideally should be started BEFORE apache.
<wasabi> But they are installed sepereatly, and apache doesnt' depend on them.
<wasabi> In the normal case.
<Keybuk> the problem is coming up with a model that isn't insane ;)
<wasabi> If you install tomcat, you would desire, only if it's installed, for it to start before apache.
<wasabi> Otherwise apache has no relation to it.
<wasabi> So, you don't want the install for tomcat to have to modify apache's job file.
<wasabi> For the previous reasons. =)
<_ion> I think Gentoo has something like "after foo" and "before bar"
<wasabi> Yeah. I think we have that too in our "job-starting apache"
<Keybuk> after has been proposed
<Keybuk> we could have "before" as well
<wasabi> event.d/tomcat :   "start on job-starting apache"
<wasabi> Is that not before?
<Keybuk> no, because that doesn't cause apache to wait
<wasabi> Yeah, and that's the question. Should it.
<_ion> And it shouldn't IMO.
<wasabi> Why?
<Keybuk> well, for a start you have to define what you're waiting for
<_ion> Everything that causes apache to wait should be defined in the apache file IMO.
<Keybuk> when do you release apache?
<Keybuk> when you spawned the tomcat process (too early!)
<_ion> Otherwise it's just confusing.
<wasabi> No, this still works.
<wasabi> Okay, you know how initctl will work?
<wasabi> Event gets issued, all the jobs that upstart is going to change goals on are found, only when they have all successfully reached that goal, is the event considered finished.
<Keybuk> I don't know how that will work yet
<wasabi> Or, successfully failed, anyways.
<Keybuk> because the goal is a wishy-washy bit <g>
<wasabi> Well, they will be turned "unidle" by the event.
<wasabi> At somepoint they'll be idle again.
<Keybuk> unidle?
<wasabi> No goal.
<wasabi> Goal.
<Keybuk> there's always a goal
<wasabi> How so?
<Keybuk> the goal is always either stop or start, no?
<wasabi> If a service is started, and nothing has told it to stop, hasn't it reached it's goal?
<_ion> Its goal is still "start".
<wasabi> Hmm.
<wasabi> Okay. I see what you mean then.
<wasabi> The goal is start, but it's "done".
<Keybuk> and when tomcat reaches started, it's not yet ready for apache to start
<wasabi> There's an indicator for "done" someplace, so it doesn't get touched on the mainloop, surely.
<wasabi> Keybuk: Yeah, it is.
<Keybuk> no it's not
<Keybuk> tomcat isn't listening yet
<wasabi> Keybuk: Since we moved post-start into starting. ;)
<Keybuk> we did ?!
<_ion> :-D
* Keybuk must keep up
* wasabi checks wiki
<wasabi> I did in my head anyways.
<Keybuk> post-start being before started seems ... odd :p
<wasabi> Well, maybe the script names are unappropiate.
<wasabi> post-exec
<wasabi> pre-exec
<wasabi> "started"
<wasabi> man the wiki is always so slow
<wasabi> Yeah.
<wasabi> I made those changes ages ago. Thought you read em.
<wasabi> Putting the post-start, whatever we call it, script in starting, makes the most sense.
<_ion> Agreed.
<wasabi> Then "started" gets properlly emitted when it's really done.
<Keybuk> I get vaguely dyslexic with long prose paragraphs; which is why I turn things into bullet points when I think I understand them
<wasabi> Yeah.
<wasabi> I was braindumping.
<Keybuk> I probably missed the change :p
<wasabi> I don't want to shove that change on you, btw. But think about it. :)
<wasabi> Anyways, so, initctl trigger foo, causes all the jobs to be enumerated, they all go into some sort of "work" state, as they attempt to move to whatever they should. Some of them get there and then immediatly go back to stopped again, eventually they all go idle.
<_ion> Having "pre-start, exec and post-start" in "starting" and "sted" after running those successfully is intuitive IMO.
<_ion> s/sted/started/
<wasabi> At the point they're idle, the result code is returned to the issuer of the starting event.
<Keybuk> right
<Keybuk> here's a question then
<wasabi> But that can be recursive. A job may itself run initctl trigger.
<Keybuk> a service's goal is to reach the start state
<wasabi> In which case that job's PID is blocking on initctl, and the issuer of the original event is blocking on that job.
<Keybuk> but a task's goal is to reach the start state and then get back to the stop state
<wasabi> Eventually that unwinds.
<wasabi> I'd say there's not much difference between a service and a task.
<wasabi> Programatically.
<wasabi> One just doesn't have anything to run long term.
<Keybuk> there's no programatically
<Keybuk> +ne
<Keybuk> but there might be a desire to distinguish their behaviour for jobs
<Keybuk> e.g. if I have a short task (like, say, check the root filesystem)
<Keybuk> and I trigger that event with initctl
<Keybuk> should it wait for the root filesystem to be checked
<Keybuk> or for the check to begin?
<wasabi> I think it should have the potential to wait.
<_ion> The first impression is that it should wait for fsck's completion.
<wasabi> I think not waiting is an acceptable option for initctl though
<wasabi> initctl -n trigger whatever
<wasabi> Whether that's default one way or another is totally open.
<_ion> Or perhaps alternatively something like this: "start footask" waits for its completion, "initctl trigger footask" doesn't.
<wasabi> initctl can put the event on the socket, and then just close it and exit, without waiting for upstart to return the result.
<Keybuk> I was thinking about the failed example
<Keybuk> on job-failed check-root
<Keybuk> should that be issued if check-root fails to finish, or just when it fails to start?
<_ion> Both.
<wasabi> What's the diff?
<Keybuk> when do you decide a job has failed?
<wasabi> When it has been determined it is unable to reach it's goal.
<Keybuk> but what's it's goal?
<Keybuk> is the goal to begin checking the root filesystem, or to have completed the check?
<wasabi> Good interesting question.
<wasabi> I can't see much of a use for the goal being to begin it.
<_ion> How about this? A task has failed if anything (pre-start, exec, post-start, pre-stop, post-stop) returns a non-zero value. A service has failed if pre-start, exec or post-start returns a non-zero value.
<wasabi> _ion: That's why I talk about "idle". A task is only "idle" after it's back at stopped.
<wasabi> A service goes idle at "started".
<wasabi> Basically, an iteration of the mainloop has determined that there's nothing being waited on, and it's at the current goal.
<wasabi> For a task, when it reaches "started", the iteration realizes there's nothing that's running, and sets the goal back to stopped, and keeps going.
<wasabi> But it's not idle.
<wasabi> for a serivice, the iteration realies that it's waiting on a running process.
<wasabi> i'm totaly late for work now.
<wasabi> I gotta jet. Bbl.
<Keybuk> have fun
#upstart 2006-09-23
<lupine_85> hello people :)
!christel:*! Morning all. The Ubuntu Marketing Team are conducting a survey at the moment and have kindly asked if we could encourage users to participate, although the survey is Ubuntu-centric they intend to release the report under creative commons and hope that it will be useful for the FOSS community as a whole. For those wishing to participate, head over to http://surveys.geekosophical.net/ and have a good day!
<Ingmar^> on edgy, using upstart, the modules for cpu frequency scaling don't get loaded correctly, i'm on an intel pentium M 1.6 gHz, I can load them manually, but i'd like to have that done on boot, how do i do that ?
<Ingmar^> highlight me of someone feels like helping, and thanks :-)
<cortana> does it get loaded with sysvinit?
<_ion> That isn't really related to upstart.
<johnnybuoy> why don't you guys team up with einit? it look as though your goals are somewhat common.
* ..[topic/#upstart:Md] : einit
<Md> oops
* ..[topic/#upstart:Md] : Upstart 0.2.7 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/doc/getting-started.html | https://wiki.ubuntu.com/UpstartDesignChanges | irc logs: http://people.ubuntu.com/~fabbione/irclogs
<johnnybuoy> LOL
<johnnybuoy> not bad, ehh
<johnnybuoy> what is uptart different in than einit? why is it better?
<LarstiQ> johnnybuoy: the original announcement I saw had a load of comparisons
<LarstiQ> not sure if einit was in there
<_ion> From the einit feature list:
<_ion> - Configuration file in XML
<_ion> ARGH
<_ion> http://einit.sourceforge.net/documentation/users/x203.html
<_ion> I already hate it. :-)
<asdx> is upstart distro specific or will be able to run in other distros too?
<_ion> It's not distro-specific.
<asdx> nice
<johnnybuoy> so no need to configure through xml, that's minr
<johnnybuoy> but why make 5 replacements to init
<johnnybuoy> it's such a waste
<LarstiQ> right, everyone flock to upstart! :)
<_ion> Right. :-)
<johnnybuoy> :D
<LarstiQ> johnnybuoy: fwiw, the model was different enough to other solutions to warrant a new project
<LarstiQ> but that should all be explained in the docs
<_ion> Actually there are lot more than 5 replacement for init. Keybuk inspected many of them before concluding that none of them are adequate.
<johnnybuoy> will it do parallel starting? modes?
<johnnybuoy> LOL
<_ion> His discoveries are documented. Perhaps i'll dig up the URL if nobody else does. :-)
<johnnybuoy> thx :)
* LarstiQ was waiting for johnnybuoy to do that ;P
<johnnybuoy> you maybe even put it in the topic to not get annoying questions like these ;)
<johnnybuoy> right, LarstiQ , right
<LarstiQ> a guy can hope :)
<johnnybuoy> wll, i can try,but...
<asdx> what features for example upstart has that initng/einit lacks?
<LarstiQ> johnnybuoy: http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe
<_ion> "Existing implementations" in http://people.ubuntu.com/~scott/upstart/spec.txt and in https://wiki.ubuntu.com/ReplacementInitDiscussion
<LarstiQ>  /win 53
* LarstiQ growls
<_ion> initng is covered in them.
<johnnybuoy> thx!
<_ion> At least the latter is linked from upstart.ubuntu.com, which is in the topic.
<LarstiQ> my paste is as well
<_ion> Chronologically the text file is the oldest, and the blog entry is the newest.
<asdx> johnnybuoy: are you running upstart?
<johnnybuoy> yep
<johnnybuoy> on ubuntu edgy
<johnnybuoy> quite stable right now...
<asdx> cool
<johnnybuoy> asdx, are you using einit?
<asdx> no
<asdx> normal sysvinit
<asdx> i don't know which to choose yet ;P
<asdx> but i will try them all :P
<asdx> upstart doesn't need /etc/fstab?
<_ion> What does an init daemon have to do with fstab?
<asdx> http://people.ubuntu.com/~scott/upstart/spec.txt
<asdx> there says something about fstab
<_ion> Upstart _jobs_ handle mounting filesystems, upstart itself doesn't. Just like scripts started by sysvinit handle mounting, not sysvinit itself.
<johnnybuoy> cio all!
<johnnybuoy> ciao all!
<asdx> i see
<asdx> _ion: so if the kernel detects file systems upstart jobs mounts them?
<_ion> With upstart, it's going to be something like this: HAL finds a hard disk and triggers an upstart event for each partition. An upstart job responsible for mounting starts on such event and, if the partition is listed with 'auto' in fstab, it mounts it. As soon as each 'auto' partition in fstab is mounted, the job triggers a 'writable-filesystem' event. Other jobs may start on that event.
<_ion> Actually, for the 'writable-filesystem' event to be triggered, most likely only FHS mountpoints are going to be considered.
<asdx> i see
<asdx> thanks for explain
<Ingmar^> on edgy, using upstart, the modules for cpu frequency scaling don't get loaded correctly, i'm on an intel pentium M 1.6 gHz, I can load them manually, but i'd like to have that done on boot, how do i do that ?
<theCore> Ingmar^, I don't it's related to upstart
<theCore> check https://launchpad.net/bugs/36014
<Ingmar^> theCore: don't think it's related to upstart ?
<theCore> Ingmar^, upstart just launch programs
<Ingmar^> in the bug the modules are loaded, but mine aren't, on boot
<Ingmar^> and if i load them, it just works
<Ingmar^> right, that's true
<Ingmar^> thanks for the reply btw
<theCore> Ingmar^, np
#upstart 2006-09-24
<_ion> keybuk: An idea: an optional, purely informative "triggers" stanza that lists the events the job (either script or the daemon) may trigger, e.g. a hald job might contain "triggers block-device-added" and a mount job might contain "triggers path-mounted fhs-filesystem". That would make it easy to 1) grep event.d/* for "starts on jobname" and 2) visualize the relations between jobs programmatically.
<Keybuk> could be just a normative comment?
<_ion> Yes.
<_ion> Just like "author" and "description". :-)
<Keybuk> true, true
<Keybuk> description is actually useful, as you have to describe the job in listings
<_ion> For example, a GUI for managing jobs might display a list of jobs that act on events the currently selected job may trigger.
<_ion> When you click "hal", it lists "check-filesystem" and when you click it, it lists "mount".
<_ion> Also cool graphviz graphs would be possible. ;-)
<Keybuk> true
<Keybuk> a bit like Java's "throws" ?
<Keybuk> :p
<ajgenius> hmm ok. question the first. From todo - "Per-user services" "for "root-user services" but not for jobs/tasks", I am trying to figure out what that means, and what the intent is for User level services down the road
<_ion> keybuk: Well, a bit like it. :-)
<Keybuk> well, the obvious thing is for users to be able to register services to be run on their behalf
<Keybuk> so I can have an hourly script run
<Keybuk> or even daemons run for me
<Keybuk> PAM needs to be used to set up the session properly
<Keybuk> the root bit is that the root _user_ should be able to register services/tasks
<Keybuk> and thus be run with PAM to set up the session
<Keybuk> which is different from those in /etc/event.d which should not be run in a PAM session, maybe
<_ion> I'd assume the root user's jobs to be different from the /etc/event.d jobs similarly as the root user's crontab is different from the system crontab.
<_ion> I mean the semantical difference, not the technical difference.
<Keybuk> indeed
<Keybuk> the technical difference is the same, actually
<ajgenius> ok. hm.
<ajgenius> the thing I am trying to understand is the long term goal for user level integration, in regards to allowing users to have purely user session jobs and scripts.
<ajgenius> and I am not finding any real information on goals regarding that in the docs or todo's :)
<Keybuk> well, it depends what you mean by "user session" at this point?
<ajgenius> I mean.. desktop situation. the user wants to register a task to do some operation on their files, by them, (they wouldn't think of it in the terms of sessions), on given events
<Keybuk> the lack of information doesn't mean anything other than I haven't written it down in stone yet, and am still thinking about it and taking suggesions
<Keybuk> right, but would these tasks need access to running X desktops?
<_ion> mkdir -p ~/.event.d; vim ~/.event.d/job ... :wq and it just works. :-)
<ajgenius> sometimes yes sometimes no. that would be a task level dependency
<Keybuk> there's several levels of thing:
<_ion> (As long as the bofh hasn't disabled it)
<Keybuk> - new system session (process group and session)
<Keybuk> - new user session
<Keybuk> - existing user's session
<Keybuk> the second is "switch to the user, create a new session, login that session, run the task"
<Keybuk> the third is run the task for a user that is logged in
<Keybuk> which is an interesting case all to itself
<Keybuk> but potentially conflicting with a desktop session manager
<ajgenius> right. I am interesting in both the latter cases
<ajgenius> mostly the last however
<Keybuk> it's definitely something that's worth serious thought
<ajgenius> one of the problems is for example - right now we have "hald" for gnome integration, which handles hardware events etc. thats nice and interesting, but it doesn't allow much real integration on a user level
<Keybuk> there's been some interesting discussion about that on the dbus mailing list last week
<ajgenius> I think most of that belongs in an upstart space.
<ajgenius> otherwise we have multiple event based systems for different kinds of things
<Keybuk> which part though?
<ajgenius> which part of what?
<Keybuk> <ajgenius> I think most of that belongs in an upstart space.
<Keybuk> you wouldn't have upstart monitoring battery levels, for example?
<ajgenius> yes. anything to do with handling events and starting jobs
<ajgenius> Keybuk: that wouldn't be IN upstart. but there is no reason not to have a way of registering new events of that nature into upstart space
<ajgenius> the event daemon is something which recieves events, and starts jobs. it doesn't generate the events. something else does
<Keybuk> +----------------------+
<Keybuk> |  gnome-power-manager |
<Keybuk> +-------+--------------+
<Keybuk> |  HAL  |              |
<Keybuk> +-------+              +-----------------+
<Keybuk> |           D-Bus      | Suspend Scripts |
<Keybuk> +----------------------+-----------------+
<Keybuk> |                   Upstart              |
<Keybuk> +----------------------------------------+
<Keybuk> that kind of thing?
<_ion>    
<ajgenius> ehm
<Keybuk> _ion: ?
<_ion> Just some line drawing characters for cooler boxes. ;-)
<Keybuk> _ion: harder to type than just '-' :p
<_ion> Hehe.
<Keybuk> gnome-power-manager receives information from HAL that indicates the battery is critical
<Keybuk> so it issues a battery critical event
<ajgenius> Keybuk: yes and no. gnome-power-manager is on top of HAL, but what should trigger it to start in the first place?
<Keybuk> which upstart receives and runs the suspend scripts for
<Keybuk> that's another point
<Keybuk> we know that HAL and the D-Bus system daemon are run by upstart
<Keybuk> but what runs the D-Bus session daemon, and gnome-power-manager?
<_ion> It would be quite cool if upstart were abstracted as much to allow _it_ to be the desktop session manager.
<ajgenius> thats the point I care about - there are a lot of really cool things that can be done from a user POV. but forcing multiple levels of start abstraction actually detracts what can be done. if they can all be started by the same thing - now in this case I think that perhaps an upstart user level daemon.
<ajgenius> each user starts its own instance of a user only upstart - which gets events from the main system, but can only start them in that users context
<ajgenius> that allows a single point of origin for anything in that users space
<ajgenius> _ion: yeah exactly. thats a large part of it
<Keybuk> kinda, you end up with two ... started by the X session manager or started by upstart
<ajgenius> but it wouldn't JUST be a "desktop" dession manager it would be a user space manager. desktop
<ajgenius> is really seperate at that point.
<ajgenius> Keybuk: why would the X session manager have anything to do with it :)
<ajgenius> it just starts a user session. why not make what it starts, a user level upstart.
<theCore> why would you want upstart as your desktop-manager?
<Keybuk> ajgenius: it doesn't just do that though
<Keybuk> an X session manager actually does a whole bunch of stuff
<Keybuk> http://live.gnome.org/SessionManagement
<Keybuk> also there's
<Keybuk> http://freedesktop.org/wiki/Standards_2fautostart_2dspec
<ajgenius> yes I know about them
<maro_> why not just hook users up to the system upstart? (as it looks to be the current plan)
<Keybuk> would upstart need to implement those?
<ajgenius> Keybuk: no
<ajgenius> well and yes ;)
<Keybuk> maro: there isn't any current plan in this regard
<ajgenius> hmm
<Keybuk> ajgenius: see, this is where the lines to me get fuzzy
<ajgenius> Autostart Specificatio
<maro_> Keybuk: I was thinking of the "on ~scott/..." examples I found somewhere
<ajgenius> Keybuk: its clear to me. upstart doesn't DO any of those things. it just recieves events, and starts jobs
<Keybuk> maro_: those are just for "new temporary session" jobs (e.g. cron/atd)
<ajgenius> thats it. in the rough ;)
<Keybuk> X sessions are odd anyway
<Keybuk> as they're not true sessions, they're just a bunch of background processes without controlling terminal that happen to share some environment variables
<ajgenius> personally I see no REASON to have the autostart specification persay. in the sense that, in terms of events, everything in a desktop environment depends on core parts of the desktop to start first, its desktop dependent. aka jobs
<ajgenius> and events
<Keybuk> it certainly makes an amount of elegant sense to have upstart start things like the panel
<ajgenius> thats kind of it. you might have a "session management" daemon that upstart begins first
<Keybuk> but then you wonder whether upstart should receive a "user clicked a launcher" event, which causes upstart to start openoffice
<ajgenius> to handle autosave stuff
<Keybuk> and I'm not sure at which point the line between genius and insanity gets crossed yet
<ajgenius> Keybuk: no
<ajgenius> hum. if someone chooses to use it in that fashion. that is up to them. but it has nothing to do with upstart itself
<Keybuk> openoffice ends up being a child of upstart :)
<ajgenius> thats not a problem to me
<ajgenius> I see no reason it shouldn't be
<Keybuk> it is by default
<Keybuk> parent process is #1 for most X apps
<ajgenius> right
<ajgenius> the idea is in effect to make the user space all started as a child of a single point of origin, a user space upstart. thats it
<ajgenius> it doesn't have anything to do with the actual processes or gui or whatnot
<ajgenius> people could make jobs
<ajgenius> that do those sorts of things.
<ajgenius> but thats not upstarts concern
<ajgenius> so you still will probably need a "session manager", but for example - it handles the other aspects, like close/shutdown things.
<ajgenius> but it doesn't need to start them
<Keybuk> it doesn't seem unreasonable
<ajgenius> that allows everything upstart can do for a system. to be done for just a user. in that users scope. and does it in a GUI and Desktop agnostic fashion
<ajgenius> and it would just have system events forwarded to it from the system instance.
<Keybuk> I was just thinking about how that would work
<Keybuk> sounds a bit dbus-like to me
<ajgenius> you could do it on dbus at that level, because the system upstart would already be started. but I don't know if it needs to be
<_ion> A user session upstart daemon would give a lot of flexibility for things, e.g. it would be possible to set niceness and environment variables for specific user session jobs.
<Keybuk> I'm not immediately sure you need a user session daemon at all
<Keybuk> due to the way X has historically worked, all you need is something to register a session with the master daemon
<Keybuk> give the DISPLAY, DBUS_*, etc. environment variables
<Keybuk> so then init can just include those in anything marked for that "session"
<ajgenius> but thats based on X
<Keybuk> they don't need to be children of any particular process
<ajgenius> hm
<theCore> that is what I'm thinking, an user upstart could be just a small program that would send message to upstart
<Keybuk> then you would add a new first-class object to upstart ... "session"
<Keybuk> jobs might exist in a session or not
<ajgenius> but what about starting jobs in user space? who would be the root level? upstart
<Keybuk> yes
<Keybuk> that's easy
<Keybuk> fork ()
<Keybuk> setsid ()
<Keybuk> setuid ()
<Keybuk> exec ()
<Keybuk> :p
<ajgenius> hm. maybe
<Keybuk> nothing X related has a controlling terminal
<Keybuk> only the X server itself
<ajgenius> but if nothing else it would make the process tree horrible to make sense of in a multiuser environment ;)
<Keybuk> so there's no UNIXish signal interaction to worry about here
<Keybuk> ps fjax
<Keybuk> this is what the process tree looks like *today*
<ajgenius> not on my system ;)
<Keybuk> note that everything in your X "session" has PID=1
<Keybuk> why not on your system?
<Keybuk> show me
<ajgenius> I can't at the moment because I am booted up under a normal system
* Keybuk doesn't follow
<ajgenius> but under my normal environment I use a hacked system like what I am talking about
<Keybuk> any particular reason?
<ajgenius> proof of concept. I started something like upstart about 2 years ago but nobody cared ;)
<Keybuk> ahh
<Keybuk> so you'd see something like
<Keybuk> init
<Keybuk> `- X
<Keybuk>    `- x-session-manager
<Keybuk>       `- user-init
<Keybuk>          `- gnome-panel
<Keybuk> ?
<ajgenius> yes
<Keybuk> probably with a "`- gdm" in the middle there somewhere
<ajgenius> I called it ProcessManager
<ajgenius> but yeah
<ajgenius> amazing how what two years ago was a stupid idea is todays big new thing ;)
<Keybuk> heh
<Keybuk> I've not yet managed to convince anyone inside the Boston Conspiracy that this is a good thing yet
<ajgenius> hehe
<Keybuk> Havoc does seem interested though
<ajgenius> I never managed to get as big a following as you though(or any at all), so thats something. at least you have momentum to make this idea actually work :)
<Keybuk> don't suppose, btw, you could write a summary mail about the above and post it to the mailing list?
<Keybuk> well, we have a distro ;)  that's a big help
<ajgenius> hm
<Keybuk> if it works, Ubuntu will rock because of it, and everyone else will adopt it
<Keybuk> if it doesn't work, then it doesn't
<ajgenius> it will work :)
* johnnybuoy hopes too
<Keybuk> I just mean upstart in general
<ajgenius> the concept is sound, and as I say. I have been running on it for a long time now.
<ajgenius> Keybuk: sure it will
<ajgenius> :)
* johnnybuoy is running it, and is quite pleased!
<ajgenius> I mean. just conceptually it really makes integration into the new udev design system a lot easier
<Keybuk> yeah
<Keybuk> next is a matter of integrating it with dbus and HAL properly
<johnnybuoy> dbus??
<Keybuk> johnnybuoy: message passing bus
<johnnybuoy> doesn't that slow down the machine horribly.
<johnnybuoy> ??
<Keybuk> no?
<johnnybuoy> yes?
<ajgenius> why would it?
<Keybuk> it's just an IPC bus
<Keybuk> how one program tells another that something happened
<johnnybuoy> i mean the cpu has to put itself into adm. mode everytime a message comes or goes
<Keybuk> is logical for upstart to be able to start and stop things because of dbus broadcast messages
<Keybuk> err?
<johnnybuoy> hmm
<Keybuk> what's "adm. mode" ?
<LarstiQ> supervisor?
<johnnybuoy> i don't remember the word :(
<johnnybuoy> but the cpu has two modes?
<Keybuk> you're thinking of a Mach-like kernel aren't you?
<johnnybuoy> CONTEXT SWITCH i think
<johnnybuoy> right
<Keybuk> where the entire kernel is based on message-passing?
<Keybuk> dbus is just a user-space process for passing messages between user processes
<LarstiQ> L4 shows that can be quite fast.
<johnnybuoy> ahh, so no context switch
<Keybuk> it's how gnome power manager can tell the screensaver you're on battery, so don't waste power bouncing cows and just blank the screen
<johnnybuoy> yet l4 doesn't even have userlan tools to do proof-of-concept
<LarstiQ> proof-of-concept of what?
<johnnybuoy> that the linux drivers an 'really' be run in userland as servers
<johnnybuoy> s/an/can
<johnnybuoy> i tested it, it got me to a pretty screen that was mooving fast, bu no user interaction at all
<LarstiQ> L4 isn't really interested in that either.
<LarstiQ> Perhaps you are thinking of linux-on-l4?
<johnnybuoy> bu if dbus doesn't need those context switching..
<ajgenius> dbus isn't in kernel space. its in user space space. thats a whole different concept then a messaging bus in kernel
<_ion> ajgenius: Excuse my ignorance, but what is "the new udev design system"?
<Keybuk> kernel sends events when stuff changes
<_ion> Isn't that how udev has worked for a long time?
<_ion> I.e. listening to uevent?
<johnnybuoy> my ISP is ging me crap, sorry, but in the lat 5-10 minutes i wasn't here...didn't miss me ehh?;)
<ajgenius> _ion: uevents etc is new
<ajgenius> as in, for proper functionality it requires a 2.6.15(16?) kernel iirc
<ajgenius> it completely replaces hotplug now
<ajgenius> before it just integrated with it
<ajgenius> there is some documentation if you want to read up on the history and the recent changes :)
<ajgenius> its one of the important reasons for upstart NOW
<ajgenius> before it was just a good idea. now its almost necesary
#upstart 2007-09-18
* Starting logfile irclogs/upstart.log
<bbraun> Keybuk: any thoughts on upstart and network based events, like inetd?
<Keybuk> bbraun: hi
<bbraun> howdy
#upstart 2008-09-15
<rgl> hi
<rgl> is there a way to exec as a non-root user?
<thom> the cunningly titled 'user' variable :)
<thom> oops, sorry
<thom> utterly wrong channel
#upstart 2008-09-16
<ion_> http://heh.fi/tmp/idlemeter
<suihkulokki> if I have "start on started foobar", will it start only after the post-start stanza of foobar ?
<SEJeff> Can anyone help me make upstart restart a getty after logging out of a serial console?
<SEJeff> I login through the cyclades and it works. After logging out, getty stops
<SEJeff> And I've created /etc/event.d/serial to look just like: http://pastebin.com/d31e43fff
<suihkulokki> respawn?
<SEJeff> Is that what it is missing?
<SEJeff> Sorry there is no man page and I've been fighting with this
<suihkulokki> SEJeff: try adding a line "respawn" to the event.d file instead of the emit thing in your post-start script
<suihkulokki> err, post-stop
<SEJeff> Just comment the initctl line and put, "respawn"?
<Zeqadious> Maybe someone can give me some insight/ideas on what to check on next.  I am trying to implement the inital switchover to upstart event based init from my current BSD style init on my distro.  Just trying to get the initial sysinit script to run before moving on to the next script, however I get the following error while trying to debug this: "init: failed to spawn sysinit main process: unable to set oom adjustment: No such file or
<Zeqadious>  directory".  I don't know what file or directory its trying to access.  Any ideas before I dig into the mailing list archives?
<ion_> /proc/1/oom_adj probably. Do you have a recent enough version of Linux?
<ion_> Oh, wait. It probably doesnât have /proc yet at that point. Why the error about file or directory then... Iâm out of ideas.
<Zeqadious> :)
<Zeqadious> https://bugs.launchpad.net/upstart/+bug/259801/+viewstatus <-- looks like its a bug of some sort :(
<ion_> You could just comment out the OOM adjustment code as a temporary workaround.
<Zeqadious> Trying that now
<sadmac2> Keybuk: greetings
<Keybuk> hullo!
<Keybuk> Ah, Portland
<sadmac2> heh
<sadmac2> I head for the airport in 30 minutes
<sadmac2> be in at 9pm
<ion_> Hi Keybuk
<ion_> keybuk: http://gitweb.heh.fi/?p=ion/idlemeter.git;a=blob;f=README;hb=HEAD :-)
<sadmac2> Keybuk: that reminds me, we need to redo libnih :D
 * sadmac2 spent much of the week trying to hammer locking primitives into it to make a new version of that list iteration race go away
<Keybuk> yeah, libnih has some issues
<sadmac2> Bill must be running some kind of Murphy's Law CPU. He always finds these first
<Keybuk> I quite like the idea of moving to using ion_'s refcounting ideas in it too
<sadmac2> Keybuk: I've been reading some papers on region-based alloc. I'll have to point them out to you
<Keybuk> we could just write Upstart in Python ;)
<sadmac2> Keybuk: actually, I'll be bringing that up whenever we get to our little design session :)
<Keybuk> have you found anywhere to stay yet?
<sadmac2> Keybuk: nope
<sadmac2> bill's hotel room might have a bath tub though
<Keybuk> I forwarded your mail on to one of the organiser's, so hopefully that'll help
<sadmac2> why sleep anyway?
<ion_> http://heh.fi/tmp/idlemeter
<ion_> Also, âhow many hours did my visit to the city take?â  % ruby -I~/src/own/idlemeter/ruby -ridlemeter -e 'puts IdleMeter::Analyze.intervals.find_all {|i| i.mode == :idle and i.length >= 3600 }.last'
<ion_> idle   2008-09-16 13:19:02 +0300 â 2008-09-16 16:49:01 +0300 ( 3.5 hours)
#upstart 2008-09-18
<Keybuk> so I've met sadmac now :-)
<ion_> Cool
<Keybuk> he's kinda hawt ;)
<Keybuk> heh, that'll make him scared and wonder whether I'm joking or not when he reads his scrollback
 * Keybuk cackles evily
<ion_> Heh
<ion_> Iâm going to overengineer idlemeter to be able to sync the activity database with another computer by executing âssh box idlemeter --pipeâ (where âidlemeter --pipeâ connects to the local idlemeter over a UNIX socket and redirects std{in,out} to it) and talking to it. :-P Iâll have to get familiar with nih/io.[ch]
<Keybuk> heh
<Keybuk> good luck, that bit's quite crusty :p
<Keybuk> almost certainly still works though
<ion_> So, i tried frappÃ© after a greek person recommended it, and it was great. Iâll have to get some Kahlua and try it with frappÃ©, that must be awesomeÂ².
#upstart 2008-09-20
<Saint-iGNUzio> Md
#upstart 2008-09-21
<tapan_chugh> how to add this line in upstart 'S0:345:respawn:/usr/sbin/vgetty ttyS0'
<tholme_> add event.d/ttyS0 with:
<tholme_> start on stopped rc3
<tapan_chugh> with what
<tholme_> start on stopped rc4
<tholme_> start on stopped rc5
<tholme_> stop on runlevel 0
<tholme_> stop on runlevel 1
<tholme_> stop on runlevel 6
<tholme_> respawn
<tholme_> exec /usr/sbin/vgetty ttyS0
<tapan_chugh> now do i have to type init q
<tapan_chugh> what do i do now
<tapan_chugh> some body help me
#upstart 2009-09-14
<Keybuk> I discovered a really nice Upstart feature over the weekend
<Keybuk> it wasn't one I designed, but it's a wonderful emergent feature
<ion> :-)
<ion> The mountall patches should be in a working condition now, btw. The bug i noticed the last time you were around was the last one iâve been able to find so far.
<ion> Please describe the feature. :-)
<Keybuk> because of the blocking behaviour of event operators
<Keybuk> you can use events as checkpoints
<Keybuk> for example
<Keybuk> starting a GNOME session
<Keybuk> place "initctl emit gnome-session-start" in the /etc/gdm/PreSession/Default script
<Keybuk> you now have an event for gdm starting a gnome session
<Keybuk> all well and good
<Keybuk> but let's say you want to defer some boot operation until the gnome session has started
<Keybuk>   start on gnome-session-start
<Keybuk> pretty obvious really
<Keybuk> but now let's say you not only want to defer the boot operation, but you don't want the gnome-session to start unless it's been done
<Keybuk> turns out to be the exact same command ;)
<ion> Neat :-)
<Keybuk> what about something which could happen earlier, but must happen before session start ?
<Keybuk>   start on filesystem or (filesystem and gnome-session-start)
<Keybuk> if g-s-s happens before filesystem, g-s-s will *block*
<Keybuk> as soon as filesystem happens, either way, the start condition becomes true
<Keybuk> if filesystem beats g-s-s, g-s-s never blocks
 * Keybuk likes this
<Keybuk> need to reboot, brb
<Keybuk> oh, and I forgot
<Keybuk> say you need gnome-session-start to block if a service is still running:
<Keybuk> just put a job file with nothing else in it except
<Keybuk>   start on stopped mountall and gnome-session-start
<Keybuk>   task
<Keybuk> now gdm will wait for mountall to complete before starting the login session
<ion> Nice
<Keybuk> ion: am still trying to think of how to handle remote mounts in mountall
<Keybuk> almost tempted to say that mountall should simply exit when all it has left are remote mounts
<Keybuk> and re-run mountall on ifup
<Keybuk> e.g. mountall --network or something
<Keybuk> if mountall is already running, that could prod it
<ion> How is that different than leaving it running and using USR1? I mean, of course itâs *different*, but what does that achieve better?
<Keybuk> no different, was just wondering about whether or not it was a good idea
<ion> It seems to me it would be simpler to leave it running and trigger (re)mounts from an external message, be it signal or something else.
<ion> If mountall --network has to prod a previous instance if one exists, you have to implement that *anyway*. Might as well only use it that way.
<Keybuk> yeah
<Keybuk> just thinking about the fact that you may end up with mountall always running
<Keybuk> because you have some insignificant network mount that never mounts
<Keybuk> but I guess that's ok too
<ion> Thatâs not too bad IMO.
<ion> If you want to get rid of the mountall process, simply get rid of the fstab entry that never mounts. :-)
<Keybuk> I think that remote mounts are going to have to be allowed to fail
<Keybuk> since it may need a different network interface
<ion> Indeed
<Keybuk> which means if you have /usr on NFS, and it fails to mount, you'll have a hung boot
<ion> Until the correct interface comes up and mountall retries?
<Keybuk> well, it could be that, for example, the remote machine isn't up
<Keybuk> I think this is solveable though with the progress functionalith
<Keybuk> e.g. usplash comes up because we're still waiting
<ion> Yeah
<Keybuk> and we put a message there saying what FHS-critical filesystems we're still waiting for
<ion> Would something like this look okay? (No test cases or anything else yet.) http://heh.fi/patches/libnih-abort-msg
<sadmac2> Keybuk: I thought you ditched usplash in favor of $fooshiny
<ion> (http://launchpadlibrarian.net/31650305/glib2.0_2.21.6-0ubuntu1_2.21.6-0ubuntu2.diff.gz)
<Keybuk> sadmac2: no
<sadmac2> Keybuk: hmm. where'd I read that then...
<Keybuk> ion: ooh, you patched that <g>
<Keybuk> ion: what's the abort_msg_parent thing for?
<Keybuk> ion: isn't it possible to do this in nih_assert() itself?
<ion> I could drop the parent, and e.g. nih_strdup the message and put that to __abort_msg. Whicheverâs better.
<Keybuk> dunno
<ion> nih_assert is just a macro that does nih_log_message and abort. It leaves the printf processing to nih_log_message, so i pretty much have to set __abort_msg in nih_log_message, unless the whole thing is modified a lot.
<Keybuk> yeah, I guess it does tend to offload everything to nih_log_message
<ion> I could move the parent inside nih_log_message, of course. http://heh.fi/patches/libnih-abort-msg
<sadmac2> ion: the first conditional in that parent looks unnecessary
<sadmac2> s/parent/patch
<sadmac2> ion: you assign the variable to NULL and then check for NULL
<Keybuk> ion: why does it need a parent at all?
<ion> Ok, using strdup now. http://heh.fi/patches/libnih-abort-msg
<ion> Whoops, forgot the parent parameter to nih_strdup.
<Keybuk> I guess one easier thing to do would be to add another log level
<Keybuk> NIH_LOG_ASSERT
<Keybuk> above NIH_LOG_FATAL
<Keybuk> and call abort() inside nih_log_message, after setting __abort_msg ?
<Keybuk> maybe that's too convoluted to save a strdup though ;)
<ion> :-)
<Keybuk> but could you open a bug with that patch on libnih for me?
 * sadmac2 reminds himself to add backtracing to libnih
<ion> Will do
<Keybuk> sadmac2: the confusion is exactly what xsplash is
<Keybuk> xsplash is basically just a splash screen that sits between X loading, the gdm login screen and the user's desktop
<Keybuk> X-gdm login because gdm takes seconds to start its login screen
<Keybuk> gdm login-user's desktop because GNOME is shit
<Keybuk> (X-user's desktop in the case of auto-login)
<Keybuk> we're also starting X very early comparatively, so it's worthwhile having the longer splash screen
<Keybuk> in fact, I'm using those event tricks I was talking about here
<Keybuk> so xsplash appears, then there's an Upstart event
<Keybuk> that Upstart event is used to "finish up" things that we need started before GDM or the user's desktop
<Keybuk> without them needing to delay X
<sadmac2> Keybuk: we just have fades between those points
<Keybuk> fades between what and what though? :)
<sadmac2> Keybuk: also your checkpointing thing scares me :(
<Keybuk> you have plymouth from initramfs to X
<Keybuk> fade into some kind of splash screen
<Keybuk> fade into gdm
<Keybuk> fade into some other kind of splash screen
<Keybuk> fade into user's desktop
<Keybuk> ?
<sadmac2> plymouth onscreen, fade to gdm, fade to users desktop
<Keybuk> so what's on screen after you've logged into gdm?
<ion> https://bugs.edge.launchpad.net/libnih/+bug/429411
<sadmac2> Keybuk: gdm
<Keybuk> you press enter at the password prompt, what stays on screen until the user's desktop?
<sadmac2> Keybuk: it stays visible
<sadmac2> Keybuk: I think gdm goes to a waiting-to-log-you-in thing before quitting, so it should be that
 * sadmac2 would know if he rebooted more often
<Keybuk> right
<Keybuk> that stuff isn't upstream
<Keybuk> likewise, you've never contributed the X patches upstream that allow plymouth to stay on screen while gdm starts ;)
<sadmac2> Keybuk: ...should be...
<ion> sadmac: Btw, the code was { static foo *bar = NULL; if (! bar) bar = baz (); }. Thus bar is kept between function calls and only initialized once.
 * soren notes that there's no ubottu or anything in here.. Is that intentional?
<sadmac2> Keybuk: wat?
<Keybuk> (though iirc, plymouth looks completely frozen while gdm starts because obviously it can't animated once X takes over the framebuffer)
<sadmac2> Keybuk: plymouth always stops in a state where that makes snese
<Keybuk> soren: this isn't an Ubuntu channel
<soren> Keybuk: Indeed. Nevertheless, the lp bug resolution magic is really convenient :)
<sadmac2> Keybuk: our X server should be totally upstream...
<sadmac2> Keybuk: granted it may be 12 revisions ahead of the released branch....]
<Keybuk> sadmac2: it isn't
<Keybuk> you have about 200 patches which aren't upstream
<sadmac2> Keybuk: you should beat on airlied at LPC then :)
<sadmac2> ajax is probably more appropriate, but beating on him is a health hazard
<Keybuk> it doesn't overly bother me :)
<Keybuk> I like knowing projects that Fedora has special patches for
<Keybuk> so every time spatula starts on his "we contribute everything upstream" rant, I start sending him URLs
<Keybuk> I know that the *reality* of developing a distro is that you have patches to glue things together that aren't really ready for sending upstream
<Keybuk> or make assumptions that upstream won't accept
<Keybuk> hell, even when you're upstream yourself, you know that the patch is ok for your distro because it assumes something but not ok for upstream
<sadmac2> Keybuk: I don't know of any Fedora devs that aren't moreso upstream Xfolk, so yeah...
<sadmac2> *Fedora X devs
<ion> It *would* be kind of nice to use plymouth instead of usplash for the pre-X fsck messages, so there would be no need to maintain usplash. But i guess that has been considered and discarded.
<Keybuk> no
<Keybuk> if someone wanted to do the work to get Plymouth working in Ubuntu
<Keybuk> then sure ;)
<Keybuk> the reason we've stuck with usplash is that it works, and the cost of sticking is zero
<sadmac2> Keybuk: I'm sure rstrode would be supportive.
<Keybuk> whereas we don't know that Plymouth works, and it needs new themes written, and needs integrating (all those usplash_writes need replacing, etc.), so the cost of changing is high
<Keybuk> I can't imagine that we'll forever stick with and maintain usplash
<ion> It works FSVO works. It never has been able to use the correct resolution on any of my computers; the logo has always had wrong proportions. ;-)
<sadmac2> Keybuk: don't forget the initrd hook
<Keybuk> but right now, we don't have anybody who can do plymouth
<Keybuk> ion: right, we briefly tested it and it didn't get something right like that on one machine
<Keybuk> on another it didn't display graphics at all, just a text bar at the bottom
<Keybuk> and on the third, it fell back to 16 colours or something
<Keybuk> so of the three test machines, it failed on all three
<sadmac2> Keybuk: the text bar thing will be an ongoing thing. plymouth uses KMS. KMS doesn't work everywhere.
<ion> I mean, usplash fails to use the correct resolution here.
<Keybuk> sadmac2: I've been *assured* that Plymouth works on non-KMS graphics cards
<Keybuk> (graphically)
<Keybuk> I think this is a lie
<sadmac2> Keybuk: who assured you this?
<sadmac2> Keybuk: it is a lie.
<sadmac2> Keybuk: graphics are KMS-only
<Keybuk> sadmac2: various people on http://www.netsplit.com/2009/09/02/making-a-splash/ comments
<Keybuk> (may have to click "Older comments")
<Keybuk> neo says:
<Keybuk> September 2, 2009 at 12:18 pm  (Edit)
<Keybuk> I am sorry but Usplash and Plymouth are very different. Plymouth can work on the non KMS case using frame-buffer.
<Keybuk> ec.
<sadmac2> Keybuk: well if it can, it can't do it in F11
<Keybuk> I think that this person doesn't know what he's talking about
<Keybuk> the whole point of KMS is that it provides a framebuffer
<sadmac2> Keybuk: beware the words of people named for Matrix characters
<Keybuk> in the non-KMS case, you *do not have a framebuffer*
<Keybuk> (unless you use vesafb of course, in which case, hello sixteen colours glory)
<sadmac2> Keybuk: fuck yeeeeeah!
<sadmac2> Keybuk: regardless of where ubuntu goes you should really sit down with rstrode and talk about the whole splash thing. He's the only one I'd trust on Plymouth
<Keybuk> there's no point me sitting down with him this year
<Keybuk> I won't have any time until at least June ;)
<Keybuk> probably not until 2011 in practice
<Keybuk> sadmac2: why does the checkpointing thing scare you?
<sadmac2> Keybuk: its making use of the internal state held by and, which is scary because there's no way to really observe it from userspace. Its using the syntax in a way that makes no sense given what the stanzas mean... its hackish.
<Keybuk> the syntax makes it odd
<Keybuk> but I don't think it's hackish
<Keybuk> it's doing exactly what this stuff was *designed* to do
<Keybuk> allow you, through their blocking behaviour, to use simple events to produce complex dependency and ordering behaviours
<sadmac2> Keybuk: I was actually disappointed when I noticed triggers /didn't/ remove this behavior. Guess I'm glad now.
<Keybuk> it's an emergent behaviour of the "before" stanza
<Keybuk> ie.
<Keybuk>   before foo and before bar
<Keybuk> implies that foo and bar will both be delayed until *after* your service is run
<Keybuk> even if before they were not
<sadmac2> Keybuk: I got to the point yesterday where I had to replace event operator related stuff in parse_job, which got me thinking about replacing parse_job/nih_parse again
<Keybuk> any particular reason?
<sadmac2> I need to look at other L1 parsers. bison was good but not quite up to snuff for a grammar as out there as job definitions.
<mbiebl> Keybuk: there is a funny typo in netbase's postinst
<mbiebl> upstart-rc.d ;-)
<Keybuk> heh
<Keybuk> I do that quite a lot
<Keybuk> and I try and install udevs on the installer
<Keybuk> udev-udeb just kills me
<ion> :-)
<mbiebl> in the ubuntu-boot ppa, i.e.
<Keybuk> already fixed
#upstart 2009-09-15
<ion> keybuk: Feel like merging my mountall changes? :-) I could rebase the patch set on to the current mountall source package later today, but there are probably no conflicts.
<Keybuk> ion: am going to merge after alpha 6 is out
<ion> Alright
<pocek> Hi
<sadmac2> hello
<pocek> How's upstart 1.0 going? I watched fosdem video and it seems really promising :)
<sadmac2> its going'
<sadmac2> pocek: are you on the mailing list?
<pocek> Just subscribed
<sadmac2> pocek: well that's the place to be
<sadmac2> I'll probably shoot another braindump towards scott tonight
<Keybuk> \o/
<sadmac2> Keybuk: celebrating my braindump or have you done wonders?
<Keybuk> celebrating your brain dumps
<Keybuk> I like them
<sadmac2> sweet
<Keybuk> for a start, they help me actually work out what *I* mean sometimes :p
<Keybuk> plus you have lots of ideas
<sadmac2> Keybuk: I got a bit sidetracked last night in my coding. Long story short libnih is about to grow a non-deterministic RE language parser to replace nih_config :)
<sadmac2> Keybuk: bison was inadequate, so I'm writing us our own.
<Keybuk> heh
<Keybuk> I'm clearly rubbing off on you ;)
<ion> :-)
<Keybuk> "why use this pre-canned library when I COULD WRITE MY OWN!" :p
<ion> sadmac: Have you looked at PEGs?
<ion> http://treetop.rubyforge.org/ as an example project implementing PEG.
<ion> They have some pros and some cons.
<sadmac2> ion: I spent a good few hours trying to get my hands on any parser generators I could find. Didn't find those.
<sadmac2> ion: the big thing we need is a non-deterministic lexer. For example: "start on start". The same token has two different meanings in that stanza.
<sadmac2> Its a keyword, and then later its an unquoted string.
<ion> PEG should handle that fine
<ion> Without any extra effort.
<sadmac2> ion: the other thing I wanted (more of a nice-to-have) is expressions that take arguments. Its good for things like this:
<sadmac2> opstring(SEP) ::= event SEP OPERATOR SEP event
<sadmac2> on_opstring ::= opstring(NONBREAKING_SPACE)
<sadmac2> event ::= event_spec | '(' opstring(BREAKING_SPACE) ')'
<ion> Please give an example of a chunk to be parsed by that.
<sadmac2> the being-nested-makes-linebreaks-ok thing is really annoying in bison
<ion> Ah
<sadmac2> ion: surely. "start on a and (b or \n c) \n start on a and b or \n c"
<ion> Yeah, got it
<sadmac2> ion: the \ns are linebreaks
<sadmac2> ion: the second line there should be an error
<sadmac2> ion: the first should be fine
<sadmac2> its less of a pain to do conventionally when you don't have big chunks of identical handler code for each version of opstring
<sadmac2> that grammar was kinda fudgy
<sadmac2> opstring(SEP) ::= event | opstring(SEP) SEP OPERATOR SEP opstring(SEP) | '(' opstring(BREAKING_SPACE) ')'
<sadmac2> on_opstring ::= opstring(NONBREAKING_SPACE)
<sadmac2> much better.
<sadmac2> BNF is hard, lets go shopping
<sadmac2> ion: implementing these can't be easy, and ruby isn't a good libnih dependency :)
<ion> As i said, itâs just an example implementation. One is free to implement PEG without such dependencies.
<sadmac2> ion: yeah, I just wonder what it would take to do in C :)
<sadmac2> ion: right now the plan is just to use C syntax and express it that way.
<sadmac2> with hopes of then bootstrapping the specification of a better grammar through that later on.
<ion> Extending e.g. Treetopâs âruleâ element with parameters (as you described) would be very natural in fact. If one is to implement PEG in C, passing the separator as a parameter wouldnât be the hard part. :-)
<ion> Pseudo-treetopish-code:
<ion> On a second thought, iâll write this to pastebin. Moment.
<ion> Something like http://pastebin.com/f79d84635
<sadmac2> ion: I'm so used to people bending ruby into dsls that I keep trying to think how this still constitutes valid ruby :)
<ion> PEG consumes input greedily, just like a regexp, without a need for separate tokenization. PEG can be thought of as an extended regexp that supports giving names to chunks and calling them by names (and recursion comes with that).
<ion> Thatâs not Ruby. Thatâs Treetop grammar syntax.
<sadmac2> ion: yeah
<ion> Say, begin with a plain regexp:
<ion> hello\s+[a-zA-Z0-9]+
<ion> Give it a name:
<ion> hello_stanza := hello\s+[a-zA-Z0-9]+
<ion> Split it to parts and give them names:
<ion> hello_stanza = 'hello' whitespace name; whitespace := \s+; name := [a-zA-Z0-9]+
<ion> And implement support for recursion. Thereâs your basic PEG parser.
<ion> Just a regexp engine extended a bit.
<sadmac2> ion: sounds nice.
<sadmac2> ion: I may do that.
<sadmac2> ion: I could probably extend glibc regexen to do most of it for me too
<ion> And as for precedence, itâs greedy just like regexps: the first matching tree is the one it picks.
<ion> Want anything in parenthesis to have precedence over an and expression, and that to have precedence over an or expression? Give them in that order:
<ion> event_spec := '(' event_spec ')' | event_spec sep 'and' sep event_spec | event_spec sep 'or' sep event_spec | event;
<ion> or something along those lines.
<ion> The regexp engine looks at the next character. Is it '('? Nope? Then look at the next alternative. Just like a plain regexp such as /\(foo\)|alternative|another/
<ion> PEG does have some disadvantages: http://en.wikipedia.org/wiki/Parsing_expression_grammar#Disadvantages
<sadmac2> ion: searching the fedora repos for peg gives me every mpeg and jpeg tool or library ever written
<ion> http://piumarta.com/software/peg/
<sadmac2> ion: I was just about to link you the same thing
<ion> Search for \<peg\> or \bpeg\b, depending on the regexp dialect of rpm or whatever. :-P
<ion> (No PEG results in Ubuntu, though.)
<sadmac2> ion: this looks new, and reeks of next months abandonware
<ion> He has bothered to write an extensive manual, that tells something. :-) http://piumarta.com/software/peg/peg.1.html
<sadmac2> Keybuk: care to weigh in with preferences?
#upstart 2009-09-16
<Keybuk> sadmac2: interesting.
<Keybuk> btw, you pretty much read my mind on the sub-job thing
<Keybuk> and action thing
<Keybuk> even down to the whitespace separation ;)
<Keybuk> I've wanted to see if it were possible to do all the pre-stop/post-stop scripts as sub-jobs for a while
<Keybuk> so let me think on your mail for a day and see where I can poke holes ;)
<Keybuk> this is kinda where I was going with pre-stop the other day
<Keybuk> I thought that, exactly as you suggest, that
<Keybuk> <argument> exec <command>
<Keybuk> <argument> script
<Keybuk> ...
<Keybuk> end script
<Keybuk> would define actions
<Keybuk> and I'd also add <argument> signal <signalname or number>
<Keybuk> where <argument> could probably be anything
<Keybuk> thus "job <argument>" would be a state, just as job was
<Keybuk> and "job <argument>" would be an event too
<Keybuk> so "job pre-start" becomes a state and event (while job's pre-start action is running)
<Keybuk> and "job post-stop" likewise
<Keybuk> I figured that events would still block their states
<Keybuk> I didn't get as far as figuring out how it'd know to run pre-start and post-stop at the right times though
<Keybuk> my thought was you'd have <argument> on/while ...
<Keybuk> so
<Keybuk> reload signal HUP
<Keybuk> reload daily
<Keybuk> or something
<Keybuk> the competing syntax, of course, being
<Keybuk> define reload
<Keybuk>   signal HUP
<Keybuk>   daily
<Keybuk> end define
<Keybuk> or job or action or whatever
<Ng> out of curiosity, is there an upstart form of the "reload" sysv concept?
<Keybuk> Ng: not yet
<Ng> ok :)
<ion> Neat http://testape.com/webtty_page.php
<sadmac2> ion: what the hell?
<Keybuk> ion: your don't-fsck-twice patch introduced a bug ;)
<Keybuk> now it doesn't retry to mount filesystems
<ion> Agh
<Keybuk> should probably call device_ready() in that if block
<Keybuk> sadmac: did you see my replies last night btw?
<sadmac2> Keybuk: on IRC? yes
<Keybuk> cool
<Keybuk> was just brain dumping in return
<Keybuk> will reply to your mail proper later
<sadmac2> cool
<sadmac2> Keybuk: so I'm implementing a PEG in libnih after ion's recommendation. As parser styles go it feels the most right for libnih, and rolling our own makes sense since all the others are kind of vaporwareish.
<Keybuk> I don't really understand that bit ;)
<Keybuk> but I look forwards to seeing the results
<sadmac2> ok then :)
<Keybuk> if it can do clang-style "your problem is here ^~~~~~~" type things, that would be k-rad-awesome
<sadmac2> I saw 2 or 3 of the things that were in C, but none of them were in source control.
<sadmac2> yeah, there should be a way
<sadmac2> I'm trying to implement it very minimalistically right now. I want enough of it in place that I can go back and finish what I was doing, and then I can polish it.
<sadmac2> since this is all happening on an interrupt (attempt to alter parse_job.c caused SIGREWRITE)
<ion> Why not base your work on the project we looked at yesterday?
<sadmac2> ion: ...straight up stealing the code is something I hadn't considered...
<sadmac2> open source is cool like that.
<ion> A PEG parser should be able to point out the precise problematic byte by keeping track of the furthest position it ever reached in the input stream.
<ion> (btw)
<sadmac2> ion: exactly
<sadmac2> ion: which it would more or less have to keep track of anyway for normal operation
<sadmac2> ion: you can actually get primitive error handling right away just by doing error <- "start" WS "on" "WS" /.*/ { send_error ("unexpected crap after start on") } as the lowest priority rule in the set.
<ion> True
<sadmac2> and that also gives you the benefit of actually pushing an error token like in yacc, which means you can keep parsing and find more syntax errors.
<ion> Yeah
<PuffTheMagic> what is the difference between "initctl jobs' and "initctl events"
<sadmac2> PuffTheMagic: one shows events, one shows changes in jobs
<PuffTheMagic> well arent jobs events?
<PuffTheMagic> what is the definition of a job
<sadmac2> PuffTheMagic: jobs are not events
<sadmac2> PuffTheMagic: a job is an object that exists in a state. an event is a point in time.
<Keybuk> (this is the primary reason why the config files moved from /etc/event.d in later Upstart releases, it confused people)
<PuffTheMagic> ok i get it
#upstart 2009-09-17
<ion> Ridgeway of Oxfordshire Foreign Export Stout is quite okay.
<sadmac> ion: sounds good
<sadmac> ion: I don't suppose you're getting to lpc this year?
<ion> Nope
<ion> It would be fun to attend, though.
<sadmac> it'd be cool to have you
<ion> :-)
<ion> LPC 2010 in Tampere, Finland? ;-)
<sadmac> ion: Portland, Portland, _________
<ion> :-P
<sadmac> Tampere almost sounds like it could be in Canada
<sadmac> As an illiterate American, I expect scandinavian places to have names like Skjoldnjikfjord
<ion> Equally cold at least.
<ion> Ah, my aunt lives in Skjoldnjikfjord.
<sadmac> I believe it.
<ion> As for Portland, Portland, _______; the Fibonacci sequence has two consecutive ones but then it goes to two.
<sadmac> ion: are you implying that Tampere, Finland is 2?
<ion> No, Tampere, Finland us â1.
<ion> is
<sadmac> ion: which means 2*Portland = -1
<ion> Sounds about right.
<ion> If you really like to shit the funky shit
<ion> That was a sample from ionâs random playlist. Now back to our regular programming.
<PuffTheMagic> are the last to arguments of nih_command_parser needed?
<PuffTheMagic> or can they be null
<sadmac> PuffTheMagic: they're mandatory
<sadmac> PuffTheMagic: what would it do if they weren't?
<PuffTheMagic> i am makking a wrapper for upstart 3.x which basically extends some of the initctl functions over dbus
<PuffTheMagic> and i figured using nih_command_parser would be the easiest way
<PuffTheMagic> and it looke dlike argv was used to pass the real commands
<PuffTheMagic> so im not sure what the last 2 params are used for
<sadmac> PuffTheMagic: they say what commands to parse from argv
<PuffTheMagic> oh
<PuffTheMagic> i just assumed it would parse what was there
<PuffTheMagic> seems a littel redundant
<sadmac> PuffTheMagic: and do what with it?
<PuffTheMagic> sadmac: do what with what?
<sadmac> PuffTheMagic: what it parsed.
<sadmac> PuffTheMagic: the last two arguments are how you tell it what the commands do
<PuffTheMagic> oh
<polz> I guess I won't be the first one to ask this in the past few days:
<polz> how do I get the latest upstart in karmic to mount my /home partition which is on lvm on a software raid?
<Keybuk> polz: this isn't the right place for Ubuntu support, try #ubuntu
<polz> Keybuk: what would be the right place for questions about mountall?
<Keybuk> polz: #ubuntu
<Keybuk> or, if you have a bug, launchpad
<polz> Keybuk: ok, thanks.
#upstart 2009-09-18
<mbiebl> Keybuk: hi
<mbiebl> noticed two issues with the latest push for native upstart jobs in karmic:
<mbiebl> 1) initscripts 2.87dsf-4ubuntu3 reintroduced the legacy sysv initscripts, but the version check in postinst is le-nl "2.87dsf-4ubuntu2"
<mbiebl> so they were not removed again when upgrading to 2.87dsf-4ubuntu4 and marked as obsolete now
<mbiebl> 2) cryptsetup seems to install both sysv initscripts and an upstart job file
#upstart 2009-09-19
<ion> (offtopic) A Monkey Island game for free: http://www.telltalegames.com/playlikeapirate
<mgoetze> hi ... from the manpage, i can't figure out what effect specifying "respawn" for a service actually has, since that is, supposedly, the default...
<Esmil> mgoetze: Which version of upstart are you using? At least with 0.6.3 jobs behave differently with and without respawn
<mgoetze> Esmil: hm yes 0.6.3, and it seems they indeed don't respawn without respawn, which means the manpage is rather confusing
<mgoetze> does upstart have any events for ac power plugged in etc. ?
<Esmil> mgoetze: I don't think it has, but I haven't tested it. It shouldn't be too hard to add a udev rule firing 'initctl emit' or something similar though
<mgoetze> i guess cron functionality such as "start every hour" isn't implemented yet?
<Esmil> No, but its planned
<Esmil> Btw. I just remembered I have an udev rule to fire an event everytime I swith on/off my wireless, its definately possible to do it for ac power too
<mgoetze> eh... has my /etc/udev/rules.d always been so empty? *scratches head*
<mgoetze> hm, how does one autmatically start multiinstanced jobs? i tried the following:
<mgoetze> start on runlevel [23] TTY=tty2
<mgoetze> but it doesn't seem to have worked :(
<Esmil> mgoetze: I don't think thats possible at the moment. You can, however make another job, eg. tty2.conf, just start on runlevel [23], pre-start exec start getty TTY=tty2, post-stop exec stop getty TTY=tty2
<mgoetze> oh... that sucks :(
<Esmil> Yes, it does. In order to fix it you'd have to figure out some new syntax of job files since events can have key/value pairs too. Probably something like "start TTY=tty2 on some-event KEY=value"
 * mgoetze reports his first ever launchpad bug
<mgoetze> am i not allowed to set the severity to wishlist myself?
#upstart 2010-09-20
<oojah> Does boot-up manager work with upstart?
#upstart 2010-09-21
<Keybuk> keybuk: test
<ion> indeed
<__keybuk> keybuk: test
#upstart 2010-09-23
<dlezcano> hi all
#upstart 2010-09-24
<ion> keybuk: Have you played Amnesia: The Dark Descent? Iâm loving it.
<Keybuk> nope, I don't know that one
<ion> Itâs a survival horror game by the guys behind the Penumbra series.
<Keybuk> ah cool
<Keybuk> right, Hoegaarden at Twitter HQ beckons
#upstart 2010-09-25
<dvrvm> hi. does the trigger "remote-filesystems" not work?
<BLZbubba> is there a way to have upstart be verbose during bootup?
<BLZbubba> i have a couple of machines that freeze during bootup with no way to know where - even in single user mode
<BLZbubba> and one of them ends with plymout-splash terminated with status 2
<BLZbubba> god, upstart is the most annoying piece of shit ever, network problem means even single user mode doesn't come up.
#upstart 2010-09-26
<enterusername> hello
<enterusername> is there anyone here?":
<enterusername> would like to know how to change the order of when upstart starts its services
<enterusername> for example in sys v it would be S99 and S1
<enterusername> i have a problem where cups starts after samba
<enterusername> and i would like to make sure cups is running before i start samba
<Stevee> just create to jobfiles, one for cups one for samba and define as start event for samba the started cups server
<Stevee> sorry two jobfiles
<casualjim> hi guys, i've been trying to use upstart to monitor a java process but I'm not having much luck at all. There is also no output I could find to help me debug the problem. 
<casualjim> my current solr.conf file https://gist.github.com/f712e5642aa70aa4d8df
<ion> The outputâs in syslog.
<ion> expect fork wonât really work for sh scripts, since theyâre likely to fork-and-exec a number times before the daemon finally forks.
<ion> The date command in your script does the first fork and Upstart will gladly follow it.
<casualjim> I've also tried without the date command.. and without expect fork.. but I'll try again with just the exec line and see where that gets me
<casualjim> ok thanks I've got it working now
#upstart 2011-09-20
<bencc> how can I check in a script if an upstart job is running?
<JanC> bencc: you can parse the output of "initctl status", or use dbus?
<bencc> JanC: I think this will work: if [ status myjob | grep -q 'start/running' ]; then
<JanC> technically it's still running when the status is 'stop/running' too  ;)
<JanC> but not for long (if everything goes well)
<bencc> JanC: it will be useful to have a simple command that gives you 0/1
<JanC> bencc: the "X/Y" part is "target/status", so the part after the "/" is the current status
<JanC> but yeah, maybe a more script-friendly initctl command might be useful  âº
<nickradford> How do you write a script that will allow any user to start the service without using sudo?
<JanC> nickradford: sudo was specifically designed to allow that, why don't you want to use it?
<nickradford> I'm trying to have a service which runs a node.js web application, and `start myservice` will be called remotely over ssh, but users which don't know the account they're accessing's password.
<JanC> you can configure sudo to allow specific users to run specific commands as root without a password
<JanC> see sudo's manpage & other documentation
<nickradford> alright, thank you JanC :)
<JanC> nickradford: there might be more support for such things in future versions of upstart, I don't know, but i'm pretty sure sudo can already do what you want  ;)
#upstart 2011-09-21
<mattbillenstein> hi all
<mattbillenstein> is this the correct place for help with upstart?
#upstart 2011-09-24
<Laibsch> I'm concerned about bug 430224. SpamapS told me that the fix for that ticket may only include support for Ubuntu chroots on a Ubuntu host.  Is that true?
<Laibsch> Can I run an Oneiric chroot on a Debian host?
<Laibsch> or is that impossible because Ubuntu now uses upstart and Debian IIRC still uses SysV
#upstart 2012-09-19
<j4m3s_> i have an upstart script that doesn't appear to be setting the limit stack size, i have a pre-start script that sets the limits but my startup script throws a warning when the limit isn't set properly
<SpamapS> j4m3s_: pre-start does not share process space/group w/ the main process
<SpamapS> j4m3s_: you can just put that in script/end script with the main process
<j4m3s_> SpamapS: http://pastie.org/private/nhapxgtg2qzzxzpjkjptg
<SpamapS> ahh limit stanza
<SpamapS> j4m3s_: http://pastie.org/4751117
<SpamapS> j4m3s_: forgot to make it private.. but.. that might work
<j4m3s_> i tried that too
<j4m3s_> SpamapS: just confirmed still getting the same error
<SpamapS> j4m3s_: what version of upstart is this btw? 1.4 and later will log stdout/stderr to /var/log/upstart/$jobname.log
<SpamapS> j4m3s_: hm, with the numeric value, you need the soft and the hard
<j4m3s_> 0.9
<j4m3s_> SpamapS: i tried changing it to 999999 999999, still getting same warning
<SpamapS> j4m3s_: just to be sure, are you doing a full 'stop' then 'start' or just 'restart' ?
<j4m3s_> restart
<SpamapS> j4m3s_: ok, stop/start are needed to reload the job file
<j4m3s_> SpamapS: start freeswitch   start: Unknown job: freeswitch
<SpamapS> j4m3s_: check syslog, its probably got a syntax error
<SpamapS> j4m3s_: if you have init-checkconf you can use that too
<j4m3s_> SpamapS: http://pastie.org/private/knrpjsuz6nl84cojzx4tng
<SpamapS> j4m3s_: thats after you fixed whatever was causing the "unknown job" ?
<SpamapS> j4m3s_: KILL is sent 5 seconds after TERM when you stop a job
<j4m3s_> i forgot the expect daemon
<j4m3s_> sorry 
<SpamapS> still weird htt it would say KILL
<SpamapS> usually it would just say that it exitted with status 1 or 0 or something
<j4m3s_> SpamapS: it's still not working, it says it's running but it's not running
<j4m3s_> SpamapS: it appears that upstart loses it whenever i put the limit stanza with the exec, if i put it in pre-start it tracks it fine and everything starts up fine
<j4m3s_> SpamapS: the only way it succeeds is if the limit lines are commented out or in pre-start
<j4m3s_> SpamapS: got it to work ;)
<SpamapS> j4m3s_: perhaps your daemon only forks once, so 'expect fork' is more appropriate?
<SpamapS> j4m3s_: what was the trick?
<tohava> If I want to have shell code run SYNCHRONOUSLY before a service, should I put it in pre-start?
<jodh> tohava: yes, that is guaranteed to be run before that jobs main ('exec' or 'script') stanza.
<tohava> jodh, thanks
<jodh> tohava: this is covered in the Upstart Cookbook here: http://upstart.ubuntu.com/cookbook/#job-lifecycle and is also in upstart-events(7) after all the tables :)
#upstart 2012-09-20
<astrostl> is there a way to 'unstick' the upstart system on rhel6 without rebooting?  stop: Job has already been stopped: elasticsearch - fair enough.  when i start it, though, it hangs indefinitely.  i've had this happen before when developing scripts, and the 'fix' is to reboot it and start with a good script.
<astrostl> rhel6 upstart = upstart-0.6.5-12.el6.x86_64 .  old, i know.
<astrostl> i know my scripts are right now because if i copy elasticsearch.conf to elasticsearch2.conf it starts and stops correctly
<SpamapS> astrostl: stuck how?
<astrostl> i ended up rebooting to clear it, but
<SpamapS> astrostl: can you paste the output of 'status elasticsearch' and the job.conf ?
<astrostl> stuck as in 'start elasticsearch' does nothing
<astrostl> hangs indefinitely
<SpamapS> astrostl: hangs indefinitely sounds like a problem with the .conf file
<astrostl> as verified with the copy, it isn't.
<astrostl> http://pastebin.com/6tmJ4tau
<astrostl> (there is a leading s in the actual file)
<SpamapS> weird, that should return as soon as su is executed
<astrostl> 'start elasticsearch' - hangs forever
<SpamapS> btw, using su has some problems
<astrostl> cp elasticsearch.conf elasticsearch2.conf && 'start elasticsearch' - works perfectly
<SpamapS> it opens a pam session
<astrostl> this isn't an su thing
<SpamapS> agreed, but you should be aware of that
<SpamapS> astrostl: status elasticsearch shows what?
<astrostl> if i ctrl-c, says it's running
<astrostl> if i stop, hangs indefinitely again
<astrostl> if i ctrl-c that, then status, says stopped
<SpamapS> "says its running" is a bit vague
<SpamapS> can you paste the full output?
<astrostl> i ended up rebooting to clear it
<astrostl> example: elasticsearch start/running, process 1753
<SpamapS> astrostl: got syslogs for around that time?
<astrostl> yes, they have nothing of note
<SpamapS> astrostl: should be something like 'init: ....'
<astrostl> i watched messages live, it reports nothing at all when it's in "stuck" mode
<astrostl> not on start, not on stop
<SpamapS> astrostl: I've only ever seen start hang forever when there's a really long post-start or expect fork where the main process never forks
<astrostl> 'kill -HUP 1' doesn't resolve it either
<SpamapS> HUP'ing init is definitely not advised
<astrostl> as i said twice, i ended up *REBOOTING*
<astrostl> relative to that, a HUP on init is not significant in my view
<SpamapS> I understand that. Trying to prep you for the next time.
<SpamapS> astrostl: HUP doesn't do what I thought it did... so ignore that warning. :p
<astrostl> init is designed to take a hup for reloads (e.g. inittab changes)
<SpamapS> astrostl: ok so your question, how do I unstick a job, is hard to answer without some extra logs..
<SpamapS> astrostl: if you expect it to happen again, perhaps raise log priority with 'initctl log-priority info'
<astrostl> i've had this happen 2-3 times during upstart script development
<astrostl> basic pattern: make an upstart script, start it, oops, try to stop, hangs indefinitely, now we're screwed
<astrostl> certain conditions from failed script starts seem to put that *NAME* in a hosed state
<SpamapS> yes there is one well known way to do that
<astrostl> fixing it won't do - fixing it and *RENAMING* (or rebooting) does
<SpamapS> notably, bug #406397
<astrostl> is there a well-known way to undo that, aside from rebooting?
<SpamapS> https://bugs.launchpad.net/upstart/+bug/406397
<SpamapS> astrostl: if its that bug, what has happened is upstart has lost track of the pid it thinks it should be tracking...
<SpamapS> astrostl: the way to know if you've hit that problem is if 'status $jobname' shows a pid that does not exist
<SpamapS> astrostl: the way to fix it w/o reboot is to exhaust the pid space so it does exist, then upstart will kill it
<astrostl> that sounds like the problem exactly
<astrostl> lol @ the solution - but that's exactly what i need to know.  thx!
 * dluna had the exact same problem a couple of weeks ago
<SpamapS> yeah, I'm hoping a fix can be worked out in the next Ubuntu dev cycle, but I doubt that will land in any RHEL release any time soon with systemd looming
<SpamapS> astrostl: please mark yourself as being affected by that bug.. it helps us figure out what to work on next
<SpamapS> that bug, by far, has the highest "heat"
<astrostl> will do, although i'm less optimistic that rhel will notice or care given how far back they are from the prod version of upstart
<astrostl> upvoted, subscribed
<astrostl> thx again, cya
#upstart 2012-09-23
<sobhan> what package upstart depend on ?
<sobhan> how i can start upstart what process grub should start ?
#upstart 2013-09-17
<hyperreal> Hello.  Can someone please tell me how to disable upstart jobs/services permanently, so that they don't start at boot?
<hagna> initctl emit started-postgresql in my postgresql init.d script and start on started postgresql in my upstart script that depends on postgres will actually start postgres and the other service in the right order sometimes
<hagna> most of the time, but is there a way to make the upstart script run after all init.d jobs are done?
#upstart 2013-09-18
<_ramok> hell
<_ramok> o
<_ramok> I'm having upstart running in version 0.65 on centos 6
<quickdry21> I'm running into an issue with some upstart jobs. start works fine, but when i stop them, the command hangs and nothing happens. When i Ctrl+C, the process controlled by upstart is still running. After this happens, any time I start or stop the job, the start/stop command hands and I have to Ctrl+C it, and the job controlled by upstart hasn't been start/stopped.
<ion> quickdry21: See https://github.com/ion1/workaround-upstart-snafu
<quickdry21> ion: thanks, this has been driving me nuts. any idea what causes this? seems to happen when start-stop daemon and upstart are used together
<ion> quickdry21: An âexpectâ stanza that lies to Upstart about the forking behavior of the main process.
<ion> The fastest way to get it to work is to get rid of daemonization altogether and drop the âexpectâ stanza.
<brainwash> this bug report requires some attention https://bugs.launchpad.net/upstart/+bug/1227212
<brainwash> the upstart user session has been identified as culprit
<ochosi> +1 on that bugreport, i've chatted quite a few people up on that in the last few days and it seems pretty much all desktops are affected
<ali1234> how do i enabled upstart xsession debugging, and where does nih_warn messages go to?
<ali1234> looks like i edit /etc/X11/Xsession.d/99upstart and add --verbose to the STARTUP variable
<ali1234> unfortunately the output isn't logged anywhere
#upstart 2013-09-19
<marrusl> huh.  never noticed this before.  if I  `ifdown lo` I get a "net-device-down IFACE=lo" event.
<marrusl> but if I `ifup lo` there's no corresponding net-device-up event.
 * marrusl looks at /etc/network/if-up.d/upstart
<marrusl> ahhh
<marrusl> ok it's specific to lo
<ali1234> argh this is a mess
<ali1234> the "quiesce" code has hardcoded minimum times of 5 seconds
<ali1234> best case it takes 5 seconds, worst and average case it takes 10 seconds
<ali1234> none of the jobs actually respond to the first request to stop
<igalic> Is it possible to run pre-start as root, but "start" as setuid user-foo?
<xnox> igalic: often requested feature. that is not available at the moment.
<igalic> xnox: we did the su hack
<xnox> igalic: yeap.
<xnox> igalic: or you can have two jobs. One which is task and run as root and does "start main-job" and the "main-job.conf" only has the exec with setuid.
<prosys> hi
<prosys> i'm trying to run an interactive shell script before lightdm starts...
<igalic> xnox: a colleague of mine after I told him: 17:43:13 < andreasntaflos> my god ... its full of hacks!
<igalic> I passed on, "Patches welcome."
<prosys> i'm thinking on modifying the lightdm.conf to start on stopped myservice
<prosys> and adding myservice.conf to do everything
<prosys> but i can't make it work :\
<xnox> prosys: "start on starting lightdm" should make your job to run before lightdm, and block lightdm starting.
<xnox> prosys: or do lightdm.override file with "start on stopped myservice"
<xnox> igalic: two jobs is not that hacky, imho ;-) and rather clean.
<prosys> xnox: i've tried that, but for some reason it doesn't show the terminal, boots right into lightdm :|
<prosys> wait
<prosys> i think i've missed something here
<prosys> brb
<prosys> no, no luck :|
<prosys> i have lightdm with autologin
<prosys> and it just starts with no problem
<prosys> and never gets into the interactive shell script i've done
<prosys> do i need to hide plymouth before starting the script ?
<xnox> prosys: what do you mean "interactive shell script", all jobs started by upstart do not have stdin.....
<xnox> prosys: can you paste your "interactive shell script" ?
<prosys> er, it's kinda big
<prosys> but yeah, i need to read input
<prosys> if jobs started by upstart do not have stdin, what options do i have ?
<SegFaultAX> Under what condition does upstart try and respawn a process?
<SegFaultAX> Doing `service foo start` correctly starts foo, but for some reason upstart doesn't think so and starts respawning it.
<SegFaultAX> It does return a successful exit code of 0 upon starting.
<SegFaultAX> Nevermind, the process was forking itself.
#upstart 2014-09-15
<Kufat> Hi. I'm seeing a lot of upstart jobs getting killed by the killall task in rc.0 instead of being stopped by upstart, seemingly because on shutdown, rc goes from waiting to starting but never actually reaches start. Any suggestions?
#upstart 2014-09-17
<checkers> hi, how can I make an upstart job run a service's configtest functionality before allowing a restart?
<checkers> if I put the configtest command into pre-start, upstart will stop the job and then fail to start it with service foo restart
<jodh> checkers: I'm not clear what behaviour you are after then?
<jodh> stgraber: hi - could you review https://code.launchpad.net/~jamesodhunt/upstart/bug-1360208/+merge/234869 when you get a chance?
<mlindner> What's the correct way to get ulimit -c unlimited to actually work in upstart scripts
<mlindner> it appears that upstart doesn't use /etc/profile
<mlindner> so setting it there seems to do nothing
<SegFaultAX> I have a process that appears to daemonize itself. If I add `expect fork`, the process boots correctly but upstart immediately loses its handle on the child process so stops/restarts hang. If I add `expect daemon`, it just hangs on start forever.
<SegFaultAX> If I omit the expect stanza entirely, it boots correctly, but immediately loses the pid (similar to expect fork)
#upstart 2014-09-18
<checkers> the behaviour I'd like is for the restart to not proceed unless configtest passes, but for a 'stop' to still work
#upstart 2015-09-15
<MrCircuitMatt> hello
<MrCircuitMatt> From the docs on the 'expect' stanza, I get: 'If your daemon has a "don't daemonize" or "run in the foreground" mode, then it's much simpler to use that and not run with fork following.'
<MrCircuitMatt> what expect stanza do I specify for the foreground mode? None?
<MrCircuitMatt> hm OK none seems to work
#upstart 2015-09-16
<alper> Hey there! I am struggling with an issue I can't seem to figure out the reason.
<alper> Upstart sends my process a SIGTERM (signal 15) just as soon as it starts 
<JanC> check why the "stop on ..." condition(s) can happen?
<mikira> Hi! I'm trying to chdir into a folder to run a binary in my upstart file
<mikira> but I'm getting "unable to chdir() to .... (No such file or directory)"
<mikira> I can confirm that the directory exists
<mikira> and I have "start on (local-filesystems and network-device-up IFACE!=lo)" as start condition
<mikira> Does anyone can help why can't I chdir to a directory?
#upstart 2015-09-17
<duvnell> I have a service .conf file  which has "start on lightdm"  so that it's started only after the display manager starts.   But of course if the user is running kdm, gdm, xdm, etc.. that doesn't work.  Is there an alias which means whatever-display-manager-the-user-uses or do I need to OR all the possible display manager names that I can think of?
<duvnell> And it doesn't need to way for a user to log in
<duvnell> /s/way/wait/
#upstart 2015-09-18
<braedy> Is there still no easy way to run a script on start up as a user?
<duvnell> despite all the people in this channel.. I asked a question yeterday and you're the first person to speak in this channel
#upstart 2015-09-20
<DarkSector> How do I execute a script that sets environment variables using export before executing a gunicorn command?
<JanC> can you explain what your problem is?  that should work as-is?
<JanC> unless you are trying to set those environment variables in a pre-start script and gunicorn as exec
#upstart 2017-09-19
<frew> I am trying to build an upstart job that executes when other services are started, for the purpose of centrally reporting and monitoring services
<frew> this is what I can up with, based on the cookbook
<frew> `start on ( started or stopped ) and ( JOB=!"cerberus" and INSTANCE=!"cerberus*")`
<frew> so it notices all starts or stops that are not itself basically
<frew> but weirdly, it actually doesn't, and stopping and starting stuff isn't working
<frew> I think I got it working with: `start on started JOB!="cerberus*" JOB!="startpar-bridge" INSTANCE!="cerberus*"`
<frew> and another one that has `start on stopped JOB!="cerberus*" JOB!="startpar-bridge" INSTANCE!="cerberus*"`
