Recent Features
| |||||||||||||
Poettering: Rethinking PID 1Poettering: Rethinking PID 1Posted Apr 30, 2010 20:29 UTC (Fri) by cmccabe (guest, #60281)In reply to: Poettering: Rethinking PID 1 by jwb Parent article: Poettering: Rethinking PID 1
If I read this right, systemd is about more than tweaking the way Linux boots. A few of the goals I saw mentioned:
1. Start fewer processes and only start them when they're actually needed.
2. Minimize boot time. This is very important for server admins trying to get to "five nines" of uptime. Sometimes you are upgrading your kernel or hardware, and you just have to reboot. It needs to be quick.
3. Manage the processes on the system. For example, put the updatedb process in its own appropriately configured cgroup. This should limit how much I/O and CPU updatedb can grab from foreground tasks.
4. Handle dynamically changing hardware configurations properly. For example, start the correct daemons when a bluetooth device is plugged in.
A lot of the "quirky interfaces" people complain about are things like automounting USB thumb drives not working correctly, or bluetooth setup. These are things that systemd is explicitly designed to address.
(Log in to post comments)
Poettering: Rethinking PID 1 Posted Apr 30, 2010 21:24 UTC (Fri) by intgr (subscriber, #39733) [Link]
> 2. Minimize boot time. This is very important for server admins trying to
> get to "five nines" of uptime. Sometimes you are upgrading your kernel or > hardware, and you just have to reboot. It needs to be quick.
Unfortunately for servers, any boot process optimization is completely irrelevant because the proprietary BIOS and SAS controller take a whole 5 minutes to initialize. It's a little ironic that the cheapest desktop computer can be up and running in 30 seconds, but the more expensive your server, the slower is your boot time.
Poettering: Rethinking PID 1 Posted Apr 30, 2010 21:45 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>It's a little ironic that the cheapest desktop computer can be up and running in 30 seconds, but the more expensive your server, the slower is your boot time.
Oh it's a good tradeoff. Given enough cores - and SGI has done these experiments - the firmware will be faster enough than the Linux kernel bootup. :-) IIRC it was something like.. 12 minutes for 4096 cores?
Poettering: Rethinking PID 1 Posted May 1, 2010 2:25 UTC (Sat) by pabs (subscriber, #43278) [Link]
The updatedb cron job should not exist. It should have been replaced by a daemon listening to inotify or similar by now.
Poettering: Rethinking PID 1 Posted May 2, 2010 23:24 UTC (Sun) by jwb (guest, #15467) [Link]
Wouldn't that result in a massive directory walk at every boot, as well as a big race? I'm not sure I like the tradeoff.
Poettering: Rethinking PID 1 Posted May 3, 2010 15:11 UTC (Mon) by bronson (subscriber, #4806) [Link]
It would be a massive treewalk only if inotify still doesn't believe that filesystems are hierarchical. I remember seeing some patches trying to fix this but I'm not sure if they got anywhere.
I don't see a big race... If you're talking about missing changes because they occurred before the treewalk is done then I agree: inotify needs to be established before the system starts doing much.
Personally, I remove locate and updatedb from all machines I manage, including laptops. I find that all my needs are met by dpkg --search and the find command. I'm really surprised that updatedb is still a part of default Linux installs: it's intrusive and locate is almost useless!
Poettering: Rethinking PID 1 Posted May 6, 2010 16:24 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Personally, I remove locate and updatedb from all machines I manage, including laptops. I find that all my needs are met by dpkg --search and the find command. I'm really surprised that updatedb is still a part of default Linux installs: it's intrusive and locate is almost useless!
Intrusive yes, but so useful and convenient.
locate answers instantly, and there is no need to remember it's command line syntax (it has none). Sometimes I use locate instead of find even when I know for sure that the file is just a few directory levels below.
Poettering: Rethinking PID 1 Posted May 3, 2010 22:18 UTC (Mon) by cmccabe (guest, #60281) [Link]
> The updatedb cron job should not exist. It should have been replaced
> by a daemon listening to inotify or similar by now.
My point was that you often want to do large jobs in the background, without having them interfere with what's going on in the foreground. Putting them in a separate cgroup is a step forward.
Beagle acts like a filesystem index, and listens to inotify. The last time I tried it, it made my system unusably slow by aggressively trying to index files as soon as they were created. That was on an older computer with only one core, though. Maybe I'll give it another try in the future when I get some time. In the meantime, asserting that alternative solutions "should not exist" seems kind of trollish.
Poettering: Rethinking PID 1 Posted May 7, 2010 7:57 UTC (Fri) by pabs (subscriber, #43278) [Link]
It was less of a troll and more of a "surely we can and should be doing better than updatedb in this day and age?".
Poettering: Rethinking PID 1 Posted May 16, 2010 23:53 UTC (Sun) by cmccabe (guest, #60281) [Link]
> It was less of a troll and more of a "surely we can and should be doing
> better than updatedb in this day and age?".
Oh, ok.
I always forget where things are, so I end up using slocate all the time.
It seems like are some tradeoffs here. Having a daemon that listens to inotify makes things slower while you're using the machine. It's more complicated and more likely to lose track of files. The updatedb / slocate scheme probably uses more power in total because it does a treewalk while you're asleep. But it is simple and always works. Of course, information may be slightly out-of-date.
Maybe people who are really concerned about the power issues should do updatedb once a week instead of daily? Would that be an acceptable tradeoff?
I suspect that, like vi/emacs, this debate will not be resolved any time soon.
Poettering: Rethinking PID 1 Posted May 17, 2010 5:51 UTC (Mon) by avik (guest, #704) [Link]
updatedb doesn't work while I'm asleep since the machine is configured to fall asleep when I do. Nor does it always work: removable disks won't work; with selinux there may be files accessible to the user but not accessible to root. Multi-user machines are rare these days, but a shared machine might take the updatedb hit just when someone in .au wakes up and connects to it.
In short, it's a static solution that doesn't fit the dynamic environment of the last 15 years.
Poettering: Rethinking PID 1 Posted May 17, 2010 6:31 UTC (Mon) by nix (subscriber, #2304) [Link] files accessible to the user but not accessible to rootThey must be easy to back up, with properties like that.
Poettering: Rethinking PID 1 Posted May 17, 2010 9:57 UTC (Mon) by nye (guest, #51576) [Link]
>>files accessible to the user but not accessible to root
>They must be easy to back up, with properties like that.
Arg. This is how user files work in Windows by default. So annoying. Windows makes a chore out of things that should be so simple.
Anyway the solution is probably to have backups done individually by the user if there is only one and it's the same person as root (ie. yourself), or to have a user whose dedicated role is to be able to read every non-special file for backup purposes, without any of the other permissions root would have which could potentially be dangerous. Then again, you could just run updatedb as that user, so...
Poettering: Rethinking PID 1 Posted May 17, 2010 6:49 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
you are making the exact mistake you are accusing others of, assuming that everyone uses systems like yours.
Poettering: Rethinking PID 1 Posted May 17, 2010 7:56 UTC (Mon) by avik (guest, #704) [Link]
I haven't accused anyone of anything. You're confusing me with somebody else.
(nor am I assuming everyone uses systems like mine; it's sufficient that a substantial fraction of users suspend or turn off their machines at night, or use detachable storage, to show that updatedb is outdated)
Poettering: Rethinking PID 1 Posted May 17, 2010 10:25 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
no, that only means it's not appropriate for those users
Poettering: Rethinking PID 1 Posted May 17, 2010 11:04 UTC (Mon) by avik (guest, #704) [Link]
That's why a more general solution is proposed.
Poettering: Rethinking PID 1 Posted May 7, 2010 7:55 UTC (Fri) by pabs (subscriber, #43278) [Link]
Er, no. Such a daemon would get updates from inotify/fanotify/etc, update the database lazily while it is running, flush those writes on shutdown and load the database on startup. For added speed, locate could query it on a socket when it is up and read the database when it is down.
Poettering: Rethinking PID 1 Posted May 8, 2010 22:08 UTC (Sat) by nix (subscriber, #2304) [Link]
And this works over a network how?
(if the inotify daemon did exist, it would need to be able to be told to write out separate dbs for specific subtrees, at least, so that the NFS server could run it and export locate databases to its clients.)
Poettering: Rethinking PID 1 Posted May 8, 2010 22:34 UTC (Sat) by foom (subscriber, #14868) [Link]
You don't write out dbs for remote clients to access as files, just export the index as a network service. Works great on Windows...
Poettering: Rethinking PID 1 Posted May 9, 2010 9:53 UTC (Sun) by nix (subscriber, #2304) [Link]
So now locate(1) has to grow network-handling code and suddenly becomes a security target as a result and has to deal with spoofing, malicious network services and so on, where before it was only as much a target as everything that reads the filesystem and command-line (and even *that* vulnerability surface has had a security hole or two in the past).
No thank you.
Poettering: Rethinking PID 1 Posted May 10, 2010 1:35 UTC (Mon) by foom (subscriber, #14868) [Link]
I can see how you might not find the feature valuable. But a network service is really the only sane way to implement search on a network share.
And security shouldn't be a huge deal -- you only need expose it to the users you're exporting the filesystem to, anyhow.
|
|||||||||||||