User: Password:
|
|
Subscribe / Log in / New account

Poettering: systemd for Administrators, Part XVIII (controllers)

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Oct 26, 2012 9:20 UTC (Fri) by jezuch (subscriber, #52988)
In reply to: Poettering: systemd for Administrators, Part XVIII (controllers) by Kit
Parent article: Poettering: systemd for Administrators, Part XVIII (controllers)

I guess the optimal outcome would be an init system with documentation that reads:

"Install. It works."

I'd also like every CPU to have a DWIM instruction.


(Log in to post comments)

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Oct 26, 2012 21:10 UTC (Fri) by intgr (subscriber, #39733) [Link]

> "Install. It works."

I believe systemd actually comes the closest of all init systems. Many upstream packages already ship systemd units -- just "make install" and possibly "systemctl enable foo" required. Compared to SysV where your distro's package maintainer duplicated a shell script for each package, and assigned a "priority number" on an arbitrary scale to order service startup.

It also replaces several other pieces that had to be manually configured before. As the article mentiones, systemd services share CPU time equally by default, not depending on the number of processes they have like before.

And many more I can think of: Most systemd users probably don't even realize that it includes a readahead tool for speeding up system startup. It works without any hacks and configuration within LXC/namespace containers. If you want a serial console, you only need to configure it in one place (on the kernel command line). Instead of distros supplying acpid and a maintainer-written script for power button events, systemd has a simple built-in default policy -- so shutting down VMs from the host works out of the box. And many more that I can't remember right now.

So, many things that seem like duct-taped together in other systems (usually by distro package maintainers), or things that required unnecessary amounts of fiddling and configuration -- now systemd does The Right Thing using a sensible built-in policy and provides straightforward configuration options.

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Nov 2, 2012 14:53 UTC (Fri) by knobunc (subscriber, #4678) [Link]

My only complaint with systemd is that I can't work out how to tell it to unmount and unlock a filesystem so I can fsck it.

I have an external SATA drive that I use for backups. Occasionally I have need to do:
> umount /backup
> e2fsck /dev/sde1

However, the fsck fails because systemd has locked the device.

I have tried systemd stop of various unit names, but have never found the right one to make systemd not hold a lock on the device.

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Nov 2, 2012 15:22 UTC (Fri) by raven667 (subscriber, #5198) [Link]

lsof might be your friend here to identify what is touching the device.

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Nov 2, 2012 15:45 UTC (Fri) by knobunc (subscriber, #4678) [Link]

It did. It is process 1 (i.e. systemd). That's why I need to tell systemd to release it...

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Nov 2, 2012 16:45 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

file a bug report

Poettering: systemd for Administrators, Part XVIII (controllers)

Posted Oct 28, 2012 16:19 UTC (Sun) by nix (subscriber, #2304) [Link]

I'd also like every CPU to have a DWIM instruction.
I protest on the entirely self-serving basis that this would leave half of us here out of a job. :)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds