[12:31] <_ion> 27C outside. \o/ === j_ack [n=rudi@p508DAD43.dip0.t-ipconnect.de] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === theCore [n=alex@ubuntu/member/theCore] has joined #upstart === iSeriesTech [n=iSeriesT@64-17-87-28.co.warpdriveonline.com] has joined #upstart === int0x0c [n=ben@161.253.46.23] has joined #upstart === pkt [n=knoppel@athedsl-292867.otenet.gr] has joined #upstart === baze [n=baze@c217110.adsl.hansenet.de] has joined #upstart === phsdv [n=paul@dyn-83-156-79-127.ppp.tiscali.fr] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [02:49] Feb 10 13:49:23 wing-commander init: /etc/event.d/4913: unable to read: Invalid argument [02:49] grr @ vim [02:54] <_ion> :-\ [02:54] it really does write a file called 4913 into the current directory when you modify something [02:54] go figure [02:55] <_ion> Perhaps the directory watching code should do something like "wait one second after things have stopped changing" [02:55] <_ion> and then react [02:55] <_ion> That should take care of any evil things editors might do with temporary files. [02:56] <_ion> The very same feature would be useful in the future when "file/directory changing" can be used as triggers for upstart jobs. [02:57] <_ion> I.e. "watch directory /foo, do this when things have changed and there have been no more changes for 15 seconds" [02:59] yeah, will have to think how to smooth that kind of thing out [02:59] 15s is a long time though [03:00] <_ion> That was just an example of an arbitrary number a user might choose. [03:00] <_ion> Not something we'd want for watching /etc :-) [03:00] <_ion> /etc/event.d even [03:03] it's vaguely useful in many cases [03:03] <_ion> A use case: i define a job that watches www-dir/apt-repo-incoming, and when one *minute* has passed from changes, it copies things to www-dir/apt-repo and runs falcon. I might want this because i manually copy things to it, and want to have up to a minute of time between copying individual files until the thing is actually triggered. [03:03] some editors just modify the file directly [03:03] some copy the file to a backup and modify the file itself [03:03] <_ion> Yeah. [03:03] some write a temporary file, and move it over the previous file [04:45] at some point, I need to rethink the way process ids are stored in the Job [05:32] right now there's just job->pid and job->aux_pid [05:32] I'm temped to move the pid to underneath the process definition [05:33] job->process->pid, job->pre_start->pid, job->post_start->pid, etc. [05:33] and then I could enum those [05:33] job->process[PROCESS_PRE_START] ->pid [05:33] and then we can add arbitrary actions [05:33] id = job_action_id (job, "reload"); [05:33] job->process[id] ->pid === theCore [n=alex@ubuntu/member/theCore] has joined #upstart [05:48] actually, I just found another reason to do that [05:48] then job->failed_state could actually be the *process* that failed :p [06:27] http://rafb.net/p/fOPZlY98.html [06:27] ^ \o/ [07:00] so, here's a poser [07:00] when you change a job's configuration file, should it [07:01] a) modify the configuration of the running job [07:01] b) mark the running job to be deleted when it stops, and use the new configuration for any new instances started later [07:03] is implementing a actually possible? [07:04] a is what is currently implemented [07:04] but I'm increasingly thinking it's wrong [07:04] it works for debugging, "a quick edit to fix the job" [07:04] but I think in practice b is better, because changes to the job file are likely to be upgrades [07:04] and you might end up with a post-stop script that wasn't intended for the running process, since it doesn't match what pre-start did at the time [07:05] silly things, like what if the upgrade changed the pid file location? [07:05] or the run directory location [07:05] that's an issue we have todya [07:05] would be nice to fix it [07:11] <_ion> b sounds good. [07:31] a) seems scary to me. [07:32] it seems to beg for race-conditions [07:34] yeah, like a pre-start script being run; the config file getting read; and a different process all together getting run afterwards === AlexExtreme[T] [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart [08:32] Keybuk: yes, I agree that b would be better === mbiebl [n=michael@e180064209.adsl.alicedsl.de] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart [09:52] Keybuk, just found an upstart bug - if you hit ctrl+alt+del multiple times, it will try to shut down multiple times [09:53] right, yes? [09:53] well, that shouldn't really happen, should it? [09:54] dunno [09:54] change "stop on runlevel" to "stop on runlevel [^6] " [09:54] :p [09:54] :p [10:02] Keybuk: I got a small problem with current svn [10:03] Seems as if kill -s TERM 1 in postinst [10:04] causes upstart to run sulogin (which kills my keyboard on X) [10:17] yes [10:17] it does that [10:19] normally it kills the entire X server [10:21] * WARNING: if you have any job declared "console owner" which is [10:21] run by the "stalled" event, comment out the "start on" stanza [10:21] before sending the TERM signal -- otherwise the newly started [10:21] process will start that job, which will kill your running X [10:21] server. [10:25] Hm, it didn't do that with <=0.3.2 [10:25] Is that a recent change? [10:26] yes [10:26] it's a "lack of a feature" [10:26] I disabled the stuff that serialised the state between upstart instances, because it was a mess and hard to maintain [10:26] I plan to put it back sometime in the couple of releases [10:33] ok [10:39] hey, quicky casper question since I know ya'll know a lot about it. ;) [10:39] Trying to copy the feisty boot CD to a USB drive, to install on a system without a CD. [10:40] filesystem.squashfs is what casper needs to mount... the vmlinuz and initrd.gz are obvious. What option tells casper how to find filesystem.squashfs? [10:40] it hunts for it [10:40] it's in the casper-local initramfs script === wasabi_ installs casper! [10:41] would ideally just be an option to mount a certain efs2 partition with a static path. ... *hopes* [10:41] it might be [10:41] hopefully the initramfs does usb mass storage by default. =/ [10:41] it should [10:42] ./usr/share/initramfs-tools/scripts/casper [10:43] hmm LIVEMEDIA maybe [10:44] it might be fixed as /casper/*.squashfs [10:44] That'll be fine. I just have to be able to point it to /dev/sdb3 [10:44] And it has to wait for it to appear. [10:44] Or... /dev/sd something. [10:44] Actually I won't know. [10:44] it should just fine it [10:44] uh, find it [10:45] # or do the scan of block devices [10:45] it checks all block devices [10:47] bah. grub doesn't like this. prints GRUB and dies. [10:48] wonder how I fix that one. [10:48] ... how does grub find it's stage2 anyways? [10:53] well this is obnoxious. === ..[topic/#upstart:Keybuk] : Upstart 0.3.5 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo [11:02] Odd. So I've got it booted into the initrd... casper breaks... probably can't find the livefs. [11:02] Guess I can just mount it manually. [11:05] nope. blah. [11:13] i've got it at an initramfs prompt though. that's good enough. i'm going on a road trip and at least needed it that far. ;) [11:13] I can do the rest by hand in the car.