[12:31] <_ion> 27C outside. \o/
[02:49] <Keybuk> Feb 10 13:49:23 wing-commander init: /etc/event.d/4913: unable to read: Invalid argument
[02:49] <Keybuk> grr @ vim
[02:54] <_ion> :-\
[02:54] <Keybuk> it really does write a file called 4913 into the current directory when you modify something
[02:54] <Keybuk> 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] <Keybuk> yeah, will have to think how to smooth that kind of thing out
[02:59] <Keybuk> 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] <Keybuk> 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] <Keybuk> some editors just modify the file directly
[03:03] <Keybuk> some copy the file to a backup and modify the file itself
[03:03] <_ion> Yeah.
[03:03] <Keybuk> some write a temporary file, and move it over the previous file
[04:45] <Keybuk> at some point, I need to rethink the way process ids are stored in the Job
[05:32] <Keybuk> right now there's just job->pid and job->aux_pid
[05:32] <Keybuk> I'm temped to move the pid to underneath the process definition
[05:33] <Keybuk> job->process->pid, job->pre_start->pid, job->post_start->pid, etc.
[05:33] <Keybuk> and then I could enum those
[05:33] <Keybuk> job->process[PROCESS_PRE_START] ->pid
[05:33] <Keybuk> and then we can add arbitrary actions
[05:33] <Keybuk> id = job_action_id (job, "reload");
[05:33] <Keybuk> job->process[id] ->pid
[05:48] <Keybuk> actually, I just found another reason to do that
[05:48] <Keybuk> then job->failed_state could actually be the *process* that failed :p
[06:27] <Keybuk> http://rafb.net/p/fOPZlY98.html
[06:27] <Keybuk> ^ \o/
[07:00] <Keybuk> so, here's a poser
[07:00] <Keybuk> when you change a job's configuration file, should it
[07:01] <Keybuk> a) modify the configuration of the running job
[07:01] <Keybuk> b) mark the running job to be deleted when it stops, and use the new configuration for any new instances started later
[07:03] <Md> is implementing a actually possible?
[07:04] <Keybuk> a is what is currently implemented
[07:04] <Keybuk> but I'm increasingly thinking it's wrong
[07:04] <Keybuk> it works for debugging, "a quick edit to fix the job"
[07:04] <Keybuk> but I think in practice b is better, because changes to the job file are likely to be upgrades
[07:04] <Keybuk> 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] <Keybuk> silly things, like what if the upgrade changed the pid file location?
[07:05] <Keybuk> or the run directory location
[07:05] <Keybuk> that's an issue we have todya
[07:05] <Keybuk> would be nice to fix it
[07:11] <_ion> b sounds good.
[07:31] <theCore> a) seems scary to me.
[07:32] <theCore> it seems to beg for race-conditions
[07:34] <Keybuk> yeah, like a pre-start script being run; the config file getting read; and a different process all together getting run afterwards
[08:32] <Md> Keybuk: yes, I agree that b would be better
[09:52] <AlexExtreme> Keybuk, just found an upstart bug - if you hit ctrl+alt+del multiple times, it will try to shut down multiple times
[09:53] <Keybuk> right, yes?
[09:53] <AlexExtreme> well, that shouldn't really happen, should it?
[09:54] <Keybuk> dunno
[09:54] <Keybuk> change "stop on runlevel" to "stop on runlevel [^6] "
[09:54] <Keybuk> :p
[09:54] <AlexExtreme> :p
[10:02] <mbiebl> Keybuk: I got a small problem with current svn
[10:03] <mbiebl> Seems as if kill -s TERM 1 in postinst
[10:04] <mbiebl> causes upstart to run sulogin (which kills my keyboard on X)
[10:17] <Keybuk> yes
[10:17] <Keybuk> it does that
[10:19] <Keybuk> normally it kills the entire X server
[10:21] <Keybuk>         * WARNING: if you have any job declared "console owner" which is
[10:21] <Keybuk>           run by the "stalled" event, comment out the "start on" stanza
[10:21] <Keybuk>           before sending the TERM signal -- otherwise the newly started
[10:21] <Keybuk>           process will start that job, which will kill your running X
[10:21] <Keybuk>           server.
[10:25] <mbiebl> Hm, it didn't do that with <=0.3.2
[10:25] <mbiebl> Is that a recent change?
[10:26] <Keybuk> yes
[10:26] <Keybuk> it's a "lack of a feature"
[10:26] <Keybuk> I disabled the stuff that serialised the state between upstart instances, because it was a mess and hard to maintain
[10:26] <Keybuk> I plan to put it back sometime in the couple of releases
[10:33] <mbiebl> ok
[10:39] <wasabi_> hey, quicky casper question since I know ya'll know a lot about it. ;)
[10:39] <wasabi_> Trying to copy the feisty boot CD to a USB drive, to install on a system without a CD.
[10:40] <wasabi_> 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] <Keybuk> it hunts for it
[10:40] <Keybuk> it's in the casper-local initramfs script
[10:41] <wasabi_> would ideally just be an option to mount a certain efs2 partition with a static path. ...  *hopes*
[10:41] <Keybuk> it might be
[10:41] <wasabi_> hopefully the initramfs does usb mass storage by default. =/
[10:41] <Keybuk> it should
[10:42] <Keybuk> ./usr/share/initramfs-tools/scripts/casper
[10:43] <wasabi_> hmm LIVEMEDIA maybe
[10:44] <Keybuk> it might be fixed as /casper/*.squashfs
[10:44] <wasabi_> That'll be fine. I just have to be able to point it to /dev/sdb3
[10:44] <wasabi_> And it has to wait for it to appear.
[10:44] <wasabi_> Or... /dev/sd something.
[10:44] <wasabi_> Actually I won't know.
[10:44] <Keybuk> it should just fine it
[10:44] <Keybuk> uh, find it
[10:45] <wasabi_> # or do the scan of block devices
[10:45] <Keybuk> it checks all block devices
[10:47] <wasabi_> bah. grub doesn't like this. prints GRUB and dies.
[10:48] <wasabi_> wonder how I fix that one.
[10:48] <wasabi_> ... how does grub find it's stage2 anyways?
[10:53] <wasabi_> well this is obnoxious.
[11:02] <wasabi_> Odd. So I've got it booted into the initrd... casper breaks... probably can't find the livefs.
[11:02] <wasabi_> Guess I can just mount it manually.
[11:05] <wasabi_> nope. blah.
[11:13] <wasabi_> 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] <wasabi_> I can do the rest by hand in the car.