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