#upstart 2006-09-15 * Starting logfile irclogs/upstart.log -ChanServ(alexanderlisa@example.com.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) -ChanServ(alexanderlisa@example.com.)- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there * ..[topic/#upstart:fabbione] : Upstart 0.2.6 | 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 <fabbione> logs will be available from the next hours or so <DMTM> hello <DMTM> i would like to register my nickname <thom> why do people think upstart is a support channel? <DMTM> hmm <Md> because it's the first or last channel I joined, so stupid people use /who to look for staff members and then think it's a good idea to ask support questions in a random channel <DMTM> ok <LarstiQ> Md: smooth :) <Coldbyte> Md are you there <Coldbyte> ? <NthDegree> i'm using ubuntu edgy eft, and i'm having trouble sorting out a script to mount my dm-crypt loopback drive at boot <NthDegree> can someone help me with getting it added to the new upstart runlevels? #upstart 2006-09-16 <Coldbyte> Md are you there? <Coldbyte> staff members here? <neuralis> Coldbyte: this is not a support channel. <Coldbyte> i know that but Md is listed as staff member <Coldbyte> and i can't pm him about my registration issues as im not registered <zorglub> you should use the dedicated channels <zorglub> I suppose #help exists <Coldbyte> doesnt <Coldbyte> anyway type /who freenode/staff/* <Coldbyte> and you will see <neuralis> Coldbyte: you can always private message staff members. <Coldbyte> the message i get says smth else <Md> Coldbyte: everybody can send messages to staff, I have no clue why you believe this is not possible. anyway, if somebody is not answering usually insisting will not help much <dem> is there documentation on the job format; i'm trying to write a job to start the mythtv backend server <LarstiQ> dem: http://upstart.ubuntu.com/doc/getting-started.html ? <dem> yeah, but it dosen't really list (all) the events that I can use <LarstiQ> from what I gather, there is no limit <dem> i'm trying to figure out exactly what respawn does <dem> since it's in some jobs but not really documented anywhere <dem> for example can i respawn something as a certain user <dem> basicaly i'm trying to figure out, how to start the mythbackend deamon, and have it respawn in the case it goes down, as the mythtv user * LarstiQ has near to zero upstart knowledge <LarstiQ> dem: sorry not to be able of help :/ <dem> and a second script to start an Xserver with the mythtv-frontend, also repsawn that in the case it goes down, but only if the mythtv-database up <dem> that's okay, maybe some one knows <dem> i figured, hell there's this new stuff edgy, might as well use/get on the bandwagon <_ion> "respawn" respawns a daemon in case it dies. <dem> _ion: how do you variables in the job? <_ion> Do you mean environment variables? <dem> yeah <dem> well that too, but how would i do a deamon that respawns when it dies and also runs as a particular user? <alp> from a blog entry i saw, "The IPC mechanism used by upstart is not currently D-BUS because of various problems" -- i was wondering if there's a summary of what these problems are? <_ion> dem: env foo=bar <_ion> dem: Seems like there's no support for setting uid in jobs. It wouldn't be difficult to implement, though. <_ion> alp: There is lengthy discussion about that in the mailing list. <alp> _ion: any idea which list/timeframe? <alp> ah, there is an upstart-devel <alp> _ion: i don't see any pertinent threads <alp> i'm working on a dbus-compatible ipc implementation and want to make sure any limitations of libdbus and its daemons aren't carried on to mine <alp> the only discussion i could find (on the dbus list) relates to process activation #upstart 2006-09-17 <pepsiman> Is it intended that single user mode in edgy runs dash as root's shell? I'd much prefer bash. /etc/passwd says root's shell is bash #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(alexanderlisa@example.com.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) -ChanServ(alexanderlisa@example.com.)- [#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(alexanderlisa@example.com.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) -ChanServ(alexanderlisa@example.com.)- [#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(alexanderlisa@example.com.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) -ChanServ(alexanderlisa@example.com.)- [#ubuntu] Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there <sciboy> Hello fellas. -ChanServ(alexanderlisa@example.com.)- [#ubuntu-server] Ubuntu Server Discussions (development and support) -ChanServ(alexanderlisa@example.com.)- [#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 alexanderlisa@example.com. <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
{'channel': 'upstart', 'month': 9}