[02:28] <mbiebl> Keybuk, hi
[02:29] <Keybuk> ello
[02:30] <mbiebl> I currently studying the code and noticed, that "pid file" does not yet have any effect.
[02:31] <mbiebl> init/job.c -> job_run_process always uses the pid returned from fork.
[02:33] <mbiebl> If job->pidfile is specified it should parse the given file for the pid file instead.
[02:33] <mbiebl> I also don't understand, why "pid file" can only be specified together with respawn.
[02:34] <Keybuk> right, it's not implemented
[02:34] <mbiebl> Imho it would also make sense together with exec.
[02:34] <Keybuk> was supposed to only make sense with daemon :p
[02:34] <mbiebl> Yeah, but a daemon can also be started with exec, or not?
[02:34] <Keybuk> yes
[02:35] <mbiebl> I also think, that a reload and maybe also a restart utility would be great.
[02:35] <Keybuk> there's no implementation for reload yet
[02:36] <mbiebl> It should also be possible to specify in the job description file a custom reload function.
[02:37] <Keybuk> probably yes
[02:37] <Keybuk> actions are in the todo somewhere
[02:37] <Keybuk> got to get events and jobs right first though
[02:37] <mbiebl> Sure ;-)
[02:38] <mbiebl> Oh, another thing, more from the packaging perspective:
[02:38] <mbiebl> in postinst you call kill directly. Maybe it would be safer to specify the complete path as kill is a bash builtin
[02:38] <mbiebl> iirc lintian also moans about that.
[02:39] <Keybuk> why would you need to do that?
[02:39] <Keybuk> what's wrong with the builtin?
[02:39] <mbiebl> They could behave differently and you don't notice as long as you run bash.
[02:39] <Keybuk> they'd at least behave consistently
[02:39] <Keybuk> it's /bin/sh
[02:39] <Keybuk> so kill must behave like POSIX kill
[02:40] <Keybuk> kill -TERM 1 is therefore legal
[02:40] <mbiebl> Is it guaranteed that the bash builtin kill behaves exactly as /bin/kill?
[02:40] <mbiebl> I'm not sure.
[02:40] <Keybuk> yes
[02:40] <Keybuk> what's bash got to do with it anyway?
[02:40] <Keybuk> /bin/sh on Ubuntu is dash
[02:42] <mbiebl> Well, if the builtin and /bin/kill behave exactly the same, then the point is moot.
[02:42] <Keybuk> indeed
[02:43] <mbiebl> You seem confident so I take this point as resolved ;-)
[02:43] <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
[02:43] <Keybuk> if the user replaces /bin/sh with a non-POSIX shell like zsh, and complains; then the bug can just be rejected :p
[02:46] <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.
[02:46] <Keybuk> not in edgy
[02:48] <Keybuk> beta freeze is only a few days away! :P
[02:48] <Keybuk> and have other bugs to be fixed for that
[02:55] <mbiebl> yeah, bug fixing should always have top priority, even if it's not so much fun :-)
[02:56] <Keybuk> fortunately there don't seem to be any upstart bugs
[03:01] <mbiebl> That speaks for your coding skills
[03:02] <Keybuk> well, no major ones anywhere
[11:19] <Admiral_Chicago> i'm on Knot 3 and i did an apt-get update
[11:19] <Admiral_Chicago> initscript is a package that is being updated
[11:19] <Admiral_Chicago> is that right?
[01:27] <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. =)
[01:27] <jbailey> 2) In single user mode, terminal type seems to be not set correctly, and "reboot" command didn't work.
[01:27] <jbailey> Although from a command prompt now, C-M-Del seems to get registered correctly now.
[01:31] <Keybuk> jbailey: isn't glibc supposed to work unconfigured? :)
[01:32] <Keybuk> hmm, will test the single user mode thing
[01:32] <Keybuk> reboot should work even better than sysvinit (no pesky "unable to obtain runlevel" type thing)
[01:32] <jbailey> Keybuk: It does.  It was that the postinst I think HUPs pid 1 or something like that.
[01:32] <jbailey> Keybuk: So I killall'd that, then dpkg --force-depends -i upstart*deb
[01:32] <jbailey> Reboot, finished upgrade ;)
[01:32] <Keybuk> oh, and you had the hack'd upstart that didn't work? :p
[01:33] <pepsiman> Keybuk: single user doesn't run bash
[01:33] <jbailey> Right. =)
[01:34] <Keybuk> pepsiman: err, yes?
[01:34] <pepsiman> it did in dapper
[01:34] <Keybuk> actually it ran sulogin in dapper ;)
[01:34] <pepsiman> yes, and sulogin looked at /etc/passwd in dapper
[01:34] <Keybuk> right
[01:34] <Keybuk> can probably hack that
[01:35] <Keybuk> or just use the real sulogin
[01:35] <pepsiman> bug 60965
[01:35] <jbailey> Keybuk: Path of least resistance: use the real sulogin.
[01:35] <Keybuk> pepsiman: yes, I saw it
[01:35] <jbailey> Solve that problem sometime in +1 =)
[01:35] <Keybuk> jbailey: yeah, was planning to move that to sysvutils too, just hadn't got around to it yet
[01:35] <Keybuk> was gonna do that along with fixing check*
[01:36] <jbailey> Cool.
[01:37] <jbailey> So for ppc64, I think it's properly cooked now.  I should test on the older kernel as well, I s'pose.
[01:37] <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.
[01:39] <Keybuk> jbailey: oh, I see why shutdown doesn't work in single-user mode
[01:40] <jbailey> Keybuk: Cool.  Need something in Malone, or is this good enough?
[01:40] <Keybuk> not sure it's actually fixable :-/
[01:40] <Keybuk> not for edgy, anyway
[01:40] <jbailey> Err...
[01:40] <jbailey> Need to have *some* way of getting back to a full state.
[01:40] <jbailey> exit didn't work either, IIRC
[01:41] <Keybuk> exit should work
[01:41] <Keybuk> it's making exit work that's causing shutdown to not work
[01:41] <Keybuk> oh, hmm
[01:41] <Keybuk> exit doesn't work either
[01:41] <Keybuk> meh
[01:41] <Keybuk> yes, bug me
[01:41] <jbailey> Two bugs or one?
[01:42] <Keybuk> only one of them will be fixable
[01:42] <Keybuk> reboot is more important, so I'll fix that
[01:44] <pepsiman> init: sulogin process (3353) killed by signal 9
[01:44] <pepsiman> System halted.
[01:47] <Keybuk> hmm? poweroff shouldn't get killed?
[01:48] <pepsiman> that was the 4th attempt at poweroff
[01:48] <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"
[01:49] <pepsiman> how did sysvinit tell the difference?
[01:49] <Keybuk> runlevel change
[01:50] <pepsiman> ah
[01:51] <Keybuk> it's a bug, or at least a lack of an implementation in upstart that causes this bug
[01:51] <Keybuk> but it's not something I can implement before Beta Freeze
[01:51] <jbailey> Keybuk: rewind a sec for me?  what kills sulogin with a signal?
[01:51] <Keybuk> which is IN THREE DAYS TIME
[01:51] <Keybuk> PANIC!!!!
[01:51] <jbailey> Is that a sideeffect of runlevel change?
[01:51] <Keybuk> jbailey: sendsigs ;)
[01:51] <Keybuk> and killing sulogin forces a runlevel change, stopping the running reboot
[01:51] <jbailey> Oh.  Weird design.
[01:52] <Keybuk> well, how would you have done it?
[01:54] <jbailey> I'm not sure. =)
[01:54] <Keybuk> I couldn't remember what happened with sysvinit if you ran telinit from the shutdown process :p
[02:37] <theCore> upstart is so boring... there is barely any bugs to find :)
[02:41] <mbiebl> Keybuk: debian/control: system-services: Is there a reason why you explicitely depend on util-linux?
[02:41] <mbiebl> util-linux is essential, so it shouldn't be necessary to add this dep.
[02:45] <Keybuk> I don't remember, no
[02:48] <mbiebl> Would make one lintian error less.
[02:49] <Md> mbiebl: are there any news about the sysvinit split?
[02:53] <Keybuk> heh, I entirely got out of the habit of running lintian when I was maintaining dpkg
[02:53] <Keybuk> don't think I've ever used it since
[02:53] <mbiebl> Md: It's currently sitting in NEW.
[03:07] <Keybuk> jbailey: looks like there's already a bug for the single-user problem
[09:02] !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!