Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said:> The thing which always gets me about systemd is not the thing itself, > but the way it was rolled out. When I first installed Red Hat 7, if a > window had appeared telling me about systemd and asking me if I wanted > to use it, or stick with the old init framework, I'd have opted for the > latter (as I was interested primarily in continuity from the previous > version.)That's not really practical for something as core as the init system. Trying to support two init systems in parallel, especially for as long as Red Hat supports a RHEL release, would require a massive amount of work. A distribution is about making choices and implementing them in the best way possible; for "leaf" packages like an editor or a web browser, it is easy to have multiple options (where they don't conflict), but core stuff like the kernel and init system don't leave lots of room for choice. I remember people complaining about SysV-style init too, "what's with all these scripts" and "why can't I just add a line to /etc/rc". systemd is a different way of thinking, but it isn't exactly original (Sun and Mac have similar launchers); practical experience has shown that this can be a better way of managing services. daemontools has been around forever, haphazardly implemented for some things; now that behavior is where it makes the most since (PID 1 is guaranteed to get the signal). systemd makes implementing one-off services much easier, makes local modifications of service startup better (include another service and add the line you need), etc. One note: when I talk about systemd, I mean systemd-the-init-service that runs as PID 1. I'm not a big fan of systemd-the-project, that seems to have unlimited scope creep and reimplements every wheel in sight (years of work on NetworkManager, decades of work on NTP? we can do better!). Nobody is forcing you to run systemd; you can continue to run CentOS 6 and earlier for years. But if you are a system administrator, your job is about learning and adapting, not trying to keep a static setup for life. systemd is different (just like SELinux was years ago), but I suggest you learn it. It can make your admin life easier. Is it perfect? No, nothing ever is; I do think it is a big improvement though. -- Chris Adams <linux at cmadams.net>
On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote:> Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said: > > The thing which always gets me about systemd is not the thing itself, > > but the way it was rolled out. When I first installed Red Hat 7, if a > > window had appeared telling me about systemd and asking me if I wanted > > to use it, or stick with the old init framework, I'd have opted for the > > latter (as I was interested primarily in continuity from the previous > > version.) > > That's not really practical for something as core as the init system. > Trying to support two init systems in parallel, especially for as long > as Red Hat supports a RHEL release, would require a massive amount of > work. A distribution is about making choices and implementing them in > the best way possible; for "leaf" packages like an editor or a web > browser, it is easy to have multiple options (where they don't > conflict), but core stuff like the kernel and init system don't leave > lots of room for choice. >Ultimately it's all software, and software can be written/changed/updated to do anything required - all that's needed is the skill and the motivation. If systemd is so "core" that it can't be unplugged and plugged easily, and glues together a lot of otherwise unrelated components, then it's just bad software - end of story (the problems with tightly-coupled components were first identified over 40 years ago, and modularization has been the watchword ever since.) In my view, it's high time someone independently analysed systemd down to basic code level, and understood why it's so invasive (if it actually is.) Then the way forward would be clear - fork it, and produce a new version which wasn't so invasive, and which could be swapped in/out. I'm not saying it would be easy! ("We do not do these things because they are easy - we do them because they are hard!")> I remember people complaining about SysV-style init too, "what's with > all these scripts" and "why can't I just add a line to /etc/rc". > systemd is a different way of thinking, but it isn't exactly original > (Sun and Mac have similar launchers); practical experience has shown > that this can be a better way of managing services.No one is saying that sysvinit is perfect. What I can't grasp is why replace it with something which is no less imperfect, and is almost certainly worse in at least some respects - and to make that replacement unavoidable and mandatory. I'm also still trying to figure out in what way systemd is supposed to be "better". I've seen the following things claimed for it: - faster boot time (this was apparently the main motivation behind it.) My experience with systemd-managed systems has been limited - but so far, I've not noticed faster boot times with systemd (maybe because the boxes booted fast enough previously.) - parallel startup of services. Not sure that I'd want that anyway - too much risk of two services trying to grab the same resource at the same time - I'm absolutely happy with the sysvinit approach of one service startup completing/failing before the next one happens. That way, things are nice and orderly. - better handling of hot-plug devices. I've not yet seen that in action, but that is the one thing which makes me inclined to investigate systemd in more detail.> Nobody is forcing you to run systemd; you can continue to run CentOS 6 > and earlier for years. But if you are a system administrator, your job > is about learning and adapting, not trying to keep a static setup for > life. systemd is different (just like SELinux was years ago), but I > suggest you learn it. It can make your admin life easier. Is it > perfect? No, nothing ever is; I do think it is a big improvement > though. >My job as a system administrator is to serve the users who use the servers I manage and administer, and to keep those servers and services in suitable condition for the users to do their work and earn their daily bread. As we all know (don't we just?) sysadmin work and responsibilities are heavy, and frequently eat into evenings, nights, weekends and (so-called) holidays. Anything which increases the sysadmin workload - e.g. suddenly faced with a vertical learning curve just to do the tasks they did yesterday, or a GUI which leaves them unable to find anything on their screens - is a major issue, and prejudicial not only to the sysadmin's own work, but also to that of the users to whom he/she is responsible. And when you're talking about systems used by hundreds and thousands of users, that's a big problem.
On Tue, 26 Jan 2016, Peter Duffy wrote:> No one is saying that sysvinit is perfect. What I can't grasp is why > replace it with something which is no less imperfect, and is almost > certainly worse in at least some respects - and to make that replacement > unavoidable and mandatory.Distros weighed up the advantages and disadvantages, and made a decision as to what they thought was best. They even shared their reasoning.> I'm also still trying to figure out in what way systemd is supposed to > be "better".https://wiki.debian.org/Debate/initsystem/systemd#Why_Debian_should_default_to_systemd jh
On Tue, Jan 26, 2016 at 11:51:29AM +0000, Peter Duffy wrote:> I'm also still trying to figure out in what way systemd is supposed to > be "better". I've seen the following things claimed for it:Of the three things you list, hot-plug is certainly an important one. But, it's not the big deal. The big deal is that systemd is not just a fire-and-hope startup system, but a service manager. It knows which processes came from where. That means it can: * insure that when something is stopped, it's actually stopped. (If you've ever managed an HPC cluster and had processes escape the scheduler, you know this problem is real.) * track process lifecycle, and restart (or take other action) on failure. (If software were perfect, this wouldn't be needed, but as is, this can save you being paged in the middle of the night.) * actually securely connect output to the process it came from for logging -- both stdout/stderr and actual log messages. (This is why journald is closely integrated.) There are other advantages (real dependency ordering, resource management/reservation with cgroups, etc.), but process supervision is the big deal. There are other alternative systems which _also_ do this, but overall, Fedora, openSUSE, Arch, Debian, Ubuntu, and others eventually decided that systemd was the technically best choice. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
> Ultimately it's all software, and software can be > written/changed/updated to do anything required - all that's needed is > the skill and the motivation. If systemd is so "core" that it can't be > unplugged and plugged easily, and glues together a lot of otherwise > unrelated components, then it's just bad software - end of story (the > problems with tightly-coupled components were first identified over 40 > years ago, and modularization has been the watchword ever since.) > > In my view, it's high time someone independently analysed systemd down > to basic code level, and understood why it's so invasive (if it actually > is.) Then the way forward would be clear - fork it, and produce a new > version which wasn't so invasive, and which could be swapped in/out. I'm > not saying it would be easy! ("We do not do these things because they > are easy - we do them because they are hard!")I know only one attempt : uselessd. Unfortunatly, the project is dead. http://uselessd.darknedgy.net/> >> I remember people complaining about SysV-style init too, "what's with >> all these scripts" and "why can't I just add a line to /etc/rc". >> systemd is a different way of thinking, but it isn't exactly original >> (Sun and Mac have similar launchers); practical experience has shown >> that this can be a better way of managing services. > > No one is saying that sysvinit is perfect. What I can't grasp is why > replace it with something which is no less imperfect, and is almost > certainly worse in at least some respects - and to make that replacement > unavoidable and mandatory.I agree. There are other init/service managers (no, init and service manager are not one same program) that combine the best of System V (simplicity, lightness, minimalism), and interesting ideas used by systemd ("BSD-style" dependencies management between services, for example). On Gentoo, the duo sysvinit/openrc works well, for example.> - faster boot time (this was apparently the main motivation behind it.) > My experience with systemd-managed systems has been limited - but so > far, I've not noticed faster boot times with systemd (maybe because the > boxes booted fast enough previously.)My professional experience shows me systemd is by far lower than, for example, upstart. But... let's be honest : is the OS launch time so important to make a software like systemd so revolutionary when it promises to save a handful of seconds ? On servers, which spend much more time checking and starting the hardware components than really booting the system, the difference is negligible. A bit less on virtual guests, I agree, but, anyway, they're always on, and the lonely reason to reboot them is normally to update the kernel... This kind of intervention is normally scheduled, and the announced unavailability time is often overestimated, to be able to get round Murphy's laws. Benefit ? Zero. On stations, maybe, systemd might potentially be useful. I don't know, I don't have systemd-dependant stations to hand. And I reboot my stations as often as my servers.> > - parallel startup of services. Not sure that I'd want that anywayEspecially when the obvious directives are not respected. Tell systemd to start sshd AFTER network, for exemple, but forget to say sshd REQUIRES network, and systemd starts sshd... BEFORE network ! And says network isn't started, by the way. Anyway, one more time, why this obsession to gain one or two seconds ?> - better handling of hot-plug devices. I've not yet seen that in action, > but that is the one thing which makes me inclined to investigate systemd > in more detail.Why does systemd care about devices pluging ? It's not its rule, it's the device manager's one. Udev, for example. Oh, wait...> >> Nobody is forcing you to run systemd; you can continue to run CentOS 6 >> and earlier for years. But if you are a system administrator, your job >> is about learning and adapting, not trying to keep a static setup for >> life. systemd is different (just like SELinux was years ago), but I >> suggest you learn it.So I learn... I adapt... And I update... So I learn... I adapt...>> It can make your admin life easier.But it didn't say us how, then. :)> As we all know (don't we just?) sysadmin work and responsibilities are > heavy, and frequently eat into evenings, nights, weekends and > (so-called) holidays. Anything which increases the sysadmin workload - > e.g. suddenly faced with a vertical learning curve just to do the tasks > they did yesterday, or a GUI which leaves them unable to find anything > on their screens - is a major issue, and prejudicial not only to the > sysadmin's own work, but also to that of the users to whom he/she is > responsible. And when you're talking about systems used by hundreds and > thousands of users, that's a big problem.I don't think systemd was designed for servers... But sysadmins have to deal with it though. When we need simply, robust and reliable softwares, systemd offers us lots of useless, incomplete, and buggy features, replacing other softs that really work as we expect. So we learn... we adapt... Sylvain. Pensez ENVIRONNEMENT : n'imprimer que si ncessaire
On 01/26/2016 05:51 AM, Peter Duffy wrote:> On Mon, 2016-01-25 at 08:05 -0600, Chris Adams wrote: >> Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said: >>> The thing which always gets me about systemd is not the thing itself, >>> but the way it was rolled out. When I first installed Red Hat 7, if a >>> window had appeared telling me about systemd and asking me if I wanted >>> to use it, or stick with the old init framework, I'd have opted for the >>> latter (as I was interested primarily in continuity from the previous >>> version.) >> >> That's not really practical for something as core as the init system. >> Trying to support two init systems in parallel, especially for as long >> as Red Hat supports a RHEL release, would require a massive amount of >> work. A distribution is about making choices and implementing them in >> the best way possible; for "leaf" packages like an editor or a web >> browser, it is easy to have multiple options (where they don't >> conflict), but core stuff like the kernel and init system don't leave >> lots of room for choice. >> > > Ultimately it's all software, and software can be > written/changed/updated to do anything required - all that's needed is > the skill and the motivation. If systemd is so "core" that it can't be > unplugged and plugged easily, and glues together a lot of otherwise > unrelated components, then it's just bad software - end of story (the > problems with tightly-coupled components were first identified over 40 > years ago, and modularization has been the watchword ever since.) > > In my view, it's high time someone independently analysed systemd down > to basic code level, and understood why it's so invasive (if it actually > is.) Then the way forward would be clear - fork it, and produce a new > version which wasn't so invasive, and which could be swapped in/out. I'm > not saying it would be easy! ("We do not do these things because they > are easy - we do them because they are hard!") > >> I remember people complaining about SysV-style init too, "what's with >> all these scripts" and "why can't I just add a line to /etc/rc". >> systemd is a different way of thinking, but it isn't exactly original >> (Sun and Mac have similar launchers); practical experience has shown >> that this can be a better way of managing services. > > No one is saying that sysvinit is perfect. What I can't grasp is why > replace it with something which is no less imperfect, and is almost > certainly worse in at least some respects - and to make that replacement > unavoidable and mandatory. > > I'm also still trying to figure out in what way systemd is supposed to > be "better". I've seen the following things claimed for it: > > - faster boot time (this was apparently the main motivation behind it.) > My experience with systemd-managed systems has been limited - but so > far, I've not noticed faster boot times with systemd (maybe because the > boxes booted fast enough previously.) > > - parallel startup of services. Not sure that I'd want that anyway - too > much risk of two services trying to grab the same resource at the same > time - I'm absolutely happy with the sysvinit approach of one service > startup completing/failing before the next one happens. That way, things > are nice and orderly. > > - better handling of hot-plug devices. I've not yet seen that in action, > but that is the one thing which makes me inclined to investigate systemd > in more detail. > >> Nobody is forcing you to run systemd; you can continue to run CentOS 6 >> and earlier for years. But if you are a system administrator, your job >> is about learning and adapting, not trying to keep a static setup for >> life. systemd is different (just like SELinux was years ago), but I >> suggest you learn it. It can make your admin life easier. Is it >> perfect? No, nothing ever is; I do think it is a big improvement >> though. >> > > My job as a system administrator is to serve the users who use the > servers I manage and administer, and to keep those servers and services > in suitable condition for the users to do their work and earn their > daily bread. > > As we all know (don't we just?) sysadmin work and responsibilities are > heavy, and frequently eat into evenings, nights, weekends and > (so-called) holidays. Anything which increases the sysadmin workload - > e.g. suddenly faced with a vertical learning curve just to do the tasks > they did yesterday, or a GUI which leaves them unable to find anything > on their screens - is a major issue, and prejudicial not only to the > sysadmin's own work, but also to that of the users to whom he/she is > responsible. And when you're talking about systems used by hundreds and > thousands of users, that's a big problem.So don't use it then .. EL6 has support until 30 Nov 2020. SystemD is not better, the 3.x and 4.x Linux kernels are not better, Gnome 3.x is not better, KDE 4.x is not better. Blah, Blah, Blah. Red Hat Linux 3.0.3 with the 1.2.13 kernel .. now there was an operating system. I have been doing this stuff since 1981/82 time frame, starting with AT&T Unix on an 3B system (https://en.wikipedia.org/wiki/3B_series_computers) that had floppy disks, 10 MB hard drives, real-to-real tapes for backups, and used a brand new UNIX System V (https://en.wikipedia.org/wiki/UNIX_System_V). Now, your cell phone has hundreds of times the computing power and storage and it literally fits in your front pocket. So tell me about long nights doing sysadmin. Tell me about change in the way the OS or the Desktop or the hardware works. Been there, done that. If you don't like it, every bit of the source code is available. You and everyone else who doesn't like can take that and build 'something else'. And before you accuse me of being an ass .. that is EXACTLY what I (and the rest of the CentOS team) did 12-13 years ago. That's why you have CentOS today, and that's why it's free. If you think you can do it better, then show us. Maybe you can. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20160126/226206f7/attachment-0001.sig>
Once upon a time, Peter Duffy <peter at pwduffy.org.uk> said:> Ultimately it's all software, and software can be > written/changed/updated to do anything required - all that's needed is > the skill and the motivation.Well sure, and I can build a rig to replace a wheel on your car while you're driving down the highway; doesn't mean it is practical to do so. You could also build a distribution with both Linux and FreeBSD kernels (and IIRC somebody tried with Debian), but that doesn't mean it is a practical thing, especially for a comercially-supported, long-term distribution like RHEL.> If systemd is so "core" that it can't be > unplugged and plugged easily, and glues together a lot of otherwise > unrelated components, then it's just bad software - end of storyNope. I said "the init system" is core, not "systemd". Someone building a coherent distribution has to make choices about what is practical to support (and nobody has unlimited man-hours to build magic tools that can swap out init systems with zero outside impact). And once you include systemd, there are features that it makes sense to take advantage of, rather than ignore because somebody has a "multiple init systems" requirement. Sun and Apple already figured out that a "know nothing" super-simple init didn't handle all that was really needed for a modern OS. The Linux world had some earlier attempts, like Upstart (used in RHEL 5 and 6 IIRC), but it never got the critical mass to use its functionality (and IIRC fairly early on, it became apparent it took some wrong approaches). The init system being PID 1 does have a bunch of "magic" abilities on a Unix-like system, so trying to strip it down to a minimal thing turns out to not be the best approach. Of course, a lot of the crap that is in systemd-the-package (and there is a bunch, although RHEL ignores some of that at least for now) is not in PID 1.> - parallel startup of services. Not sure that I'd want that anyway - too > much risk of two services trying to grab the same resource at the same > time - I'm absolutely happy with the sysvinit approach of one service > startup completing/failing before the next one happens. That way, things > are nice and orderly.So, the parallel startup has shown a few issues along the way, where there were undefined dependencies. There have always been dependency issues with SysV-style init - service deps can't always be described properly as an ordered list, more of a directed graph (which systemd's unit files allow and handle). Was it annoying if you encountered such a bug? Yes, but those types of bugs came up with SysV-style init repeatedly over the years anyway. You had poor solutions like init scripts calling other init scripts to make sure they had the things they needed (and "soft" deps, like on a database server, were really a mess). For example, AFAIK it is still the case that RHEL 6 and before don't enable quotas on a filesystem on an iSCSI device. The only way to "fix" that would be to copy all the quota code from rc.sysinit to another, post-netfs, script. With systemd, I'm pretty sure the same quota unit can re-trigger after new filesystems are "discovered". On the flip side, when I need to add a new one-off service, I can write a dozen line (or more often less) systemd unit file much easier than writing an init script. All the odd corner cases are handled for me, I don't have to worry about something like daemontools if I want the service restarted on fail (one line in the unit file), standard out and/or error can be redirected to log files (without having to pipe to logger), etc.> As we all know (don't we just?) sysadmin work and responsibilities are > heavy, and frequently eat into evenings, nights, weekends and > (so-called) holidays. Anything which increases the sysadmin workload - > e.g. suddenly faced with a vertical learning curve just to do the tasks > they did yesterdayOkay, but change is the only constant in this business. I agree you should not be running into the learning curve significantly on production systems, but if you are running systems with thousands of users, you should always be looking ahead to new technologies all the time. I've always worked in the Internet service provider "world"; when I started, a T1 and a router you could fit in a backpack made you an ISP. Now we have a router that is a third of a rack, requires a lift to move, with a couple of 10 gig ethernet links to the world, and that's still considered a "small" ISP. It is so much easier now to lab up new versions for testing and learning (just fire up some VMs). If you want to have an idea of "what is coming", run some Fedora releases now and then. I personally have used Fedora on my desktop since the project started (and Red Hat Linux for many years before that). It is called professional education; lots of jobs require you to learn new skills on an on-going basis. I've been running CentOS 7 on all my new server installs for a year now. Is it perfect? No, but I haven't seen the perfect OS yet. Am I still learning? Yes, always. Do I think it is worth the higher learning steps than say from CentOS 5->6? Yes, I do. -- Chris Adams <linux at cmadams.net>