Service supervision is where a daemon takes charge of a service, and should the service stop without user provocation, the service is restarted along with any logging of that service if configured for the service. If the user does stop the service then the service stays "down" until the user bring it "up" again, or the system is restarted. However, if the service script is not available or executable, the service is not started.

However, even by that definition, it's a fickle argument that we need service supervision that badly.

3 members found this post helpful.

Well, yes, that is precisely my point. I did not imply that every feature of systemd needs to be in the init system, far from it, and I do not plan to reimplement everything in the same package.
It stands nonetheless that the features of systemd are the reason why it got adopted so widely, and similar features, albeit organized differently (and correctly implemented this time), need to be provided if we are to compete; and I need to know what is important for distributions.

It is indeed somewhat complicated, because there are two close notions and it is easy to confuse them. I would say that service supervision is an overloaded term, and refrain from using it.
At the very basic level, there is process supervision. It is a framework for starting, stopping, and monitoring daemons; that is what daemontools, runit, s6 and perp do.
Up a layer, there is service management. It is a global view of all services running on a machine, and a framework to handle them. A service can be represented by a running daemon, in which case managing the service amounts to supervising the daemon process; but it is not always the case. A network interface being up, for instance, can be a service - the service is down when the interface is unavailable - even though it doesn't have any process attached to it. systemd has that notion of "unit" which can be basically anything - it takes service management to a whole new level.

Process supervision is essential; everything that people hate about System V scripts comes from the lack of process supervision.
Service management is not essential, but, as far as I understand it, it is nice to have, and it is one of the most obvious advantages of systemd over its competitors. Again, I am not sure how important it is, and I would like to hear word from distribution maintainers: in order to switch from systemd to a new framework, do you need that framework to provide service management ?

3 members found this post helpful.

I do not wish to engage in pointless debate, but I do not think that either of those propositions are without dispute.

I can appreciate that they are drivers of your own project, but they are not universally accepted truths.

Exactly,

Things brought in by systemd could be easily forked as modular projects working off a static library dependency rather than shared library to make it portable.

Why can't we have just a libsystemd static library to link from?

logind shouldn't have to require PAM, but it should be portable enough to use it's own internal dependency library without requiring the underlying shared systemd dependency library at all.

That's like compiling a program to work off zlib's static library to where it can be portable between systems, rather than the shared library locked to a single system.

My question is why should there be a global system of "service supervision". Why doesn't every service implement their own service supervision as needed ? It sounds very naiive to think that a global system of service supervision can manage to bring up services if they have crashed. I mean it doesn't investigate into the cause of the stopped service, and I'd say it is unlikely to succeed in bringing it back up unless it knows what is wrong. How can it know what could go wrong with every service that it manages. It doesn't make sense.

1 members found this post helpful.

The supervisor tracks the execution state of the service. Like a parent-child process, it uses the execution state as a way to track the service. If the execution state stops and exits, closing the parent-child process, the service supervisor re-executes the service.

Here's what Gerrit Pape wrote on it:

http://smarden.org/runit/benefits.html

Well, if there is one debate about systemd that is not pointless, it is exactly this one - what should an alternative provide in order to be a serious competitor ?

I'm not talking about individual preferences here. I'm using s6 as is, with no service management, no PAM, no graphical interface, no glibc, almost no shell, and am very happy with it. I'm talking about something generic, something that a distribution needs. I am willing to take the time to correctly design the parts that are needed, and write them. It's not about my project as it is today: it's much bigger than that.

If you disagree with what I said in my previous message, then please enlighten me. What, in your opinion, should be done in order to provide an alternative to systemd, that systemd opponents would be happy with ?

Here's a good article on service supervision as well:

http://jtimberman.housepub.org/blog/...olved-problem/

kdbus is a major concern as
http://www.phoronix.com/scan.php?pag...tem&px=MTczNjI

This means that if kdbus is merged into the kernel then systemd would be the only option even with eudev unless a workaround is found. I suppose if this happens we will have to assume that a workaround can and will be found, and that this workaround will allow init and the rest of the alternatives to work.

It also means that unless you use systemd, or get a working kdbus API handler for non-systemd systems, the userspace will be completely broken.

However, unless kdbus doesn't get added, then it's a fruitless effort meaning, we have time to counterattack the advance of systemd, but we're on borrowed time. Once, and if, kdbus is ever added, it's over unless Gentoo's Eudev team commits to a complete fork.

To restate the points I disagreed with:

With regard to the first point, I think that systemd was swept into "acceptance" as quickly and to the degree that it has been primarily by politics and money, egos, allegiances and alliances and whatever other orchestrated pressures could be applied by those with the self-interest and resources to do it. I think that technical excellence and/or features were very low on that list, if on the list at all.

Given that I believe there to be some good measure of truth in that first assessment, I think that tryng to compete with it on the basis of features is one of those exercises that involves noxious liquids sprayed into a moving air mass!

I think genuine technical excellence and usefulness can withstand the systemd onslaught in the identical way that other wonderful and useful Unix ideas (including SysV init) withstood the Microsoft onslaught of the 80's and 90's, to re-emerge as what we have known as the GNU/Linux/BSD ecosystem.

Competition based on "features" is actually a small player in that scheme of things.

1 members found this post helpful.

There's a choice missing - 'Almost anything *but* systemd' (I don't want to check 'other' for this because from my little understanding of these things, there's only 4 +/- that may be any good to go to *IF* Slackware actually has to at all).

Otherwise, I'm also of the camp *use what's working! - if it ain't broke, don't fix it!*. And if that fails, and systemd is used, then I too will somehow figure out how to move to one of the BSD's or LFS.

Why - please someone explain why it has to change? why is it inevitable? I'm just a newbie and I can understand how it works now - why complicate it?

2 members found this post helpful.

it's a red queen's race