Richard Brown wrote:
On 28 June 2013 21:11, Linda Walsh
wrote: Advantages?
For me, one of the big appeals of systemd is nothing to do with its boot performance, but it's capabilities to manage services 'on demand'
Systemd is able to start and stop services based on D-Bus, Sockets, Files/Paths (inotify). Upstart has no such capabilities.
This has already brought some benefits - in 12.3 the CUPS service isn't started up until a user tries to print. This has pretty huge potential beyond that simple example - I've been messing around on some of my servers using systemd to automate some regular sysadmin-esque activities.
That's a very cool feature. Very much like windows -- which I've already noted systemd having a strong Windows-like feature set. That's not necessarily bad nor good -- I use win for a desktop and lin for serving.
For example, I had an application that was a little messy with how it behaved, and spat out un-needed debug files every few minutes. There was no way to disable this feature, and the developers recommendation was just to write a cron script that pruned them down after a while. With systemd, I was able to create a unit file (aka service) that would listen for any file being created in that location, and automatically run a script of my choosing, which in this case did nothing more than delete the files present. Nice, simple, tidy... I can see the potential for systemd to be used for much bigger and brighter things than my simple two examples
So sorta like xinetd listens for services and launches them? `Course dbus wasn't around when xinetd was first designed, and dbus often fails/dies in my own experience.
Another key benefit to systemd in my opinion is its tight integration with Linux control groups - This kernel feature is incredibly useful, being able to manage the resources and priorities of processes, but before systemd it was quite an exercise to really make use of cgroups. Every running service in systemd is running in its own cgroup automatically, and systemd provides some nice tools that make it a lot easier to start using cgroups to control your processes.
---- Might be nice might be a pain. I currently run my own cgroups -- mostly for networking, where I map services to they type of network service... So: } map cgroups=( [Compliant]=$(PRIO) [bulk_back]=$(NORM) [bulk_fore]=$(HI_THRU) [webproxy]=$[$(HI_THRU)|$(PRIO)] [mail]=$[$(HI_RELY)|$(PRIO)] [DNS]=$[$(IMMD)|$(HI_RELY)] [time]=$[$(HI_RELY)|$(FLSH)] [fileserv]=$[$(PRIO)|$(HI_THRU)|$(HI_RELY)] )
And I'm sure there is much more, every time I take a look at systemd it seems to have something new to play with
So yes, in terms of 'boot speed', it might give little or no benefit over upstart, but in terms of a bigger picture, I think systemd gives a much more comprehensive and powerful set of tools for managing a Linux systems processes/services ==== You mention it does it's own cgroup thing -- is that easy to shut off so it doesn't mess w/mine?
A concern I have with monolithic programs is that often, they don't play nice with other programs. Managing udev, power, xinet/inetd type functions... having all your eggs in one basket makes for too much of a uniform breeding ground for problems (especially exploits). I don't mind it managing services, but it seems that it wasn't designed with flexibility in mind (lots of boot time requirements). That has shown to be problematic already. More flexibility would go far in making it useful and even desirable. Also, we found that having no off=switch was a problem in the M5 system manager... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org