| === robbiew is now known as robbiew_ | ||
| creature | How can I find out the order in which upstart processes are run? Is there a tool that will draw me a tree or print me a summary? | 16:33 |
|---|---|---|
| Keybuk | there is no such thing as an "order" | 16:36 |
| Keybuk | it's an event-driven system | 16:36 |
| Keybuk | that means the boot can be different every time | 16:36 |
| creature | Well, there's a dependency tree, right? Even if you can't give a deterministic order, you should be able to show various 'levels'. | 16:37 |
| Keybuk | no, there's no "dependency tree", it's an event based system | 16:37 |
| creature | (A, B, C) first, then D (due to dependency on B), then (E, F) (which require C, D) to be started, etc... | 16:37 |
| Keybuk | Upstart is an event-based system | 16:38 |
| creature | Apparently I understand this even less than I thought. So what happens when I boot my system? How do services get started? | 16:38 |
| Keybuk | it does not do dependencies | 16:38 |
| wasabi_ | creature, events are raised. services are defined as starting on those events, or stopping on others. | 16:41 |
| wasabi_ | jobs starting emit their own events. | 16:42 |
| creature | OK. Well, let me ask another question, which might seem a little off-topic. http://pastebin.com/m1c51bf9c contains the details; in summary, I'm having trouble getting my encrypted disks to start without user intervention at boot. | 16:43 |
| creature | The best that I can determine is that this is some weird interaction between cryptsetup, udev, and upstart. | 16:44 |
| creature | But I have no idea how to debug this. | 16:44 |
| creature | My current hypothesis is that udev (or dbus) is trying to do something, and because there's no /tmp yet there's no dbus-socket, which is causing it. But I don't know how to test this, or alter my boot 'order' (or event triggers) to see if that helps. | 16:45 |
| wasabi_ | i don't think dbus is required for any of that, is it? | 16:46 |
| wasabi_ | dbus shouldn't start until tmp is mounted. | 16:46 |
| creature | I don't know how to find out at what point dbus attempts to start. I wouldn't be surprised if Ubuntu presumes that /tmp is available as soon as / is. | 16:47 |
| wasabi_ | Okay, I'm going blind with the cryptoloop stuff, because I've never used it. | 16:49 |
| wasabi_ | I'm assuming it has some initrd components that should do the work. | 16:49 |
| creature | This isn't cryptoloop, it's dm-crypt. And I think it's working via upstart too. There's a cryptdisks-enable.conf in /etc/init, at least. | 16:49 |
| wasabi_ | Actually, this is post initramfs isn't it | 16:50 |
| creature | Yes, it is, AFAIK. | 16:50 |
| creature | The key things to know are: there's a tool called cryptsetup that does the hard work. Neither of these partitions should require user input. cryptsetup handles the encryption, and makes a /dev/mapper device available, which is then mounted as usual through the fstab. (There's an /etc/crypttab for the crytpo setup.) | 16:51 |
| Keybuk | yeah | 16:51 |
| Keybuk | cryptsetup in Ubuntu is busted | 16:51 |
| creature | The crypttab says "Partition /dev/sdaX should be used as swap," which doesn't require a filesystem, so it's essentially transparent redirection. System writes to swap device, dm-crypt handles encrypting/decrypting the data that's written to disk. | 16:52 |
| creature | For tmp it's pretty much the same, but it says "This is a tmp filesystem", so it creates a new ext2 filesystem on it at boot. | 16:52 |
| === robbiew_ is now known as robbiew | ||
| === robbiew is now known as robbiew_ | ||
| magcius | Keybuk, ping. | 17:10 |
| Keybuk | magcius: what's up? | 17:11 |
| magcius | Keybuk, creature's having some issues with Upstart and encrypted disks. | 17:11 |
| Keybuk | don't care | 17:11 |
| Keybuk | cryptsetup is busted in Upstart | 17:12 |
| Keybuk | err | 17:12 |
| Keybuk | in Ubuntu | 17:12 |
| magcius | Is that a known bug? | 17:12 |
| Keybuk | yes | 17:12 |
| creature | I did try and tell magcius that you were aware of this, but... well. He's an eager beaver. | 17:12 |
| Keybuk | and nothing to do with me | 17:12 |
| magcius | Keybuk, okay. | 17:12 |
| creature | I'd be interested in seeing a link to "known busted", as I've not come across anything saying that so far. | 17:12 |
| magcius | Keybuk, so it's the rules? | 17:12 |
| Keybuk | "the rules" ? | 17:12 |
| Keybuk | as far as I know, cryptsetup is a piece of crap that nobody should ever expect to work :p | 17:12 |
| Keybuk | I looked at it, I barfed | 17:13 |
| magcius | Yes. It's OpenBSD code IIRC | 17:13 |
| Keybuk | as far as I'm concerned, if I ever have to care about it, I shall solve it by removing it from the archive | 17:13 |
| magcius | so what do you recommend for encrypted disks? | 17:14 |
| Keybuk | I don't recommend encrypted disks | 17:14 |
| Keybuk | I think it's silly | 17:14 |
| creature | So. I don't want dbus to start until my encrypted disks are started. How do I express this in upstart? | 17:19 |
| Keybuk | dbus already won't be started until local filesystems are mounted | 17:21 |
| Keybuk | which will include your encrypted disks if they're listed in /etc/fstab as mounted on particular mount points | 17:21 |
| Md | what is the ubuntu-approved solution for secure storage then? | 17:22 |
| Keybuk | Md: this isn't an Ubuntu channel | 17:22 |
| Keybuk | that question isn't appropriate here | 17:22 |
| Keybuk | ask people in #ubuntu-devel | 17:22 |
| Md | what is the Keybuk-approved solution for secure storage then? :-) | 17:22 |
| Keybuk | Md: Don't Do That Then | 17:22 |
| creature | OK, well, 'status dbus' shows me that its status is 'stop/waiting'. So much for my dbus-wants-/tmp-but-doesn't-have-it-yet theory. | 17:24 |
| Keybuk | depends whats in your fstab | 17:24 |
| Keybuk | is /tmp in your fstab? | 17:25 |
| creature | It is. | 17:25 |
| creature | /dev/mapper/ctmp /tmp/ ext4 defaults,bootwait 0 0 | 17:25 |
| Keybuk | then mountall will wait for it | 17:25 |
| Keybuk | you don't need the bootwait technically | 17:25 |
| creature | It should be ext2, but as the hang is on swap creation I don't think that's the problem. | 17:26 |
| creature | Oh, wait, I've got a new theory. | 17:27 |
| creature | I'm going to test this, but if I'm right you'll love it. | 17:28 |
| creature | Fuck yes. I am right. That took some thinking. | 17:29 |
| creature | The problem: cswap and ctmp have random keys, because you never need to decrypt them, right? They had /dev/random as their keyfile. | 17:30 |
| creature | /dev/random is high-quality randomness. It blocks if sufficient entropy is missing. | 17:30 |
| creature | The solution: replace /dev/random with /dev/urandom. | 17:30 |
| Keybuk | so you were starving your entropy pool? | 17:31 |
| creature | It was just after boot. There wasn't much entropy by that point. | 17:32 |
| creature | The keyboard-slapping was giving it enough entropy to unblock. | 17:32 |
| MattCampbell | What distinguishes upstart from runit? | 19:10 |
| MattCampbell | I'm trying to choose between the two for an appliance project in which fast booting is highly desirable. | 19:11 |
| magcius | I've never heard of runit. | 19:19 |
| MattCampbell | It's another sysvinit replacement with service supervision. | 19:20 |
| MattCampbell | http://smarden.org/runit | 19:20 |
| magcius | MattCampbell, what's the advantage of runit over sysv? | 19:21 |
| ion | As long as it doesn’t run as pid 1, it can’t reap parentless child processes. | 19:22 |
| MattCampbell | magcius: Services are restarted if they crash. Each service gets a consistent, clean process state (environment, open files, etc.). Services are started in parallel. | 19:23 |
| Keybuk | how does runit help eliminate race conditions during boot? | 19:24 |
| Keybuk | if everything is started in parallel, how do you wait to start things until they *can* be started? | 19:24 |
| MattCampbell | it has service dependencies, and there's a sequential initialization stage (a single shell script) before services are started in parallel. | 19:25 |
| MattCampbell | My guess was that upstart's developers knew about runit and had some reason for developing upstart anyway. | 19:25 |
| Keybuk | how does a job depend on the existance of a device? | 19:27 |
| MattCampbell | oh, good question | 19:28 |
| MattCampbell | upstart supports that? | 19:28 |
| Keybuk | that's the entire point of upstart's existence | 19:30 |
| MattCampbell | Oh, I thought the point of upstart was to start services in parallel for faster boot, and restart services if they crash, like runit. But that was just my assumption. And the upstart home page said nothing about devices. | 19:31 |
| Keybuk | it's all about "events" | 19:31 |
| MattCampbell | Perhaps I misunderstood in part because I observed how fast Ubuntu 9.10 and Chromium OS can boot, and thought that was what upstart was all about. | 19:31 |
| Keybuk | partly | 19:32 |
| Keybuk | if you have an event-based system | 19:32 |
| Keybuk | you can eliminate race conditions | 19:32 |
| Keybuk | you can eliminate the need for busy loops | 19:32 |
| Keybuk | you can eliminate the need for sleeps | 19:32 |
| Keybuk | and you can start everything in parallel | 19:32 |
| Keybuk | and bits carry on when they can | 19:32 |
| Keybuk | so you end up faster as a result | 19:32 |
| MattCampbell | Thanks for the clarification. | 19:33 |
| MattCampbell | I haven't yet chosen a base distro for my current project (a server appliance, with some unusual requirements), but I wanted to decide on an init system first. I'll definitely use upstart. Thanks for being patient with a newcomer. | 19:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!