[12:49] <Keybuk> hmm
[12:49] <Keybuk> so "status foo", pretty obvious that should return one entry for a normal job
[12:50] <Keybuk> and I think it's correct to return a list of jobs for an instance job
[12:54] <Keybuk> but should it also return the "master" job, which would always be stop/waiting
[12:54] <Keybuk> or should I have a special message for an instance job list
[05:38] <AlexExtreme> heh
[05:38] <AlexExtreme> "Do not stand directly in front of this door."
[05:38] <AlexExtreme> well do you expect blind people to read it without going up to it? :p
[05:39] <Keybuk> that was my point :p
[05:39] <AlexExtreme> yeah i know ;)
[06:12] <Mithodin> Hello
[08:13] <AlexExtreme> why's that?
[08:14] <Keybuk> initctl is turning out to be rather simpler with the new IPC messages
[08:14] <AlexExtreme> cool
[08:33] <mbiebl> Keybuk: I wanted to prepare a 0.3.5 release for experimental today. 
[08:34] <mbiebl> Got a couple of questions
[08:34] <Keybuk> sure
[08:34] <mbiebl> Is console logged still unsafe?
[08:35] <Keybuk> it's still disabled yeah, I haven't touched logd any further yet
[08:35] <Keybuk> the problem is the bad behaviour of just about every app when they can't write to stdout
[08:35] <mbiebl> ok, then I'll better also use console output then.
[08:36] <mbiebl> The next issue is rc0-poweroff/rc0-halt, which were obsoleted.
[08:36] <Keybuk> haven't traced it further; can't see why they terminate, rather than just ignore it
[08:36] <Keybuk> yes
[08:36] <Keybuk> since we can transfer environment variables in an event, it made more sense for shutdown itself to set INIT_HALT, just as it did with sysvinit
[08:37] <mbiebl> You seem to backup them to dpkg-bak if they were modified in preinst. Why not just remove it?
[08:38] <Keybuk> general "don't remove other people's modified conffiles" behaviour
[08:38] <mbiebl> You also delete the unmodified ones in preinst, so they are still recorded as installed by dpkg
[08:38] <Keybuk> that's a dpkg bug
[08:38] <Keybuk> older dpkg behaves correctly
[08:38] <Keybuk> there's currently no way to remove a conffile without it still showing up in dpkg -L
[08:39] <Keybuk> even if it's not shipped in the current version of a package
[08:39] <mbiebl> I tried it that way:
[08:39] <mbiebl> mv the modified ones in preinst to .dpkg-bak, the unmodified ones to .dpkg-remove
[08:39] <mbiebl> Remove .dpkg-remove files in postinst.
[08:40] <mbiebl> If upgrade fails, restore .dpkg-bak and .dpkg-remove files back.
[08:40] <mbiebl> (abort-upgrade in postinst)
[08:42] <Keybuk> how does that change it?
[08:42] <Keybuk> dpkg still records the conffile, no?
[08:42] <mbiebl> no, it doesn't
[08:42] <Keybuk> ahh
[08:42] <Keybuk> interesting
[08:43] <Keybuk> that's changed recently then
[08:43] <Keybuk> shiny
[08:43] <Keybuk> I'll update my functions accordingly
[08:43] <mbiebl> It also restores the state completely on an aborted upgrade.
[08:44] <mbiebl> If I rmmed the unmodified ones in preinst that wouldn't be possible.
[08:44] <Keybuk> I rm them in postinst, no?
[08:45] <mbiebl> Yes.
[08:45] <Keybuk> the recipe always used to be:
[08:46] <Keybuk>   in preinst, move to dpkg.bak if modified, leave alone if not
[08:46] <Keybuk>   in postinst, remove if still exists
[08:46] <Keybuk>   in postrm abort-upgrade, rename .dpkg-bak back to the conffile
[08:46] <Keybuk> -- 
[08:46] <Keybuk> so what happens there is the conffile is in place when the package is upgraded, so dpkg notes it in status as an obsolete
[08:47] <Keybuk> looks like dpkg has been fixed so dpkg actually stats the file, and doesn't note a missing file as obsolete now
[08:47] <Keybuk> so the recipe should be:
[08:47] <Keybuk>   in preinst, move to .dpkg-bak if modified, .dpkg-remove if not
[08:47] <Keybuk>   in postinst, remove .dpkg-remove if it exists
[08:47] <Keybuk>   in postrm abort-upgrade, rename .dpkg-bak or .dpkg-remove back to the conffile
[08:47] <Keybuk> yes?
[08:48] <mbiebl> yeah, that's what I do currently.
[08:48] <mbiebl> I just wanted to hear your thoughts on this, if you think this is the correct way (tm) to do it.
[08:48] <Keybuk> that makes perfect sense
[08:49] <mbiebl> I really hoped dpkg would be a bit more clever in that regard.
[08:49] <mbiebl> And did that automatically.
[08:50] <Keybuk> :D
[08:50] <Keybuk> note a bug in the Ubuntu upstart package
[08:50] <Keybuk> migrate-inittab generates the wrong runlevel event names
[08:52] <mbiebl> I haven't synced this feature into the Debian postinst (yet)
[08:53] <Keybuk> *nods*
[08:53] <Keybuk> btw, woooooo shiny:
[08:53] <Keybuk> wing-commander util% sudo ./initctl start tests/foo 
[08:53] <Keybuk> tests/foo (start) waiting
[08:53] <Keybuk> tests/foo (start) starting
[08:53] <Keybuk> tests/foo (start) pre-start
[08:53] <Keybuk>         pre-start process 2533
[08:53] <Keybuk> tests/foo (stop) pre-start
[08:53] <Keybuk> tests/foo (stop) stopping
[08:53] <Keybuk> tests/foo (stop) killed
[08:53] <Keybuk> tests/foo (stop) post-stop
[08:53] <Keybuk> tests/foo (stop) waiting
[08:54] <Keybuk> initctl: tests/foo pre-start process killed by SEGV signal
[08:54] <Keybuk> -- 
[08:54] <Keybuk> start blocks until the job is running/finished, and returns an error if the job failed, and outputs all the interim process states
[08:55] <mbiebl> oh, I remember another issue: postinst/purge
[08:55] <mbiebl> I added a call to remove .dpkg-bak there.
[08:55] <Keybuk> hmm, interesting
[08:55] <Keybuk> hadn't previously considered that
[08:55] <Keybuk> does dpkg remove modified configuration files on purge?
[08:56] <mbiebl> yes, that's why I added it
[08:56] <mbiebl> To be compliant with dpkg's behaviour
[08:58] <Keybuk> *nods*
[08:58] <Keybuk>  tests/foo (start) post-start
[08:58] <Keybuk>         main process 2865
[08:58] <Keybuk>         post-start process 2866
[08:58] <Keybuk> \o/
[09:00] <mbiebl> Does that mean, I could start a daemon in (pre|post)-(start|stop) (and have it monitored/respawned)?
[09:00] <Keybuk> no, upstart wouldn't know the process id
[09:01] <Keybuk> Mar  5 19:59:52 wing-commander init: Caught segmentation fault, core dumped
[09:01] <Keybuk> Mar  5 20:00:23 wing-commander last message repeated 19073 times
[09:01] <Keybuk> Mar  5 20:01:24 wing-commander last message repeated 33310 times
[09:01] <Keybuk> oops
[09:06] <AlexExtreme> Keybuk, that looks bad ;)
[09:13] <Keybuk> AlexExtreme: yeah, haven't figured out a way to dump core *and* get over the problem instruction yet
[09:13] <Keybuk> so when it SEGVs, it basically ends up in an infinite loop writing core to the disk
[09:13] <AlexExtreme> yes
[09:14] <AlexExtreme> so basically it needs to stop calling the function that's causing the SEGV if possible?
[09:14] <Keybuk> right, but how do you do that?
[09:14] <Keybuk> the function has probably altered state
[09:15] <Keybuk> so you have no idea whether the global state is consistent
[09:15] <Keybuk> you may have a job that has dangling pointers into the nether
[09:15] <Keybuk> so you can't carry on, because you'll just dump core again
[09:15] <AlexExtreme> yep :/
[09:15] <Keybuk> and you can't even reexec and transfer your state, because you could dump core while reexecing
[09:15] <Keybuk> the best solution so far is to reexec without transfering state
[09:15] <Keybuk> which will cause X to crash :p
[09:15] <AlexExtreme> :)
[09:15] <Keybuk> but I figure X crashing is better than nothing
[09:16] <AlexExtreme> yes
[09:25] <Keybuk> brb, need to SUB
[09:30] <Keybuk> right
[09:30] <Keybuk> better
[09:31] <Keybuk> that works actually
[09:31] <Keybuk> SEGV'ing init might crash X
[09:31] <Keybuk> but apport catches it
[09:31] <Keybuk> so you get a friendly explanation *why* and can click to file a bug
[09:32] <Keybuk> which is nice
[09:34] <Keybuk> wing-commander util# ./initctl status tests/inst
[09:34] <Keybuk> tests/inst (instance)
[09:34] <Keybuk> wing-commander util# ./initctl start -n tests/inst
[09:34] <Keybuk> wing-commander util# ./initctl start -n tests/inst
[09:34] <Keybuk> wing-commander util# ./initctl start -n tests/inst
[09:34] <Keybuk> wing-commander util# ./initctl status tests/inst  
[09:34] <Keybuk> tests/inst (instance)
[09:34] <Keybuk>     (start) running
[09:34] <Keybuk>     (start) running
[09:34] <Keybuk>     (start) running
[09:34] <Keybuk> ^ do we like that as a method for reporting instance jobs?
[09:40] <Keybuk> (and stop tests/inst stops every single instance)
[10:03] <AlexExtreme> Keybuk, looks good
[10:04] <Keybuk> needs some cleaning up, and testing but I'm pretty happy with it