| |||||||||||||
The road forward for systemdThe road forward for systemdPosted May 26, 2010 19:57 UTC (Wed) by jspaleta (subscriber, #50639)In reply to: The road forward for systemd by martin.langhoff Parent article: The road forward for systemd
The proof is indeed in the pudding. Like for most things, its much easier for me to wrap my head around it when there are bits I can break.
There's a lot of flexibility here for service control that sysadmins who have grown to rely on sysV init scripts are going to need to expend some energy learning to wrap their heads around some of the flexibility in control/resource limits that relying on cgroups allows. From a sysadmin pov, this seems like some of the richer benefits are going to be reaped in understanding that particular point of the design... as well as some of the biggest challenges. The discussion about how cgroup level interactions with screen-like detached behavior is going to be important.
-jef
(Log in to post comments)
The road forward for systemd Posted May 26, 2010 21:46 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
most sysadmins deal with servers, and on the servers there is less value in the delayed startup, and more importance that the first time something tries to access a service it be up and running (without having to wait for it to initialize)
this is something useful for desktops, but that's not for where most sysadmins work.
The road forward for systemd Posted May 26, 2010 22:07 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Did I say anything about boot up speed? I'm referring to how cgroup level resource controls can be configured. The follow up discussion in the blog comments about detached screen session behavior in a cgroups controlled login session speak directly to the sorts of tradeoff of the flexibility of the cgroups level controls as it applies to long running services like login sessions.
The design of systemd isn't _just_ about service start up. There are elements in there which deal with resource constraints over the lifetime of the systemd control process via its use of cgroups. I think sysadmins should attempt to wrap their heads around when cgroup level control are going to be useful..and when they are going to be..in the way. Part of that will mean getting familiar with the libcgroup utilities..which are mentioned in the blog story.
To paint systemd as just being a different way to start things up fast is missing a critical point about service management in choosing to rely on cgroups in the design.
-jef
|
|||||||||||||