Felix Miata wrote:

F14 was systemd's first Fedora GA appearance in November 2010. F19 got the green light last night and will be formally announced Tuesday. IIRC, F13 and maybe F12 were upstart's only Fedora appearances.

It wouldn't surprise me if the switch was as much a NIH thing as anything else.

I wonder if the N.I.H. runs programs to treat those with NIH syndrome... ;-) (ducking) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Graham Anderson wrote:

On Saturday 29 Jun 2013 19:44:49 Linda Walsh wrote:

...

You mention it does it's own cgroup thing -- is that easy to shut off so it doesn't mess w/mine?

This should never be a problem. Systemd services run in a cgroup namespace directly mapped to the service name. So for example sshd runs under the "sshd.service" cgroup namespace.

You should probably read this mail about upcoming kernel and systemd changes with respect to cgroups, suffice it to say that there's going to be some significant changes so you may not want to rely too heavily on cgroup API's that might change in the not too distant future.

Um... *ouch*?

http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html

--- I don't get it. I use the cgroups in /sys/fs/cgroup/. Currently my only usage is in the net_prio group to set default network priorities for a group or type of service (naming services, timekeeping, mail...etc). The only interface I'm aware of has been the one in /sys. They said something about there only being one hierarchy and it being owned by systemd. That sounds like it would interfere with setting anything up like I have already setup. What does it mean to own a hierarchy?? Are they removing the cgroup interface in /sys?

systemd is anything but monolithic, it's a collection of multiple specialised binaries, more than 50 of them... And they run with fairly tightly controlled kernel capabilities. What's the old adage, "do one thing and do it well", Does that sound familiar? ;)

Being in separate binaries doesn't mean it's _not_ monolithic. The linux kernel is 1 kernel but 100's or 1000's of modules. It is fairly configurable as to what is included. There are some large parts, but if you don't want, say, IPV6, you can build w/o it (as a random example). What type of boundaries are there between the binaries and is that interface "public" or did they they come up with their own internal interface that isn't based on any standard so nothing else can really tie in with them? Do they all require each other? Or are there are 50 different pieces one could choose to configure in like the 100's of modules in the kernel -- i.e. configuring in only the functionality that you want? If that's the case, that's cool, if not and it's an all or nothing thing... well, that'd tend to be more monolithic. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrey Borzenkov wrote:

� Sun, 30 Jun 2013 01:01:18 -0700 Linda Walsh �����:

...

but if you don't want, say, IPV6, you can build w/o it (as a random example).

No, you can't for three or for years already, unless you want to completely disable networking. Some parts of networking stack simply presume existence of IPv6 part.

---- I specifically said it was a random example to forestall such pointless diversions. If you have a kernel that is broken when you disable IPV6, take it up with your vendor.

ll /proc/sys/net/ total 0 dr-xr-xr-x 1 0 Jun 30 04:18 bridge/ dr-xr-xr-x 1 0 Jun 30 04:18 core/ dr-xr-xr-x 1 0 Jun 30 04:18 dccp/ dr-xr-xr-x 1 0 Jun 30 00:12 ipv4/ dr-xr-xr-x 1 0 Jun 30 04:18 netfilter/ -rw-r--r-- 1 0 Jun 30 04:18 nf_conntrack_max dr-xr-xr-x 1 0 Jun 30 04:18 unix/ 3.9.7-Isht-Van

Looks like people running a vanilla kernel don't have a problem. You should try it if it bothers you. If not.. that's fine too. The point is about whether or not systemd is configurable as the linux kernel is. Not whether or not people are running some specific non-standard kernel that doesn't work with it disabled... yast still gives you the ability to turn off ipv6... you might try it, you might be surprised. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 30 Jun 2013 01:01:18 Linda Walsh wrote:

...

You should probably read this mail about upcoming kernel and systemd changes with respect to cgroups, suffice it to say that there's going to be some significant changes so you may not want to rely too heavily on cgroup API's that might change in the not too distant future.

---- Um... *ouch*?

...

http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html

--- I don't get it. I use the cgroups in /sys/fs/cgroup/.

Currently my only usage is in the net_prio group to set default network priorities for a group or type of service (naming services, timekeeping, mail...etc).

The only interface I'm aware of has been the one in /sys.

They said something about there only being one hierarchy and it being owned by systemd. That sounds like it would interfere with setting anything up like I have already setup. What does it mean to own a hierarchy??

Are they removing the cgroup interface in /sys?

I don't think so, just making the default/root hierarchy managed by systemd. By the description it sounds like there will be just a few less knobs to worry about and no opportunity to accidentally clobber cgroup settings. Personally I find the following the most interesting part of the whole email: "More specifically: libcgroup is out of the game with this. libvirt/openshift/lxc/.. can continue to do what they do for now, however they should be updated sooner rather than later to do things the systemd way, i.e. rely on systemd VM/container registration and user cgroup management." I think if I was deploying KVM and containers on an upstart system I'd probably be a little bit apprehensive right now. Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

El 30/06/13 04:01, Linda Walsh escribió:

...

What does it mean to own a hierarchy??

It means that the _kernel_ (not systemd) will only allow a single writer into the cgroup hierarchy.

In the proposed changes, on systems booting with systemd, it will be the only writer and applications will hook up into it.

Ouch... going from a general file-system interface that can allow an abundance of tools to *easily* work through it, they are going to a specialized systemd-controld API... this is making me queasy. I notice that no one is saying it will be on the level of configurability as the kernel....i.e. sounds more like you take the whole thing or you are on your own. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 30/06/13 23:57, Linda Walsh escribió:

Ouch... going from a general file-system interface

The filesystem interface is very likely not going away immediately, it can't, it is part o the kernel->user-space API/ABI. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org