| twb | Is /lib/init/fstab an upstartism? | 05:53 |
|---|---|---|
| twb | lxc-ubuntu creates it, but I'm not sure what uses it | 05:53 |
| ectospasm | this channel seems underpopulated, and the Upstart documentation seems woefully inadequate. | 05:54 |
| ectospasm | ...I never see any adequate answers to questions like that here. | 05:55 |
| twb | ectospasm: I know, but it costs me little to try | 05:57 |
| ectospasm | true enough | 05:58 |
| 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:36 |
| mbiebl | but yes, it is upstart specific (as is mountall) | 08:37 |
| twb | OK. | 08:37 |
| 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:38 |
| mbiebl | which directories fail to mount under lxc? | 08:39 |
| twb | mbiebl: I don't know | 08:40 |
| twb | I don't know *how* to know | 08:40 |
| 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:43 |
| 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:45 |
| twb | That means I don't need it for my specific use case | 09:46 |
| === azul_ is now known as jodh | ||
| 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:49 |
| twb | Yeah, but I happen to not be doing it :-) | 09:50 |
| twb | Dumb question: does that mean ubuntu/upstart ignores RAMRUN=yes RAMLOCK=yes in /etc/default/rcS? | 10:10 |
| mbiebl | yes | 10:11 |
| twb | Hum. | 10:11 |
| 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:17 |
| mbiebl | /etc/init/rc.conf | 11:18 |
| mbiebl | it calls /etc/init/rc 0|6 on shutdown/reboot | 11:18 |
| twb | Ah, and the hard halting is done by it | 11:19 |
| mbiebl | it is done in S90reboot resp. S90halt | 11:20 |
| twb | Right, I juts found it | 11:20 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| twb | mbiebl: short of HTFS, is there a way to tell upstart "I know better than you, please let me kernel panic"? | 11:58 |
| 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:00 |
| 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:01 |
| twb | Or are you saying that "LXC is just wrong"? | 12:02 |
| Keybuk | I was ;) | 12:03 |
| twb | Grmph | 12:04 |
| Keybuk | I'm not a fan | 12:04 |
| twb | mbiebl: in case you don't know, lxc is basically openvz cleaned up and accepted into mainline | 12:05 |
| 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:07 |
| 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:08 |
| Keybuk | that sounds like a bug in lxc | 12:09 |
| 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:12 |
| twb | mjt said -9 might be special | 12:20 |
| twb | So I just tried everything from -1 up, and -8 worked | 12:20 |
| twb | So I *think* I can just edit /etc/init.d/S90halt to call "kill -8 1" instead of "halt -f" | 12:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| twb | OK, I think I have it actually working | 12:36 |
| 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. | 12:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!