[05:53] <twb> Is /lib/init/fstab an upstartism?
[05:53] <twb> lxc-ubuntu creates it, but I'm not sure what uses it
[05:54] <ectospasm> this channel seems underpopulated, and the Upstart documentation seems woefully inadequate.
[05:55] <ectospasm> ...I never see any adequate answers to questions like that here.
[05:57] <twb> ectospasm: I know, but it costs me little to try
[05:58] <ectospasm> true enough
[08:36] <twb> If I'm running upstart inside a container, how do I pass --debug to it?
[08:36] <twb> (container as in LXC)
[08:36] <mbiebl> twb: to be precise, /lib/init/upstart is used by mountall
[08:37] <mbiebl> but yes, it is upstart specific (as is mountall)
[08:37] <twb> OK.
[08:38] <twb> I'm trying to run lucid in an LXC container, but unless I rip out most of /lib/init/fstab, it doesn't start a getty on /dev/console and there's no other output on /dev/console, and I don't know how to work out why -- short of bisecting over /lib/init/fstab
[08:39] <mbiebl> which directories fail to mount under lxc?
[08:40] <twb> mbiebl: I don't know
[08:40] <twb> I don't know *how* to know
[09:43] <twb> In /lib/init/fstab, is "showthrough" a mountallism?
[09:43] <twb> i.e. if I'm moving those mountpoints to pre-upstart code, do I just strip that option out?
[09:45] <mbiebl> showthrough from what I know allows you to mount /var/run early during boot
[09:45] <mbiebl> and later /var 
[09:45] <mbiebl> and /var/run won't be shadowed
[09:45] <twb> Oh, I see.
[09:46] <twb> That means I don't need it for my specific use case
[09:49] <mbiebl> twb: if you don't have a separate /var, yes
[09:49] <mbiebl> (not sure if that is even possible within an lxc container)
[09:50] <twb> Yeah, but I happen to not be doing it :-)
[10:10] <twb> Dumb question: does that mean ubuntu/upstart ignores RAMRUN=yes RAMLOCK=yes in /etc/default/rcS?
[10:11] <mbiebl> yes
[10:11] <twb> Hum.
[11:17] <twb> Due to the way LXC operates, I want to instrument wherever the upstart calls the "real" (hard) halt
[11:17] <twb> I can't see where that's happening in /etc/init -- is it done elsewhere?
[11:18] <mbiebl> /etc/init/rc.conf
[11:18] <mbiebl> it calls /etc/init/rc 0|6 on shutdown/reboot
[11:19] <twb> Ah, and the hard halting is done by it
[11:20] <mbiebl> it is done in S90reboot resp. S90halt
[11:20] <twb> Right, I juts found it
[11:52] <twb> Is it just me, or does upstart get pissy if its pid isn't 1
[11:52] <twb> kill -9 1 wasn't working, so my first idea was to make upstart the not-quite-first init
[11:52] <mbiebl> it needs to be pid 1
[11:53] <ectospasm> twb: init is always 1
[11:53] <twb> Because the kerenl gives special treatment to 1?
[11:53] <ectospasm> init is the parent process of everything
[11:53] <ectospasm> init cannot be a child of some other process
[11:53] <ectospasm> old school UNIXy design, IIRC
[11:53] <mbiebl> pid 1 has special semantics
[11:54] <mbiebl> re-parenting of child processes etc
[11:54] <twb> Is there a way to get "kill -9 1" or similar to work?
[11:54] <ectospasm> twb: what are you trying to achieve with "kill -9 1"?
[11:55] <mbiebl> killing pid 1 will result in a kernel panic
[11:55] <twb> I'm in a container, and halt/reboot -f doesn't work quite right, but I'm told LXC will do the right thing if I instea terminate the init process
[11:58] <twb> mbiebl: short of HTFS, is there a way to tell upstart "I know better than you, please let me kernel panic"?
[12:00] <mbiebl> twb: I know there were problems in the past related to openvz and upstart
[12:00] <mbiebl> I can't tell you more, sorry
[12:00] <Keybuk> there's nothing about Upstart that would cause kill -9 1 to not work
[12:01] <Keybuk> if kill isn't working, you have a kernel problem
[12:01] <Keybuk> (which was implied by you saying you were using LXC, I realise)
[12:01] <twb> Keybuk: my host OS is 10.04 (running stock lucid 2.6.32) -- could I fix this with a different / newer kernel?
[12:01] <Keybuk> no idea
[12:02] <twb> Or are you saying that "LXC is just wrong"?
[12:03] <Keybuk> I was ;)
[12:04] <twb> Grmph
[12:04] <Keybuk> I'm not a fan
[12:05] <twb> mbiebl: in case you don't know, lxc is basically openvz cleaned up and accepted into mainline
[12:07] <twb> Well, lucid doesn't boot if /var/run isn't a tmpfs, and lxc doesn't detect the guest halting if /var/run is a tmpfs, so it looks like I'll have to give up and use KVM, taking the performance hit that emulating an entire peecee for every daemon implies
[12:08] <twb> (If lxc doesn't see the domU pid 1 terminate, it does a dirty hack by watching /var/run/utmp for a restart event, but it can't see it when there's a tmpfs mapped over the top.)
[12:09] <Keybuk> that sounds like a bug in lxc
[12:12] <twb> mjt (in #lxcontainers) said: well, the prob can be solved in two places.  Either proper (for a container) sys_reboot in kernel (this is what halt -f is using), or in init.  So far kernel folks tells us "it can be done in userspace" (in init), and init folks say "kernel is wrong".
[12:20] <twb> mjt said -9 might be special
[12:20] <twb> So I just tried everything from -1 up, and -8 worked
[12:21] <twb> So I *think* I can just edit /etc/init.d/S90halt to call "kill -8 1" instead of "halt -f"
[12:24] <Keybuk> if kill -9 1 is being treated as special, it's being treated as special by the kernel ;-)
[12:24] <Keybuk> so again, the fix for that should go in the kernel
[12:24] <twb> I guess so.  Sorry for losing my temper.
[12:25] <Keybuk> so the discord is because when you write software on any platform, you agree to a contract between yourself and things like the kernel for how you should operate
[12:25] <Keybuk> something like init is even more important, it has special behaviours that aren't granted to ordinary processes
[12:25] <Keybuk> so the contract (ie. API/SDK) between you and the kernel is very important
[12:26] <Keybuk> the reason init authors tend to dislike things like LXC is that it makes the kernel break that contract
[12:26] <Keybuk> and the LXC folks seem to think it's our fault
[12:26] <Keybuk> now, if container authors could agree on an alternate contract
[12:27] <Keybuk> *and* provide ways for init to be told which contract we should use
[12:27] <Keybuk> things would be better
[12:27] <Keybuk> but historically they've been unwilling to do that
[12:27] <twb> I suppose they argue the whole point is you shouldn't be able to tell you're in a container
[12:27] <Keybuk> (OpenVZ, LXC, etc. have all randomly changed their APIs and which kernel features they support between releases)
[12:27] <Keybuk> and right, they argue that a call to tell whether you're in a container defeats the point
[12:27] <Keybuk> and our counter-argument is that we *CAN* tell we're in a container
[12:28] <Keybuk> we can tell because the kernel is not obeying its interface contract to userspace
[12:28] <twb> haha
[12:28] <Keybuk> they can't have their cake and eat it
[12:28] <Keybuk> if a container should be invisible, it should also be invisible to init
[12:28] <Keybuk> if init should handle containers specially, so should all user space processes be able to
[12:36] <twb> OK, I think I have it actually working
[12:37] <twb> Now a kill -2 to lxc-start (or upstart) from the dom0 will make upstart see a ctrl-alt-del, and at the end of that, /etc/init.d/reboot (or halt) will kill -SEGV 1, which lxc-start "sees" and handles the cleanup of stuff above upstart.