[00:27] <Keybuk> mbiebl: the shutdown messages are normal
[00:27] <Keybuk> that's unrelated
[00:27] <Keybuk> at -> atd - good catch
[00:27] <Keybuk> udev-finish - good catch
[00:28] <Keybuk> the directly after upgrade stuff isn't ideal
[00:28] <Keybuk> not sure why you have a running dbus though
[00:28] <Keybuk> but it's because those are services are can't shutdown, so we can't "inherit" them
[00:28] <Keybuk> they're still running under sysv conditions until you reboot
[01:23] <mbiebl> Keybuk: I'd also suggest to remove dbus-reconnect.conf and run telinit q in dbus.conf's post-start
[02:23] <Keybuk> mbiebl: doesn't work ;)
[02:25] <ion> Why is that?
[02:29] <Keybuk> because telinit q reloads all the configs
[02:29] <Keybuk> and throws away the accumulated "start on" events ;)
[02:29] <Keybuk> it was a bad choice for dbus reload, in hindsight
[02:30] <ion> So, there should be a way to tell Upstart just to reconnect to dbus?
[02:30] <Keybuk> yes
[03:39] <ion> keybuk: rc-sysinit starts again if one runs mountall from a system that has already booted up. Any way to fix that?
[03:40] <ion> The job starts running rcS scripts
[04:11] <ion> keybuk: Why is anacron a task?
[06:35] <PuffTheMagic> can someone point me to some docs on what events i can emit
[06:36] <PuffTheMagic> like how do i start stop services
[06:36] <PuffTheMagic> using initctl emit
[06:37] <PuffTheMagic> or like... cant i get a list of services this way?
[06:39] <mbiebl> ion: anacron is not a daemon
[06:40] <mbiebl> It's triggered by cron (and other event sources)
 and throws away the accumulated "start on" events ;)
[06:43] <mbiebl> Do you intend to approach it differently then or keep the current solution?
[13:33] <ion> mbiebl: Ah. In that case, ‘task’ is right, but something else must be done to prevent ‘start anacron’ from blocking for ages, especially during the installation of the package.
[13:39] <Keybuk> oh, is that what it's doing?
[13:39] <Keybuk> hah
[13:39] <ion> to053953 < ion> keybuk: rc-sysinit starts again if one runs mountall from a system that has already booted up. Any way to fix that?
[13:39] <ion> to054029 < ion> The job starts running rcS scripts
[13:40] <Keybuk> no, I mean anacron
[13:41] <ion> I mean, that’s another issue i talked to you about.
[13:41] <Keybuk> oh
[13:41] <Keybuk> Don't Do That Then
[13:41] <ion> Hehe
[13:42] <Keybuk> mountall will emit events like filesystem, which will start other bits
[13:42] <ion> Indeed
[13:42] <Keybuk> I guess rc-sysinit should have "start on startup and filesystem"
[13:42] <Keybuk> because it should be only run-once
[13:45] <ion> I think there’s a slight design problem with my fsck-queue patch. I’m just installing a virtual system to test. If there’s a LVM VG that resides on /sda1 *and /sda2, the code will probably output {"8:0", "8:0", NULL} which then will get both locked (i.e. added to the lock hash).
[13:46] <ion> That is, i’ll have to make the get-physical-dev-ids code not output duplicates.
[13:52] <Keybuk> *nods*
[14:43] <Keybuk> mbiebl: you were saying something about /forcefsck not working ?
[14:44] <keesj> so anybody has a good dbus-deamon starting service?(that waits for the service to be started?)
[14:44] <Keybuk> keesj: ?
[14:45] <Keybuk> not sure what you mean
[14:45] <keesj> something that checks if the daemon is ready 
[14:45] <Keybuk> you don't need to
[14:46] <keesj> I need to sue fork for that?
[14:46] <Keybuk> right, "expect fork" and "exec dbus-daemon --system --fork" are sufficient
[14:47] <keesj> thanks
[14:48] <Md> Keybuk: I have noticed myself as well that /forcefsck does not work since I switched to upstart
[14:48] <ion> Ah, Mount *mnt isn’t nih_alloc’ed. No wonder it segfaulted. :-P
[14:58] <sadmac2> Keybuk: Yesterday you said that in the expression on foo started that started was a sub-state of foo (or sub-job or whatever)?
[14:58] <sadmac2> Keybuk: I was wondering if you'd thought of a way to create more of these sub-states
[14:58] <sadmac2> in terms of syntax etc.
[15:00] <Keybuk> syntax is the wishy bit
[15:00] <Keybuk> but yes, you can create them
[15:00] <Keybuk> you can also create them deliberately inside logs
[15:00] <Keybuk> err inside jobs
[15:00] <Keybuk> e.g. apache logrotate
[15:01] <keesj> I have an other meta physical question, suppose I have a dbus server that I want to launch using dbus activation, would'nt it be nice if is wat a upstart server?
[15:01] <keesj> service
[15:02] <Keybuk> yes
[15:02] <keesj> (so I have respawn and such)
[15:02] <Keybuk> it's relatively trivial to patch d-bus to use Upstart to start services
[15:03] <sadmac2> Keybuk: heres a few thoughts then: Suppose the existence of a stanza called "exclude" which takes as its argument a few sub-states. It prevents those sub-states from being true at the same time
[15:04] <Keybuk> why would you want that?
[15:04] <Keybuk> and how would such a thing be resolved?
[15:04] <sadmac2> Keybuk: if you tried to start one state it would stop any of the others in the list
[15:04] <sadmac2> Keybuk: the "why" I'm getting to :)
[15:04] <Keybuk> isn't that the same as "while not <state>" ?
[15:04] <Keybuk> starting that implies that <state> has to be stopped
[15:05] <Keybuk> (for the same reason that starting "while <state>" implies that <state> has to be started)
[15:05] <sadmac2> Keybuk: for two states yes. for N or more its a bit more difficult. Plus this is a push maneuver. It implicitly /makes/ it true
[15:05] <Keybuk> assuming you're talking about the physical "start" command
[15:05] <Keybuk> which is the only case where we want that kind of behaviour
[15:05] <Keybuk> I don't think we ever want auto behaviour like that
[15:06] <sadmac2> Keybuk: ah, but we do, let me continue
[15:06] <Keybuk> could you explain on the ML?
[15:06] <Keybuk> I'm really busy at the moment
[15:06] <sadmac2> Keybuk: sure. It'll be out of context there since we started the discussion here, but that's our fault to begin with anyway :)
[15:07] <Keybuk> you can provide context ;)
[15:09] <sadmac2> Keybuk: not to mention I'll see you in two weeks anyway :)
[15:19] <Keybuk> indeed
[15:34] <ion> keybuk: Okay, now everything seems to work – i have tested the fsck queue as well (in a virtual machine). Patches updated.
[15:35] <Keybuk> awesome
[15:36] <ion> Actually, i just noticed a missing nih_assert that should be there. Patches updated again. :-P
[15:36] <Keybuk> ion: can you get rid of the LIKELY/UNLIKELY bits
[15:36] <ion> Okay
[15:37] <Keybuk> also no need to nih_warn() on repeating update_mount_dev_ids
[15:37] <Keybuk> if it's not supposed to happen, assert
[15:37] <Keybuk> if it's safe, just return
[15:38] <Keybuk> actually, it's quite easy for that to be called multiple times
[15:38] <Keybuk> e.g. a disk change for an md device
[15:38] <Keybuk> (would you need to recalculate then, I wonder?)
[15:40] <ion> update_mount_dev_ids is called just before fsck is spawned, and the dev_ids are only used for fsck locking.
[15:40] <Keybuk> it looks like you call it in the udev device watcher
[15:40] <Keybuk> in which case
[15:40] <Keybuk> say the fsck is queued
[15:40] <Keybuk> and a new update for the udev device comes in
[15:40] <Keybuk> you'd need to dequeue the existing fsck (I don't think you even check for it right now)
[15:40] <Keybuk> rescan the ids
[15:40] <Keybuk> then queue again
[15:41] <ion> Do md or lvm partitions ever become visible if they are not ready/fully initialized?
[15:41] <Keybuk> yes
[15:41] <Keybuk> though the watcher thing checks for that
[15:41] <Keybuk> but they can *change* remember
[15:41] <Keybuk> imagine:
[15:41] <Keybuk> boot, mdadm initialised, in degraded
[15:42] <Keybuk> user notices while fsck of / is happening
[15:42] <Keybuk> (md is /var maybe)
[15:42] <Keybuk> and pulls the disk out and replaces it
[15:42] <Keybuk> you'll get a change for the queued md
[15:43] <Keybuk> forcefsck - not sure this hook is right
[15:43] <Keybuk> mountall gets passed this as --force-fsck on the command-line, it doesn't check for the file
[15:43] <Keybuk> removing that should go in post-stop of the conf I think
[15:44] <ion> Ok
[15:50] <PuffTheMagic> so is there anyway to start a service using 'initctl emit'?
[15:50] <sadmac2> PuffTheMagic: yes. initctl emit <something> where the service is defined with start on <something>
[15:51] <PuffTheMagic> oh, but no equiv of 'initctl start <serfvicename>'
[15:51] <sadmac2> PuffTheMagic: no
[15:51] <PuffTheMagic> :(
[15:51] <sadmac2> PuffTheMagic: why?
[15:52] <PuffTheMagic> cause stupid palm dev had to use upstart 0.3.x on the Pre....
[15:52] <PuffTheMagic> so there is no dbus interface
[15:52] <PuffTheMagic> and i wanted to make a gui
[15:52] <PuffTheMagic> for starting stopping services
[15:53] <PuffTheMagic> so i have to make a service that wrapps around upstart/initctl
[15:53] <PuffTheMagic> and relays stuff over dbus
[15:53] <PuffTheMagic> and i wanted to just use events
[15:53] <PuffTheMagic> but i guess i could just call initctl start/stop
[15:53] <PuffTheMagic> just seems ugly
[15:55] <PuffTheMagic> is there a libupstart or anything in the older upstarts that will give me more functionality?
[15:55] <sadmac2> PuffTheMagic: there was a time when such a thing as libupstart existed. Not sure if its still rattling around in that code.
[15:56] <PuffTheMagic> well im using 0.3.8
[15:56] <sadmac2> PuffTheMagic: still.
[15:57] <Keybuk> yes, there's a libupstart in 0.3.8
[15:58] <Keybuk> (it's how initctl talks to upstart)
[15:58] <PuffTheMagic> good
[15:58] <PuffTheMagic> so i can use that to do start/stop :D
[15:58] <Keybuk> sadmac2: *cough* isn't "that code" what you're going to be supporting for the next seven years? :p
[15:58] <PuffTheMagic> haha
[15:59] <sadmac2> Keybuk: 7? You're some crazy kinda optimist. I'm betting on it being around in 2040.
[16:00] <sadmac2> I'll retire before 0.3 does.
[16:00] <Keybuk> you could always ship 0.6 instead :p
[16:00] <Keybuk> then, when you have some problem with it, I probably won't just point and laugh <g>
[16:00] <PuffTheMagic> so the palm devs must have static build initctl then cause i see no libupstart on this userland
[16:00] <PuffTheMagic> how lame
[16:01] <Keybuk> PuffTheMagic: upstart always static-builds initctl and init
[16:01] <sadmac2> Keybuk: you overestimate my authority on these issues. notting is the one to bug. maybe plautrba.
[16:01] <PuffTheMagic> oh
[16:01] <sadmac2> Keybuk: 8ball says don't count on it though :(
[16:01] <sadmac2> Keybuk: I'm support engineering now though. I don't build the product. I just get stuck with the consequences.
[16:02] <notting> Keybuk: didn't land in time (heck, i still haven't seen any patches for integrating it yet, and i do not have time to look at it myself right now)
[16:03] <Keybuk> I guess you're not using it any differently than in F10?  No plans to convert more jobs over?
[16:03] <notting> nope. but i'd assume it's still not a no-op to land it
[16:03] <sadmac2> notting: its missing the state transfer thing, which means the ttys-don't-respawn thing will come back. other than that its not hard.
[16:04] <sadmac2> not a no-op, but not hard.
[16:04] <sadmac2> Keybuk: I wasn't planning on moving anything until 1.0
[16:04] <sadmac2> just gonna have to fiddle with them again then anyway.
[16:04] <sadmac2> 1.0/0.10 depending on how stable we feel.
[16:04]  * Keybuk is moving things now, it's fun
[16:38] <ion> keybuk: Patches updated.
[16:46] <ion> Shutdown seems to be delayed by perhaps 10 seconds by this: http://heh.fi/tmp/upstart-rc-stop-cont-stop-cont
[16:50] <ion> LVM seems to be nice enough to compute which physical partitions each logical volume spans, and only report those partitions in /sys/.../slaves instead of e.g. every single partition the volume group uses.
[18:25] <ion> keybuk: Did you receive the above messages?
[18:26] <Keybuk> ion: I can't answer that question ;)
[18:27] <Keybuk> shutdown: the "10 seconds" is killall5 running
[18:27] <Keybuk> the upstart output is just a side-effect of what killall 5 is doing
[18:27] <Keybuk> some other process is the one not stopping
[18:29] <ion> Ok
[18:29] <ion> Why SIGSTOP?
[19:04] <ion> Can you review the new patches, btw?
[22:26] <mbiebl> ion, Keybuk: who is responsible for mountall?
[22:26] <ion> Dunno about responsible, but Keybuk is the author. :-P
[22:27] <mbiebl> ok, there is a bug wrt to ntfs mounts
[22:27] <mbiebl> I have a ntfs-3g auto mount in my fstab and subsequently mountall fails
[22:27] <mbiebl> which stops the boot process
[22:28] <mbiebl> I think there are two issues here: 1.) failing to mount ntfs(-3g) mount points
[22:29] <mbiebl> 2.) the mount point is non-critical (mounted as a shared partition under /mnt/data)
[22:29] <mbiebl> the boot should not fail because mount failed for a non-critical mount point
[22:34] <mbiebl> Keybuk: and a more cosmetic issue: the output of mount differs between the old-style mounting using the sysv initscripts and mountall
[22:34] <mbiebl> http://pastebin.ca/1561541
[22:50] <mbiebl> Keybuk: btw, is there a bug tracker for this sort of issues or should I send it to the m-l or via pm?