[02:57] <jiger> hello how can I check if I am booting via upstart or no?
[02:57] <cortana> jiger: check /proc/1/exe ?
[02:58] <jiger> there is no /proc/1/exe
[02:59] <jiger> top shows 1 as init
[02:59] <cortana> then you're not using linux... perhaps you don't have permission to read it, i seem to only be able to read it if i am root
[03:00] <jiger> ohhh wait only works with sudo. hmmmm but ls shows nothing
[03:00] <jiger> wonder why booting kubuntu takes so long
[03:01] <jiger> cortana: and why is process 1 init?
[03:02] <cortana> well it's a symlink to a processes' executable file
[03:02] <cortana> it guess it depends how you have upstart installed
[03:02] <cortana> maybe it has replaced the /sbin/init file
[03:04] <jiger> cortana: but isn't upstart executable called upstart?
[03:05] <cortana> depends how you have it installed
[03:05] <jiger> cortana: any definitive way to check>
[03:05] <cortana> i don't even have it installed here :)
[03:05] <cortana> ask your package manager what owns the file?
[03:05] <jiger> cortana: I did a dapper to edgy
[03:05] <jiger> cortana: u ain't running ubuntu?
[03:05] <jiger> cortana: command?
[03:06] <cortana> dpkg --search i think
[03:07] <jiger> upstart-compat-sysv: /usr/share/doc/upstart-compat-sysv
[03:07] <jiger> system-services: /usr/lib/upstart/migrate-inittab.pl
[03:07] <jiger> upstart-logd: /usr/share/doc/upstart-logd
[03:07] <jiger> upstart: /usr/share/doc/upstart/copyright
[03:07] <jiger> upstart: /usr/share/doc/upstart
[03:07] <jiger> upstart: /usr/share/doc/upstart/changelog.gz
[03:07] <jiger> upstart: /usr/share/doc/upstart/NEWS.gz
[03:07] <jiger> upstart: /usr/share/doc/upstart/AUTHORS
[03:07] <jiger> upstart: /usr/share/doc/upstart/changelog.Debian.gz
[03:07] <jiger> system-services: /usr/lib/upstart
[03:07] <jiger> upstart: /usr/share/doc/upstart/README.Debian.gz
[03:07] <jiger> strikes anything?
[03:08] <cortana> it's dpkg --search /sbin/init
[03:08] <cortana> to find out what package owns /sbin/init
[03:09] <jiger> upstart: /sbin/init
[03:09] <jiger> good? ontrack?
[03:09] <cortana> then it seems you are using upstart
[03:09] <jiger> cortana: then wonder why it is so slow to boot
[03:10] <cortana> afaik upstart doesn't make anything aster
[03:10] <cortana> *faster
[03:10] <jiger> cortana: slightly slower than dapper
[03:10] <cortana> but i can't really say since i don't use it
[03:10] <jiger> cortana:  doesn't it load possible services in parellel ?
[03:10] <jiger> cortana: might not be immen. but in future aim?
[03:11] <cortana> maybe, but if those services are both competing for the same resource then they won't load any quicker
[03:11] <jiger> cortana: hmmm hope next ubuntu makes it fast.
[03:11] <jiger> cortana: thanks for the help
[06:27] <madduck> Keybuk: http://www.metager2.de/ -- Michael Biebl is now the maintainer for Debian and I suggest you link to http://packages.debian.org/upstart instead as the package won't be experimental forever.
[06:27] <Keybuk> thanks
[06:27] <madduck> oops
[06:27] <madduck> http://upstart.ubuntu.com/
[06:27] <madduck> i mean.
[06:27] <madduck> you can keep me in if youw ant, i am comaintainer...
[06:27] <madduck> (though i have not done much)
[06:28] <Keybuk> *nods*
[06:30] <AlexExtreme> Keybuk: you busy atm with uds-mtv or can I ask a quick question?
[06:32] <AlexExtreme> oh, nvm, just got some of your emails on the mailing list - my mail server is a bit laggy today
[06:38] <Keybuk> AlexExtreme: you can always ask questions :)
[06:38] <Keybuk> I just may not reply instantly
[06:38] <AlexExtreme> ok :)
[06:39] <Keybuk> what was your question?
[06:39] <AlexExtreme> well, just a quick (and stupid - /me points at crazy (another frugalware devel) ;)) question - will hal ever be needed by upstart?
[06:40] <Keybuk> I suspect HAL will become an important source of events
[06:40] <Keybuk> as unlike udev, it has policy
[06:40] <Keybuk> udev can give you a "a block device has been added"
[06:40] <AlexExtreme> but not actually *required*, meaning you could run upstart without it?
[06:40] <Keybuk> HAL can give you "a block device ON A DIGITAL CAMERA has been added"
[06:40] <Keybuk> right
[06:41] <AlexExtreme> good
[06:41] <Keybuk> very little of upstart will be required
[06:41] <Keybuk> just the /sbin/init daemon and some IPC mechanism to send events to it
[06:41] <Keybuk> other than that, everything else will be optional
[06:41] <AlexExtreme> k
[06:41] <AlexExtreme> crazy: there, got your question answered
[06:41] <AlexExtreme> :)
[06:41] <Keybuk> hmm?
[06:42] <AlexExtreme> crazy wanted me to ask that
[06:42] <Keybuk> ahh
[06:43] <Keybuk> on the dbus thing
[06:43] <Keybuk> I'm still debating the custom IPC vs. dbus thing
[06:44] <AlexExtreme> ok
[06:44] <AlexExtreme> bbl, food
[06:44] <mbiebl> Keybuk: did you advise Md to reassign the udev problem in Debian to upstart-compat-sysv?
[06:45] <Keybuk> mbiebl: yes
[06:45] <Keybuk> both the problems are definitely upstart
[06:45] <Keybuk> in Debian, I'd argue that you need "console owner" in the compat-sysv jobs; simply because Debian doesn't have a "no boot messages" policy, so init scripts are well within their rights to expect stdin=/dev/console
[06:46] <Keybuk> also there's definitely a bug that the rcS job doesn't set RUNLEVEL or PREVLEVEL (note that rc-everything-else does :p)
[06:46] <mbiebl> Sure, we don't have that policy, but that doesn't mean that it doesn't make sense to have everything logged to file instead to stdout
[06:46] <Keybuk> right, but it's also inherently not a udev bug
[06:46] <Keybuk> you're well within your rights to reject it
[06:46] <mbiebl> ;-)
[06:47] <mbiebl> The problem with console owner is, that it makes logd pretty useless.
[06:47] <Keybuk> right
[06:48] <Keybuk> needs improvement
[06:48] <AlexExtreme> Yes, I pointed that out on upstart-devel. /var/log/boot contains nothing then
[06:48] <AlexExtreme> maybe I should try improving it for something to do? ;)
[06:48] <AlexExtreme> anyway, gotta go
[06:48] <mbiebl> Keybuk: you know, I want to give the user the choice, if they want verbose output or not.
[06:48] <Keybuk> mbiebl: *nods*
[06:48] <mbiebl> So imho udev needs this "fix"
[06:49] <Keybuk> md is well within his rights to refuse the fix
[06:49] <mbiebl> Well, I guess I'll just ask Md to add " -o $TTY /dev/null" to his am_i_interactive check.
[06:49] <Keybuk> *nods*
[06:49] <Keybuk> that may be a good compromise
[06:49] <Keybuk> talk to him about it
[06:50] <Keybuk> Marco responds very well to conversation through medium other than the BTS
[06:50] <mbiebl> hehe
[06:51] <mbiebl> What about cryptsetup, how do solve that in ubuntu?
[06:51] <mbiebl> exec <1>2 /dev/console ?
[06:56] <mbiebl> I mean: exec </dev/console >/dev/console 2>&1?
[06:56] <mbiebl> Seems a bit "hackish" to add that to a dozen of init scripts.
[06:57] <mbiebl> Wouldn't it be better to have something like input/output functions, which forward the request to upstart instead of doing the input/output itself.
[06:58] <mbiebl> Would something like that be possible.
[06:59] <_ion> They should support a splash program as well.
[06:59] <mbiebl> _ion: yes, it wouldn't matter how this information is presented.
[06:59] <_ion> I don't think upstart needs to know about them, though.
[07:08] <mbiebl> Keybuk: what are your top priorities for upstart in the near future?
[07:09] <mbiebl> I wanted to "convert" existing init scripts and noticed that "pid file" and "multiple events" support are needed for a lot of services.
[07:11] <mbiebl> I hacked together some kind of pid file support, which works most of the time.
[07:12] <mbiebl> But it's rather hard to do that right.
[07:27] <cortana> ugh, i thought one of the advantages of upstart is to do away with pidfiles?
[07:32] <mbiebl> cortana: there are still services which don't deal well with being started in foreground.
[07:32] <mbiebl> They have to be tracked somehow. Most of them write pid files.
[07:32] <_ion> Use the "daemon" stanza
[07:35] <mbiebl> _ion: this only works, if the "daemon" does not fork and detach.
[07:36] <_ion>                 /* daemon (WS <command>)?
[07:36] <_ion>                  * indicates that the process forks into the background
[07:36] <_ion>                  * so we need to grovel for its process id
[07:38] <mbiebl> _ion: try it, you'll see that it doesn't work for daemon's which fork
[07:38] <_ion> Then it has a bug, which should be fixed.
[07:39] <mbiebl> Is it even possible for upstart to determine the pid of the forked process?
[07:39] <mbiebl> I dunno.
[07:42] <mbiebl> How should it be done? By traversing /proc checking for a process with the same name as the binary specified in the upstart job file?
[07:43] <mbiebl> Wouldn't work reliably imo.
[07:44] <AlexExtreme> yeah, i mean, what if the daemon changes the process title or forks itself into multiple processes
[07:45] <mbiebl> AlexExtreme: exactly.
[07:46] <_ion> keybuk: Could you share your insight on the issue?
[07:50] <_ion> IIRC it has something to do with pid 1 getting SIGCHLD for parentless processes.
[07:54] <mbiebl> _ion: hm, ok. but take hald e.g. which spawns several sub processes.
[07:54] <mbiebl> How do you know, which one is the controlling daemon.
[07:55] <_ion> I haven't studied how upstart handles or is supposed to handle that.
[07:55] <_ion> Let's wait for Keybuk's answer. :-)
[08:12] <Keybuk> mbiebl: input/output functions are the expected way to do it
[08:12] <Keybuk> then we can provide implementations that deal with console, usplash, text-to-speech, braille, etc.
[08:12] <Keybuk> mbiebl: current list in my head is
[08:12] <Keybuk> 1. fix the IPC stuff
[08:12] <Keybuk> 2. implement the events changes we've talked about
[08:13] <Keybuk> 3. multiple events, optional events
[08:13] <Keybuk> 4. event completion notification
[08:13] <Keybuk> 5. job changes we've talked about
[08:13] <Keybuk> 6. temporal jobs
[08:13] <Keybuk> 7. user jobs
[08:14] <Keybuk> and, on pid location, the idea is that you spawn the daemon
[08:14] <Keybuk> and then look for either the /proc/*/exe matching "pid binary"
[08:14] <Keybuk> or the "pid file" file which should contain the pid
[08:14] <Keybuk> we get SIGCHLD for these later
[08:15] <sladen> it would certainly be more consistent if upstart does the handling of pid saving
[08:17] <mbiebl> Regarding the /proc/*/exe matching: How would you handle e.g. sshd?
[08:17] <mbiebl> It spawns several sub processes for each connected user and you certainly don't want to kill the wrong pid ;-)
[08:18] <Keybuk> sladen: this is for processes that fork
[08:19] <Keybuk> mbiebl: first one
[08:19] <Keybuk> you only locate the pid once
[08:19] <Keybuk> then again, sshd would be run with -D
[08:19] <mbiebl> But what if you start multiple instances of a daemon.
[08:20] <mbiebl> (SSH on prt 24 and 22 e.g.)
[08:21] <_ion> I thought you can set both in sshd_config.
[08:22] <madduck> you can
[08:22] <madduck> you might want to have different settings though
[08:22] <mbiebl> But I guess most daemons either write pid files are can be run properly in foreground.
[08:22] <madduck> my port 22 sshd never allows root access.
[08:22] <mbiebl> So this option is not that important.
[08:22] <madduck> i have an sshd allowing without-password on a port that changes often
[08:24] <_ion> Btw, instances of sshd spawned for logged-in users have the initial sshd as their parent.
[08:27] <mbiebl> Md: hi
[08:30] <Keybuk> indeed, it's only the multiple-daemon-that-pid-is-1 that's a problem