What Are The Differences Between Systemd And Non-systemd Linux Distros?

Home » CentOS » What Are The Differences Between Systemd And Non-systemd Linux Distros?
CentOS 32 Comments

Good afternoon from Singapore,

What are the differences between systemd and non-systemd Linux distros?

Is systemd implemented in all the latest Linux distros?

Please advise. Thank you.

==

32 thoughts on - What Are The Differences Between Systemd And Non-systemd Linux Distros?

  • I really think you are asking in the wrong place – this, in case you hadn’t realised, is a mailing list for CentOS Linux. It is not a general Linux mailing list. Although many people here are very knowledgeable about Linux, general questions about Linux really must be classed as off-topic.

    P.

  • My advice is to go and read up on the original design goals of systemd. 
    The information is out there.  We had this discussion here years ago when we were staring and the impending transition.

    Read the archives on the angst the change engendered and the adjustment to the new methodology.

    They say that the Internet never forgets, so you should be able to find the original discussions and make your own judgment call.

  • Systemd is implemented in all the major distros, if you want to find ones that don’t search for non-systemd.

    Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
    2220 Bush Dr McKinney, Texas
    75070
    http://www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here
    . If you prefer not to be contacted by Harris Operating Group please notify us
    . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

  • Hoping to not offend proponents of systemd/firewalld…

    Linux kernel is already containing chunks of code related to systemd/firewalld and friends. One can disable stuff during kernel build, but the result it still is not like the result of building kernel before the existence of systemd/firewalld. Also, it is likely that at some point systemd-free Linux distribution(s) may fade away.

    That said, if one is strongly willing to stay away from systemd, and not to such extent into Linux as to needing an advise on that, I would recommend to take a look at non-Linux system, specifically BSD
    descendants (FreeBSD, NetBSD, etc). Their kernel is not as heavy
    (big,resource demanding) as Linux kernel, and you can do pretty much everything one needs (except maybe computer games, although these will fall mostly into MS Windows scope). I for one have FreeBSD on my laptop
    (with alternative boot into Debian, the last being systemd though…).

    I hope, this helps.

    Valeri

  • Troll bait removed.

    Congrats, folks. You fell for it.

    This was also troll-posted to fedora-users within seconds of this post.

    John

  • Perhaps if you weren’t spreading misinformation, we wouldn’t be offended?

    None of this is true. It’s true that systemd uses some Linux-only features like cgroups, but I was using those features well before systemd came around. And firewalld uses Linux only specific features too — it manages the NETFILTER rules which is a linux-specific project. The only thing that seems to be in common is that they are both projects that end with ‘d’. I suppose you’re going to start claiming that SSHd, HTTPd and NTPd are up to no good.

    There was already a move away from SysV init before systemd was introduced, heck RHEL6/CentOS6 used Upstart instead of SysV. There are always going to be projects with a diverse set of tools, it just depends on how many people care about it. Turns out, not that many people care about maintaining a SysV init (or other init) distro.

  • I’m not sure that that necessarily follows. Among RH-ecosystem distributions, and specifically RHEL derivatives, there’s a barrier to the usefulness of smaller projects given that a large chunk of the users need binary-compatible commercial equivalents, or at least vaguely commercially supported ecosystems. We’re long past the days where WBEL
    and other hobbyist projects can probably gain traction. Those RHEL
    alternatives that do exist either have a long history (CentOS, even before the RH deal), or are supported by large entities: the government
    (SL, before it became more or less congruent with CentOS), a multi billion dollar company (OEL), or a trillion dollar company (AWS). SuSE
    Enterprise might be the best counter example here.

    Also, while EL6 did move from original init to upstart, that’s somewhat beside the point. Almost none of the advanced features from upstart were used, and – crucially – the startup sequence was still handled with grokkable, imperative scripts. The jump from EL6->EL7 was night and day compared to EL5->EL6.

    -jc

  • It was also troll-posted to ubuntu-users, this is certainly not the first time this user has done so, and AFAICT he has never responded to people asking questions about his initial posts. Can a list moderator please remove this user and block him from returning (or, perhaps, leave him subscribed but disable posting)? He’s pretty clearly a troll.

    –keith

  • Not that I disagree with the thrust of what you are saying but it seems to me that SUSE is not so much a counter example. The SUSE subsidiary of Micro Focus is, in and of itself, a multi-billion dollar company. It was valued at $2.535 billion when its sale to EQT Partners was agreed earlier this year.

    It seems to me that what you say in your first paragraph above applies not just to RH-ecosystem Linuxes but probably to all corporate-focussed ones in both the RH and SUSE ecosystems.

    It’s mainly the Debian world where it seems to me that there is still room for smaller entrants (including at least one healthy non-systemd one).

  • I’ve listened to the video and no, it doesn’t say any such thing. The video does not say that BSD is going to use systemd.

    What the speaker in the video certainly does point out is that service and system management is a good thing overall and that there are better ways of doing this than SysVinit. However, most people have not disputed this.

    A lot of people, including very many of those who greatly dislike systemd, accept that SysVinit could and should be replaced or improved upon. It’s just that they do not think, for a variety of entirely legitimate reasons, that systemd is the right software to do this. Even on Devuan, for example, many people prefer to use init software other than SysVinit.

    The speaker says, amongst others thing, “what I find amusing occasionally is that a lot of people who bitch about systemd, don’t bitch about launchd but I find that funny because systemd is launchd in concept” but he should not be surprised. The people who complain about systemd are doing so because (a) launchd is not being forced on them as systemd is in practice (in their view), and/or (b) because they disagree with systemd’s specific architectural choices and/or their view of its quality.

    I should add that the speaker also massively over-simplifies opposition to systemd on the basis that he incorrectly perceives it to be opposition to change. He seems to ignore the fact that, as above, there are substantive objections to the specific architecture and quality of systemd, not merely objections to change with no deeper reason. He further seems to ignore the fact that many people objecting to systemd would nevertheless favour more modern system/service management.

    The speaker goes on to give his reasons as to why bringing service and system management to BSD is a good thing. As I point out above, many people could well agree with this, even many people who dislike the specific implementation of systemd on Linux.

    To be clear, objections to systemd on Linux largely seem to me to be about the specific implementation and perceived quality (and, dare I say it, personalities), rather than either fear or change or objection to modern system/service management.

    The speaker explicitly points out: “What can we [BSD] get from systemd?
    I’m not saying that we should adopt it […] I don’t think that trying to directly adopt system is going to work for us”. He then goes on to point out why implementing a BSD kernel-based systems/service management component that is inspired by some of systemd’s advantages (or, to put it another way, the advantages that any modern system/service management facility could and should offer) would be a good thing. As I say, many people, including many systemd-doubters or haters, would not object to this.

    He is not, however, saying that systemd will be used on BSD. He’s just saying that the principles of system/service management are good ones and that software other than systemd could implement them. And that’s exactly what a lot of systemd’s critics say, too.

  • This is indeed good news (that BSD isn’t necessarily going to adopt systemd).

    Leroy Tennison Network Information/Cyber Security Specialist E: leroy@datavoiceint.com
    2220 Bush Dr McKinney, Texas
    75070
    http://www.datavoiceint.com TThis message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here
    . If you prefer not to be contacted by Harris Operating Group please notify us
    . This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

  • Try doing without launchd on macOS.

    If you think that’s irrelevant, count the number of MacBooks at the next FreeBSD conference you attend.

    For an init system to gain sufficient momentum, it must be the default, with no easy way to avoid it. Without that, you get things like:

    1. TrueOS, where major non-core services still have no OpenRC script despite OpenRC being the default for about a year. There were no Samba or NUT OpenRC scripts the last time I tried TrueOS, for example. Even if that’s changed, it’s still a reflection of the fundamental barrier to adoption that I’m talking about here.

    2. Lazy third-party Linux packages that still use SysVInit scripts, because they’re just forward-porting old packages with minimal effort.

    While there certainly are objective problems with systemd’s design and implementation, it is basic human psychology that many people will not move to a newer system despite piles of advantages.

    The major BSDs are fundamentally conservative at the project management level, so I believe this tendency is stronger in the BSD user population than elsewhere in the IT world. It’s a form of self-selection bias: the BSDs are run conservatively, so they attract a user base that is also technologically conservative, from which come the next generation of core developers, who therefore continue to run the project conservatively. Consequently, the major BSDs are even more conservative than the Enterprise Linuxes.

    If it were otherwise, TrueOS would have long since taken over the FreeBSD world, and nvi wouldn’t still be missing proper UTF-8 support.

    I’d love to see that quantified.

    Alternatives to the BSD rc init system are readily available, yet I think if you were to survey actual use, you’d find that over 99% of BSD boxes use the stock init system.

    Change has to be forced from the center out on this kind of thing. Diffusion from the outside in takes too long.

    The question in my mind is how long it’s going to take for the major BSDs to make such a change at the center, so that the majority of new installs will use a modern init system. The systemd project started in 2005, and wasn’t widely deployed as the default until about 4 years ago. If past is prologue, I think this won’t happen on the BSDs for another decade or so, if ever.

    Example: FreeBSD is just now moving to pkg-in-base in earnest, giving it features I first saw in the default install of Debian in about 1995.

  • That’s Mac. It’s not Linux. And that’s the point. Mac does not have Linux’s very particular culture and history.

    Apple and oranges, and all that. Sure, launchd is an init system but it’s not on Linux. If launchd was on Linux and it had systemd’s cultural issues and, in many people’s views, technical issues then the opposition to it would be identical to the opposition to systemd.

    When people go to Mac they accept what it is (mostly). That’s a fundamentally different culture to Linux (or BSD for that matter).

    That’s an argument for authoritarianism, which seems to me to be anathema to the overriding culture of Linux. Can you see why many people might dislike the personalities involved with systemd, yet, when such an argument is used in favour of systemd? :-)

    Quite true but the fact that some people do dislike change (a) does not make the substantive and objective problems, in many people’s views, with systemd any less real or important and (b) does not mean that the speaker did not massively over-simplify the opposition to systemd , i.e. he effectively claimed that it was all to do with fear of change when, as you agree, there in fact are substantive, real and objective issues which are widely recognised.

    An interesting observation. It seems to me that there are aspects of the Linux culture that are at least as conservative as the BSDs in this context (are perhaps shared with BSD). One of these aspects is the “do one job and do it well” expectation of componentisation. In many people’s views, systemd wilfully and unnecessarily tramples all over this cultural/technical requirement. If this is the case in many people’s views, then it makes a lot of sense that hey are unhappy with it.

    None of these comments (neither mine nor those of the speaker of the presentation) are easy to quantify. I can only say that I base my comments mainly on the contents of technical mail lists and blogs and similar and I have very frequently observed that (a) a common question is how users can change init system to something other than either systemd or SysVinit (depending on whether they are starting with a Linux that is normally with or without systemd), and (b) there does seem to be a very common thread that the time had come that something needed to be done to update SysVinit but that systemd definitely should not be it
    (and that the solution, whatever it was, should not have been introduced in the way that systemd was).

    That’s a different metric. People may well stick with the stock init system but that doesn’t mean that they like it or really want it.

    Again, an appeal to authoritarianism. Excuse me if I don’t wish to join you on that. Authoritarianism, in all its forms, is dangerous and, in my view, a form of vandalism.

    Also one might ask: What centre? This is the world of Linux. Many people don’t recognise any centre, and quite sensibly so. Indeed, they use Linux explicitly to avoid the centrism of the likes of Linux or Apple.

    As I observed above, this authoritarian centrism in in part why systemd is so despised. It was effectively forced on a great many users in in a centrist, choice-limiting manner. A great many people regard this as a bug, not a feature. I think they might be right.

    That’s up to them and their users, isn’t it. Just because it’s a good idea doesn’t mean it has to be done in a hurry. This was and is one of the problems with systemd on Linux.

    —
    Mark Rousell

  • Every couple of months we seem to get a systemd usage discussion on this list.

    But really, discussions whether to use systemd (or anything else in the RHEL source code) really isn’t appropriate here .. because, we rebuild what is released as source code for RHEL. If Red Hat decided to shift from the Linux Kernel to the Windows 10 kernel (or the Free BSD Kernel, or a Mac OS Kernel or whatever).. and if it was open source .. then the CentOS kernel would shift to that as well. CentOS is a rebuild of the RHEL source code .. therefore, it will contain whatever is released in RHEL in our base OS.

    Also, someone said we were ‘forcing’ them to use something they didn’t want to use. That is actually quite hilarious .. since CentOS is completely free and no one HAS to use it for anything at all. It is also open source .. so you can use only the parts you want, and build and use anything else with it that you want if you don’t like certain pieces of it.

    The bottom line .. we don’t make the decision whether or not to use systemd or not. We rebuild RHEL source code.

  • Try this gedankenexperiment instead: what if RHEL 7 shipped based on launchd instead of systemd, with no differences relative to the version shipped in the contemporaneous version of Mac OS X?

    I’m uncertain as to whether the opposition would have been as great, but I’m dead certain the opposition would have been vociferous and strident, because Linux, though less conservative than the BSDs, is much more conservative than macOS.

    The systemd vs launchd vs sysvinit vs whatever-else arguments are more about human factors than about technology, even though they’re usually couched as technical battles.

    I doubt most Mac people even know launchd exists, much less have an informed technical opinion about it. And of the small minority that do have such an opinion, it almost certainly doesn’t drive buying decisions. Maybe that’s what you mean by accepting macOS as it is.

    The thing I don’t get is, why is it different in the Linux world? Why did we in the Linux community spend so much time arguing about systemd over the past several years? Why is it still an active topic five years after the key events? And why is the BSD community continuing to stir the pot?

    Here’s what I want to see: I want one of the BSDs to clean Linux’s clock with a thoroughly awesome modern init system that makes us Linux fans so jealous we start noisily advocating to replace systemd with it, much as ZFS is starting to replace the horrid lash-up that is ext4/xfs+md+LVM+DM.

    What I *don’t* want is more of this retrenchment to SysVInit. I liked it well enough within its limitations, but we can do better in 2018.

    (It’s a related tragedy that a slightly modified ksh88 remains the most powerful general purpose scripting language mandated by POSIX three decades after it was released by AT&T. We’ve got better alternatives here, too.)

    I call it leadership. Working code argues best.

    Benno Rice is right: Lennart Poettering gets stuff done.

    In the BSD world, they call the opposite tendency bikeshedding. You can find a thousand people willing to argue about why something shouldn’t be done, or why it shouldn’t be done *that* way for every person capable, willing, and available to write a given piece of software.

    For all the complaints about systemd over the past several years, I note that there is still no fork of CentOS 6 or CentOS 5, keeping the prior init system(s) but updating their package set to recent versions. Many would rather gripe about change than put in the work it takes to maintain the status quo.

    Then you get the crowd that tries to argue that we should just stay with what works, apparently under the misapprehension that staying in place is a zero-effort choice, when in reality it is at best an accrual of technical debt; the bill will come due eventually, with interest.

    I suspect these two groups overlap quite a lot, inconsistent though the combined position is.

    Of course not, but I also don’t see a lot of effort going into replacing systemd with something better. Most of the effort opposing systemd seems to be going into anti-systemd advocacy campaigns, plus a tiny slice off to the side going into retrenchment to SysVInit. That’s conservatism, plain and simple.

    I suspect that for many people, those are rationalizations rather than reasons.

    I saw much the same sort of logic in the Unix vs Linux wars, roughly spanning the decade surrounding 1996.

    The Big Iron Unix and SCO Unix fans had all kinds of myopically rational reasons why Linux wasn’t going to replace their OS of choice: journaled filesystems, better SMP, STREAMS, hot-swap hardware, real ksh93 instead of that cheesy nonstandard imitation Bash…

    The analogy I used at the time is that the Unix fans saw Linux surfing behind their big yacht and laughed at the tiny, flimsy, cheap little surfboard, not realizing that it would take an awfully big wave to allow someone to be surfing out in the middle of the ocean. We’ve been skimming the splinters of that yacht off the surface of the sea for decades now.

    Like the Linux wave, the systemd wave took years to build beneath the surface. If you perceive that it broke fast, it’s only because you weren’t looking in the right places, where you could see and even help direct that long build-up.

    You can spend your time rationalizing against systemd while it sheds enough of its weaknesses and gains enough features to sweep the planet. You’re years late if you want to stop that from happening, but I believe it can be done, just as systemd replaced rc files, SysVInit, and Upstart.

    It’ll take a lot of hard work, but it can be done.

    That’s never been an especially hard and fast rule. Witness Emacs, Perl, GNOME, Firefox, ZFS…

    My DVCS of choice is Fossil, which is about as far from the “small pieces loosely joined” philosophy as you can get, from which comes much of its power and simplicity. Fossil’s primary opposition is Git, which is famously difficult to understand and use properly, even though it adheres perfectly to that philosophy.

    (Incidentally, I’ve spent a fair bit of time in recent months making Fossil work better, so my calls to action in this thread are not just me proposing work for other people to do.)

    I *want* my init system to build a dependency graph and maintain that graph at run time. I *want* it to start services in parallel, consistent with that dependency graph. I *want* it to restart services that die unexpectedly, with exponential back-offs. I *want* it to have sensible answers to a “status” command without having to write the shell code to dig that that status out of service-specific files. I *want* my service definition scripts to be 15 lines, rather than 150. I *want* to be able to start services as a normal user, with all of the power of a real system service, limited only by OS permissions, without needing sudo.

    That puts an awful lot of code into a single place. It is not small pieces loosely joined. What it *is* is powerful.

    I’m not a particularly big fan of systemd. I agree with much of what its opponents dislike it for.

    The only reason I enter these arguments is that I feel the need to fight against the complainers, because I’d rather see opposition deflected toward a replacement.

    Give me a better option, and I’ll happily switch to it.

    Tricky bit: “better option” is evaluated on a systems basis, not on a per-feature basis. If the combined system doesn’t provide most of CentOS’ key virtues, as I see them, it isn’t a better option.

    If you ask why I don’t just write something better myself, it’s because I don’t care enough about the Linux init system to do that, so I’d rather spend time advocating for and taking advantage of systemd’s features than complaining about its weaknesses.

    (Automatic service restarts saved me a lot of work just a few weeks ago!)

    I’m also unwilling to stick with increasingly poorly supported technology. If the cheese moves, I’m following the cheese.

    That’s a large part of my point: if you are unable or unwilling to take the time to replace a thing, why bother spending time griping about its weaknesses?

    Talk about a first world problem: Oh, waaah, my automated software management service isn’t ideally designed. Woe is meeee!

    It’s much like my macOS argument above: CentOS sucks in many ways, but I have no good answer to the “What’s better?” question for the applications where I use it. I’m not going to spend a bunch of time listing all the ways CentOS sucks: either I’ll fix the problems myself, or I’ll work around them, or I’ll ignore them.

    Notice that putting up with systemd is only one of your several choices. The FOSS ecosystem advances every time someone scratches an itch. My objection is that we’ve got all these people claiming to have itches, but very, very few are scratching.

    In what useful sense do you believe you own the parts of CentOS affected by the move to systemd? It can’t be vandalism otherwise.

    Intellectual property is no answer in the FOSS world, since that implies that you’ve relinquished the relevant rights already, so you have little to no say in how the wall gets reshaped, if in fact you built it in the first place.

    I suspect it’s more that you found this free wall just sitting around online, and no one was guarding it, and in fact there were people offering you free copies of the wall, as many as you want, so you started making buildings out of these walls. Then someone changed the wall generator to produce differently-shaped walls, and now you’re upset that the walls aren’t the same any more.

    I get it: you’re annoyed. What I don’t get is why you believe your annoyance should, of itself, effect a change in the world.

    FOSS is a do-ocracy: he who does the work makes the rules. If you want the wall to be shaped differently, and no one is making new walls with that shape any more, go make your own wall, or maintain an old wall that was already correctly-shaped, by your lights.

    In this case, I think the lowest friction path is to fork CentOS 5 or 6, then backport as much of the feature set as is possible without dragging in systemd. No one’s done this, despite having over 7 years to react, dating from systemd’s deployment as the default init system in Fedora. Why not?

    The closest thing I’m aware of in the Linux world is Devuan, which was low in popularity a year ago and has been dropping ever since:

    https://distrowatch.com/dwres.php?resource=popularity

    According to the same stats, CentOS is pretty stable, which I find appropriate. :)

    In this case, the one currently headquartered in Raleigh, NC, USA.

    If you want a different centre, pick one, or be your own. That’s why we have several major Linux flavors and hundreds of Linux distros.

    Centralized control is clearly not the key problem here, since so much of this anti-systemd sentiment is coming from the much more centralized BSD camps.

    Centralized control didn’t do the Big Iron Unix vendors much good. A better thing came along and wiped them out. The thing is, a whole lot of programmers went to a whole lot of effort to make that happen. Are you going to do more than post to mailing lists in an effort to wipe out systemd?

    You also didn’t get a choice over SysVInit vs BSD style init, short of switching from Red Hat to Slackware. So what?

    Someone has to make a decision. We call those who do this often and well leaders.

    Leadership is not central control or authoritarianism: we get to choose which leaders we wish to follow.

    Don’t like where Poettering is taking his slices of the Linux world? Fine; follow someone else who is taking equivalent slices in a direction you like better. Or, be that someone!

    The first version of systemd was released in 2010, and it wasn’t deployed “for real” until RHEL 7 came out in 2014, as far as I’m concerned. I don’t call that “in a hurry.”

    This in a world where Linux’s major competition all had systemd-like service management by around 2005:

    – Solaris 10 came out in early 2005 with the Service Management Facility (SMF), which is very similar to systemd’s initial feature set.

    – Several months later, Apple shipped Mac OS X “Tiger” with launchd replacing init(8).

    – Microsoft, ever late to the party, shipped the last major piece missing relative to the above about 18 months after Tiger came out, adding delayed-start services to Windows Vista.

    (This is probably where the “2005” in my prior post came from, by the way. I thought systemd got started earlier.)

    So yeah, systemd finally let Linux catch up to Vista in the area of background service handling, an area where Linux is supposed to be superior, but it’s all happening too fast?

  • With all due respect, many people just stopped offering any argument about systemd, and simply fled elsewhere which in _their_ opinion (and I
    am one of them) lies better in what they with their education and life experience is more reasonably resembling system suitable for servers.

    Servers are key word for me. You can see me using macintosh laptop in variety of places, that doens’t mean MacOS will be my choice for server, so don’t count laptopls into any statistics. The same is true about a bunch of other sysadmins I know, who mostly use Apple laptops, whereas run Linux, or UNIX-like, or [truly] UNIX servers.

    To add to the “refugee” camp recognition, there are Linux refugees who left even earlier for different reason, so they don’t even care so say aloud what they think of systemd (or don’t care about it at all).

    Valeri

    —
    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Valeri Galtsev wrote:

    Because he’s funded. And I strongly suspect that a lot of that funding comes from M$’s interest in Upstream.

    Actually, I’ve got CentOS on my 9 yr old Netbook, that I use while traveling. Otherwise, my home workstation is CentOS 6, and I am NOT
    looking forward to EOL.

    But Valeri’s correct: people are tired of screaming and yelling about systemd, because we’ve had years now of the response being “tough, it’s the Wave of the Future”, and Poettering is like upper management: they know, I mean, Everything, so why should they need to talk to end users (or working sysadmins)?

    Lack of screaming and yelling filling this venue is more because “what’s the point?”, and we have to get work done.

    mark

  • [topical reply trimmed for brevity]

    Please learn how to trim your replies. Rough count and 145 lines of crap could have been removed from your recent post. This is getting a bit ridiculous, Valeri:

    https://wiki.CentOS.org/GettingHelp/ListInfo

    Fourth item, top section “CentOS Mailing Lists and Posting Guidelines”

    Note: do not reply privately to me with yet another flippant reply;
    please read and adhere to the published guidelines for this and other CentOS.org mailing lists.

    John

  • There are plenty of people with jobs that don’t get stuff done.

    Soooo…systemd is a Microsoft conspiracy against Linux?

    That’s what I meant with my comment about the technical debt bill coming due. You can’t ignore the changes in the external world forever.

    The OpenSSL issue brought up in a prior post is another example of the same basic problem.

    We covered that back when RHEL 7 was still in beta: the time is far too late to change the init system of RHEL 7. The fact that you’re tired of being ignored doesn’t enter into it: you could still be yelling about it, and it still wouldn’t change. Red Has simply isn’t going to swap out its Enterprise Linux init system within a major release cycle.

    I believe it’s certain that RHEL 8 (and thus CentOS 8) will also be systemd-based, since we’d be hearing about the change by now via Fedora if it were otherwise.

    Those of you who want a systemd-free CentOS-like OS to be available before CentOS 6 hits EOL are going to have to see to that yourselves. You cannot expect it to just drop from the sky.

    The suggestion that Red Hat is not listening to working system administrators beggars belief. That’s pretty much the basis of their company’s major income stream.

    What Red Hat is not doing is filling every demand from all working system administrators. They’re choosing which demands to address, as any software project management must.

    Red Hat has certainly heard the screams of the reactionaries. Since that hasn’t changed anything, I believe you have your demand’s answer. So, what are you going to do about it?

  • *** This response is my personal opinion and may not reflect that of my employer. ***

    After spending the last year and a half preparing a major CentOS 6 based appliance for the upgrade to CentOS 7, I can say when I started the project, I was very much in the “I hate systemd” boat. It was new, different and a drastic change from what I had become accustomed to. I have spent way too many hours cursing systemd, converting init scripts, and handling the different way it does things (like Java app daemons retuning non-zero exit codes for clean shutdowns). Now that I have spent the time getting very intimate with systemd, making it do what I need it to, and learning some of the neat tricks it has up it’s sleeves (like the xxx.mount definition files), I actually have come to appreciate it, and the power it contains.

    Is the conversion from sysVinit/Upstart services simple and easy? Not in the least, particularly if you are used to the simplicity involved with dropping a launch script in the /etc/init.d/ folder. Does CentOS 7 make allowances for some of this pain? Yes, it still processes the /etc/init.d/ folder in order to allow legacy services to launch as pseudo systemd services. Is it a perfect workaround? Not at all, otherwise I would have had no reason to convert all our services to systemd, and my project would have been done a year ago. Will there ever be a way to automate upgrading a CentOS 6 system and services to CentOS 7 or 8 (like was asked in another thread this week)? It might be do-able for a very basic file server, or possibly even a web server, but with the wide variety of services run on top of CentOS, there would be no foolproof way of automating the process. If someone was to spend the time to create an automated tool to convert init scripts to systemd services, I have a feeling their life would become an unmitigated hell trying to accommodate all the corner cases out there where a simple conversion won’t work (and we all know how people love to complain that free software doesn’t do what they need it to do for corner case #65,535, and therefore the developer who spent their own time writing it to fill the need their project had, should donate their own time to make it work for corner case #65,535).

    If CentOS 8 were to switch back from systemd, I think you would be able to see the explosions from Alpha Centauri as all the developers out there lost their minds after spending all this time converting their apps to work with systemd. If you don’t like change, you are more than welcome to go back to using Windows XP (as too many businesses still do because they don’t want to spend the time and money updating their LOB software), I’ll guarantee you the script kiddies and crypto-criminals will love you.

    Greg

  • Hi,

    A lot was already said but let me underline a few things from my personal point of view:

    – the upgrade path from EL6 to EL7 is completely broken.

    That’s certainly a good thing for upstream, because they can sell even more support and training. I don’t blame them for trying to make money, I
    just say from the technical point of view it’s not the best solution.

    For home users it doesn’t hurt too much but for the enterprise market it’s bad. Migrating complex systems is a huge amount of work and takes a lot of time and manpower. In the end it means higher costs.

    – the migration to systemd is not really finished carefully in EL7.

    Just look into upstream’s Bugzilla and see how many issues still exist and will probably not be fixed.

    I show you a simple example: we happen not mount some NFS filesystems on servers like this in /etc/fstab:

    ftp:/var/ftp/pub /mnt/nfs nfs bg,soft 0 0

    Now, with every Linux since the last millennium one could simply bring down the system into maintenance mode with ‘telinit 1’, and all worked fine. Now try the same with EL7, do a ‘systemctl rescue’ or ‘systemctl emergency’ and see what happens. With lightning speed it does the wrong thing, brings down networked services, brings down the network, and doesn’t unmount the NFS filesystems. Then try a ‘df’ or ‘lsof’ in rescue mode, it all hangs.

    Of course I found a solution, mount it with the option
    ‘x-systemd.requires=network-online.target’ and it behaves correctly. But really, it’s broken, because it’s always clear that NFS mounts always only work WITH network!

    That’s just a single small example how things don’t work as expected.

    – migrating from EL6 –> FreeBSD seems easier than migrating from EL6 –>
    EL7, IMHO.

    That’s really an important point, because those who started using Linux with Linux/systemd will be bound to Linux/systemd with their knowledge, switching to a *BSD or other Unix will be difficult. For me, I don’t like to be limited in such ways.

    In other words, systemd is a new operating system which still lacks a kernel :-)

    One thing I know for sure: if the *BSD folks were ever going to invent something like systemd, they will do it in a way which hurts less.

    Regards, Simon

  • Having worked with the init systems in a bunch of different distros, I
    really *loved* having to write a different SysV init script for debian and RHEL, using different functions and different styles. Also, don’t forget to actually package the Red Hat init scripts as
    /etc/rc.d/init.d/, because /etc/init.d is a symlink, while on debian it is the actual location, and if you weren’t careful, your package would create an /etc/init.d directory and suddenly it’s not even found by the init system.

    Oh, and as for ‘grokkable’ shell scripts used by init, they bear only a passing resemblance between distros, they even differed between releases of the same distro, making it so you had to learn a different weird init system for each distro. Heck, there was even an argument about which shell they’re run with. And it was always fun when shell bugs cropped up in init scripts. A vendor writes an init script using bash features that aren’t in another distro, but it still uses the
    #!/bin/sh shebang so you get really weird and difficult-to-diagnose startup errors.

    And heaven forbid you actually want to *SEE* any shell errors. Nothing is ever captured in any logs, you have to be physically looking at a console (be it a glass terminal or serial line) to capture the error.

    So, yes, people starting to use systemd won’t know about having to do that. They’re also not custom-crafting Modelines in their XF86Config file for a monitor that uses weird undocumented, non-VESA parameters, nor are they trying to track down the right interrupt to run their network card so it doesn’t interfere with their sound card. I’m sure we could create a whole book of all the annoyances with older Linuxes that have been largely solved.

    I don’t see systemd as the end-all, be-all init system, I just think it’s heading in a good direction. Its important to provide feedback like people have on this list, although people in the CentOS community really ought to provide feedback to the upstream communities.

    Here’s a good example for me: In other systemd-based distros, they’ve got the systemd –user enabled (RHEL/CentOS have it patched out). This breaks a lot of our use case because the systemd developers don’t think that different sessions of the same user are distinct, so they want to use systemd –user to manage user processes. This breaks if you use session-based authentication services like Kerberos. systemd
    –user tries to start up processes outside of your PAM session, so it won’t have access to your kerberos tickets. And of course, Gnome Terminal now uses a gnome-terminal-server process to be the parent of all terminal sessions, started by systemd (as your user, on behalf of PID1). So you log in, start up a terminal, and it doesn’t have any Kerberos tickets. Now, what happens if you happen to use an NFS v4
    volume for $HOME, which uses Kerberos 5 for authentication? Now not only does your terminal not have tickets, but IT CAN’T EVEN REACH
    $HOME. And of course, systemd –user wants to read and write files in
    $HOME, so the whole thing is broken.

    What do the systemd developers say? They want it so anyone who becomes your $USER should just automatically have access to your Kerberos ticket cache, so systemd can work. This is actually breaking from the way Kerberos has worked for decades. And it seems that the systemd developers have just decided that their way is better. But I’m going to keep pushing back.

  • Under what conditions would you actually use it?

    As we can see from the repeated attempts to get a reliable in-place upgrade process working, the community doesn’t seem to have much interest in the idea:

    https://lists.CentOS.org/pipermail/CentOS/2018-October/170379.html

    I believe this is because in-place upgrade is antithetical to the idea of a “stable” Linux distro in the first place. Once something’s configured and running, you just want it to keep doing so.

    In my world, OS upgrades are generally paired with new hardware or VMs.

    I did just this on an Ubuntu VM recently, which does have an in-place upgrade system. I’d been ignoring its motd offers of upgrade for years, on purpose, and only upgraded it from 14.04 LTS to 18.04 LTS when I needed to rebuild the VM anyway.

    That’s why I was on an LTS release in the first place: to give me the years of stability that let me batch the changes up into a single big-bang upgrade. CentOS is even better in this regard, with version lifetimes up around 10 years, rather than 5 for Ubuntu LTS. One of the reasons I chose to upgrade it recently was because Ubuntu 14.04 is about to fall out of support, so it was time to move.

    I believe a lot of the antipathy toward systemd is that people want “LTS” to be forever. That’s not going to happen until the rest of the world stops changing. That would be a very sad thing: it’s basically a wish for stagnation.

    If upgrading via separate hardware or a new VM is difficult, it calls into question the usefulness of your backup and restore strategy.

    Another advantage of this style of upgrade is that you have the prior box online and ready to fall back to if the manual upgrade fails. If an in-place upgrade fails, you’ve just lost the primary.

  • Today’s software project is going to take me all day, and it’s largely going to amount to reinventing systemd template units, since the software has to run on non-CentOS 7 boxes. I’d be done in an hour if I could just use template units.

  • *snip*

    I think think some of the opposition to “switching back” misses the point. IMO there’s nothing particularly wrong with systemd as a service manager, so folks wanting to use it as /just/ that (which accounts for the bulk of what SysV-style init scripts from vendors do) could still use it if they wanted. Initscripts work fine for traditional C unix daemons, but lots of other ecosystems (looking at java) are better served with other management systems. Disintangling from systemd’s overall paradigm doesn’t necessitate forcing everyone to write initscripts again for their own daemons.

    -jc

  • The first time I had to look at SysV init scripts on a Debian/Ubuntu box my eyes bled; if systemd had begun from that ecosystem I definitely would have understood its formation a bit more. But on Red Hat-derived distros, an initscript for a basic daemon is pretty simple and mostly boilerplate: copy/paste the sample file, maybe decide what you want to make tweakable in /etc/sysconfig/, then (if desired) build an RPM
    according to best practices.

    Virtually everything you might need that isn’t provided by the
    ‘functions’ file is going to be your own custom logic for your own daemon, and it turns out that that usually doesn’t change in a systemd landscape, resulting in a lot of workarounds, wrappers, and shell bits in unit files which would probably be more predictably understood in a single shell script to begin with.

    Building a single init script that works across ALL Linux distributions
    (and other unices) is indeed painful and ugly, so if a vendor wanted to make a declarative config file and wash their hands of, that’s understandable. But the same goes for an xinetd.conf snippet, or any other service manager of the same ilk. And making a boilerplate /Red Hat-specific /init script is trivial.

    That’s a larger *nix issue. As a proponent of dash on EL systems, I
    definitely think ensuring bashisms are called out and that /bin/sh means
    /bin/sh is probably a Good Thing.

    The /sbin/service command is just a shell script. I’d suggest a patch to send stderr/out to logger as well if I thought it would be accepted.
    (And *manually executing* an init script with direct call was something we were already supposed to be deprecating; the service command was the standard environmental interface.)

    Frankly, I’ve had a lot more problems debugging mysterious systemd-based startup failures than I ever had in a properly-written Red Hat init script. (Again, vendor-agnostic init scripts can be hot messes, but that’s them…)

    -jc

  • Japheth Cleaver wrote:

    Yeah. I have trouble finding the actual startup configs –
    /etc/systemd/system? /var/lib? whereeverthehell they are, do a locate…. as opposed to /etc/init.d to find the damn name (nfs? nfsd? idmapd?
    nfs-idmapd? rpc-idmapd?)

    mark