| dkam | Hey guys - I run a web app which requires a couple of daemons to run - is it appropriate to use Upstart to manage these users based processes? | 02:14 |
|---|---|---|
| dkam | Seems like a good way to do it - starts up at system startup, respawns if it crashes. | 02:15 |
| dkam | Does this look sane? http://gist.github.com/386808 | 02:16 |
| dkam | (I'm still not quite sure about where the environment variables go - I think sudo eats them if I don't put them within the sudo call) | 02:18 |
| torment | how can i tell upstart to not start network-interface from grub? | 02:40 |
| torment | its hanging my system boot | 02:50 |
| torment | no takers huh | 03:07 |
| Keybuk | don't you just hate it when you write an e-mail that would make an awesome blog post, but can't, for any number of reasons, post it publicly :-( | 07:49 |
| ion | Heh | 08:10 |
| ion | Perhaps some unknown person just happens to get hold of it and post it anonymously in a pastebin/wikileaks/something. :-P | 08:12 |
| Keybuk | lol | 08:22 |
| Keybuk | I don't really want to enter a public argument with Lennart over systemd vs. upstart | 08:23 |
| Keybuk | or, indeed, a private argument ;) | 08:23 |
| Keybuk | mail was answering internal questions as to why Upstart doesn't do some of the things systemd does | 08:24 |
| Keybuk | like why cgroups don't work for process supervision | 08:24 |
| * Keybuk played with them for Upstart a couple of years ago, if you recall | 08:27 | |
| ion | Yeah, vaguely | 08:29 |
| Keybuk | it's the screen problem | 08:29 |
| Keybuk | you place each service in a cgroup | 08:30 |
| Keybuk | cgroups ensure each child process is in the same cgroup | 08:31 |
| Keybuk | and you use the cgroup feature where a cgroup becoming empty notifies the cgroup creator | 08:31 |
| Keybuk | so, getty has a service | 08:31 |
| Keybuk | that service has a cgroup (debug:/systemd-1/getty@.service/tty1 in systemd) | 08:31 |
| Keybuk | you login, your login process stays in that cgroup | 08:31 |
| Keybuk | and your bash process stays in that cgroup | 08:32 |
| Keybuk | now you run screen | 08:32 |
| Keybuk | that stays in that cgroup | 08:32 |
| Keybuk | and you run something like irc | 08:32 |
| Keybuk | that stays in that cgroup | 08:32 |
| Keybuk | you now detach screen, and exit bash (and thus exit login) | 08:32 |
| Keybuk | screen is still running | 08:32 |
| Keybuk | irc is still running | 08:32 |
| Keybuk | the cgroup is not empty | 08:32 |
| Keybuk | getty is not respawned | 08:32 |
| ion | Right | 08:37 |
| ion | I was thinking of how to collect disk usage patterns for optimum reordering in the far future. There could be a daemon that constantly gets information about block reads from the kernel and updates a markov chain. A defrag process could then run with idle IO priority and reorder filesystem blocks to optimize for the parts of the chain with the highest usage weights. The chain could additionally be pruned of stuff below a weight threshold every now and then. I have ... | 08:38 |
| ion | ... no idea whether that would actually be feasible, but there must be a way to do something similar, since Windows™ is doing it. Another thought: a device mapper that does filesystem-independent block reordering based on that data. | 08:38 |
| Keybuk | it would be pretty trivial with btrfs | 08:39 |
| Keybuk | though why would you want to reorder the filesystem all the time? | 08:39 |
| Keybuk | you only really care about the order of things read during boot | 08:39 |
| Keybuk | to try and group them together | 08:39 |
| ion | I also care about things read during post-boot computer usage. Windows™ does that too, optimizing blocks for frequently started pieces of software. | 08:40 |
| ion | The actual reordering doesn’t need to be constant. It could also happen every now and then. | 08:40 |
| Keybuk | bear in mind though that the newer Linux filesystems tend to not fragment as much | 08:43 |
| Keybuk | so exactly what windows does might not be relevant | 08:43 |
| Keybuk | you might, instead, for example want to keep track of the most commonly used files | 08:44 |
| Keybuk | rather than blocks | 08:44 |
| ion | Nevertheless, if a person always starts OpenOffice and Firefox after booting the system, it would be nice for the blocks to be in roughly sequential order. | 08:44 |
| Keybuk | and when those packages are upgraded, hint strongly to btrfs not to accept fragmentation | 08:44 |
| Keybuk | right, but the windows approach is probably wrong | 08:44 |
| Keybuk | (for Linux's filesystems) | 08:44 |
| ion | The base concept sounds good for any filesystem. Generate a statistical model, such as a markov chain, and reorder blocks based on what weighs the most in the model. | 08:46 |
| ion | And, naturally, keep evolving the model forever. There should also be a bias toward recent usage patterns. | 08:48 |
| Keybuk | no | 08:48 |
| Keybuk | again | 08:48 |
| Keybuk | you don't want to reorder *blocks* on a Linux filesystem | 08:49 |
| Keybuk | you want to reorder *files* | 08:49 |
| ion | Make that more generic: s/blocks/data/, so an implementation that reorders files matches the description. :-) | 08:50 |
| Keybuk | it'd be pretty easy to write though | 08:50 |
| Keybuk | just enable open tracing | 08:50 |
| Keybuk | and on shutdown read through /sys/debug/tracing/trace and update your file lists | 08:50 |
| Keybuk | then reorder | 08:51 |
| ion | Yeah | 08:51 |
| JanC | reordering files takes time too ;) | 09:59 |
| ion | Naturally | 10:09 |
| Keybuk | my iPhone feels a lot smaller now | 10:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!