I haven't had any problems with systemd. However, I didn't have any problems with sysVinit over many years.
But the only practical advantage of systemd that I've seen touted is that it speeds up boot-time. Even if this were true it does not seem to me worth worrying about, as - in my case at least - the frequency of re-booting is so low that even if it took twice as long it would still be a negligible fraction of my time.
In fact I've been running CentOS-6.5 and CentOS-7 off and on for the last few days, and I have found no difference in boot-time. It takes my HP MicroServer 80 seconds to reboot and login, and at least 65 seconds of this is taken up with messages from HP's BIOS, checking USB devices or ports, checking PXE devices (I know I could probably turn this off), and starting up KDE.
So I find this particular argument for systemd null and void.
As far as I can see, the other reason for favouring systemd is more philosophical, and is based on the idea that the many different start-up routines share a considerable amount of common code, and that it is good to take out this code and put it in a separate process. That seems to me a good Unix-like argument.
In principle this should simplify the algorithms involved. But it seems to me that the way in which it has been implemented has in fact increased the complication rather than the reverse.
On 2014-07-17, Timothy Murphy gayleard@alice.it wrote:
But the only practical advantage of systemd that I've seen touted is that it speeds up boot-time. Even if this were true it does not seem to me worth worrying about,
It is if you manage a large cluster of virtual containers which dynamically boot or shut down based on load or other factors. If you need to boot 100 virtual containers right away, boot time will be a huge factor. (Not suggesting that systemd actually solves this issue, only that boot time is important in some use cases.)
--keith
On Jul 17, 2014, at 12:39 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2014-07-17, Timothy Murphy gayleard@alice.it wrote:
But the only practical advantage of systemd that I've seen touted is that it speeds up boot-time. Even if this were true it does not seem to me worth worrying about,
It is if you manage a large cluster of virtual containers which dynamically boot or shut down based on load or other factors. If you need to boot 100 virtual containers right away, boot time will be a huge factor. (Not suggesting that systemd actually solves this issue, only that boot time is important in some use cases.)
If the only practical advantage of systemd that you have seen touted has been boot time efficiency then you have been poorly served by your advisors. For servers I think some of the largest advantages is that now you have a standard, built-in way to make your services highly available, both with explicit watchdog heartbeats and with automatic restarting on failure if you want, but not mindless restarting if the service is broken, you have a configurable hold down timer as well. Another advantage is in not needing to demonize anymore, which is a little song and dance of UNIX trivia I’m happy to dispense with, along with the reliable capturing of stdout/stderr from services for logging, which is where plenty of errors go especially when services can’t start properly. Sanitized and consistent environment for services is also another feature, you can’t leak environment variables or file descriptors from the shell of the person who (re)starts a service since all services are a child of pid 1 not your shell. I haven’t even mentioned control groups for reliably managing all processes which are members of a named service without relying on the kindness of pid files or having unique argv0 (I have a lot of processes named /usr/bin/perl that are not all the same thing 8-)
There are plenty of features, any of which might be useful to you, that have been integrated into a critical mass of distros and upstream projects. That’s really the main difference, many of the individual features have been done before in various one-off systems but now there is a critical mass of the features being standardized across distros. You can learn more by reading some of blogs from the project lead developer, who is obviously very excited about the project http://0pointer.de/blog/projects/ or LWN
https://www.google.com/?gws_rd=ssl#q=site:lwn.net+systemd+for+administrators
— Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg@wisc.edu
Mark Tinberg wrote:
But the only practical advantage of systemd that I've seen touted is that it speeds up boot-time. Even if this were true it does not seem to me worth worrying about,
If the only practical advantage of systemd that you have seen touted has been boot time efficiency then you have been poorly served by your advisors. For servers I think some of the largest advantages is that now you have a standard, built-in way to make your services highly available, both with explicit watchdog heartbeats and with automatic restarting on failure if you want, but not mindless restarting if the service is broken, you have a configurable hold down timer as well.
I did not say that boot-time is touted as the only advantage of systemd. I explicitly said
As far as I can see, the other reason for favouring systemd is more philosophical, and is based on the idea that the many different start-up routines share a considerable amount of common code, and that it is good to take out this code and put it in a separate process. That seems to me a good Unix-like argument.
It seems to me that the arguments you put forward fall into this category. And I added the remark
In principle this should simplify the algorithms involved. But it seems to me that the way in which it has been implemented has in fact increased the complication rather than the reverse.
a point that you have not answered.
On Jul 18, 2014, at 7:14 AM, Timothy Murphy gayleard@alice.it wrote:
In principle this should simplify the algorithms involved. But it seems to me that the way in which it has been implemented has in fact increased the complication rather than the reverse.
From my perspective this is a simplified implementation, service files have very simple and well documented behavior, any complication I see seems to be inherent to the problem space and existed before systemd came on the scene, so it’s not created by systemd. A simple service example would be rsyslogd.service which just reads /etc/sysconfig/rsyslogd and runs /sbin/rsyslogd -n $SYSLOGD_OPTIONS a more complicated example would be mounting NFS filesystems, which has a bunch of dependancies on RPC port mapper services like idmap or gssapi a special filesystem in /var/lib/nfs etc. Neil Brown wrote a series of articles for LWN on replacing the shell scripts in nfs-utils with systemd unit files for SuSE. https://lwn.net/Articles/584175/
So simple things are trivial, more complicated things are possible and the options are there in the config file if you want to use them but you aren’t forced to.
— Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg@wisc.edu
On Fri, Jul 18, 2014 at 4:20 PM, Mark Tinberg mtinberg@wisc.edu wrote:
So simple things are trivial, more complicated things are possible and the options are there in the config file if you want to use them but you aren’t forced to.
But it does force people who should be focusing on improving an application to instead spend their time reconfiguring the startup configuration for a distribution just to keep it working the same way.
For example: http://issues.opennms.org/browse/NMS-6137
And, while it might offer a benefit in terms of being able to make it wait for the supporting postgres database if it is local, what happens if it is configured that way but you use the setup recommended for scaling where the database runs on a different system?
On 2014-07-18, Les Mikesell lesmikesell@gmail.com wrote:
But it does force people who should be focusing on improving an application to instead spend their time reconfiguring the startup configuration for a distribution just to keep it working the same way.
This seems (again) to be moving into a debate on "why systemd", when at least for CentOS 7 the decision has been made--it's systemd or bust (or a SIG for removing it). Perhaps we should focus systemd discussions more on how we as CentOS users can easily adjust? (I know, I already violated this principle in the thread, but I will aim not to in the future.)
IOW, if people really don't like systemd, I don't think this is a good forum for that discussion.
--keith
On 19.7.2014 1:23, Keith Keller wrote:
On 2014-07-18, Les Mikesell lesmikesell@gmail.com wrote:
But it does force people who should be focusing on improving an application to instead spend their time reconfiguring the startup configuration for a distribution just to keep it working the same way.
This seems (again) to be moving into a debate on "why systemd", when at least for CentOS 7 the decision has been made--it's systemd or bust (or a SIG for removing it). Perhaps we should focus systemd discussions more on how we as CentOS users can easily adjust? (I know, I already violated this principle in the thread, but I will aim not to in the future.)
IOW, if people really don't like systemd, I don't think this is a good forum for that discussion.
It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things. Even the grumpy sysadmins at university I work are happier with it than the old sysv init. It really makes their work easier.
And I have written sysv startup scripts before and I will be looking forward to convert them to systemd when my client upgrades to CentOS7 or RHEL7 depending on the machines. It seems more reasonable way of doing them and will also help in the task by automating many of the tasks which you specifically needed to take care yourself in the script before.
And for those who complain the new way is badly written, have you actually read those old scripts like old network service and can you easily understand what is going on. When reading them I could really understand why they were abandoned for something which promises to do things simpler and more sane way. Especially as they probably should be rewritten for the new ip tools instead of the old stuff.
But I don't mind you complaining it makes entertaining read on the summer work trips as local free newspaper is on summer vacation. Especially when I know that the things will not change back to old sysv way. There might be something new in future, but somehow I feel that there will be new group of people complaining that why change as systemd is good enough for them.
-vpk
On Sat, 2014-07-19 at 09:08 +0300, Veli-Pekka Kestilä wrote:
It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things.
These are the causes:-
1. Familiarity with something that works and can be modified without much effort- very important consideration in the computer world.
2. "Conservative" because new software is renown for creating "time wasting" frustration and irritation and sometimes "breakdowns".
3. Adherer to the principle "If it is working, do not repair or replace it".
4. Lack of knowledge about the replacement.
The systemd files do look like Windoze .ini files.
On Jul 19, 2014, at 9:05 AM, Always Learning centos@u62.u22.net wrote:
On Sat, 2014-07-19 at 09:08 +0300, Veli-Pekka Kestilä wrote:
It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things.
These are the causes:-
- Familiarity with something that works and can be modified without
much effort- very important consideration in the computer world.
- "Conservative" because new software is renown for creating "time
wasting" frustration and irritation and sometimes "breakdowns".
- Adherer to the principle "If it is working, do not repair or replace
it".
- Lack of knowledge about the replacement.
The systemd files do look like Windoze .ini files.
Times change, things evolve, adapt or go the way of the dodo
-- Regards,
Paul. England, EU.
Centos, Exim, Apache, Libre Office. Linux is the future. Micro$oft is the past.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 07/19/2014 09:05 AM, Always Learning wrote:
On Sat, 2014-07-19 at 09:08 +0300, Veli-Pekka Kestilä wrote:
It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things.
These are the causes:-
- Familiarity with something that works and can be modified without
much effort- very important consideration in the computer world.
- "Conservative" because new software is renown for creating "time
wasting" frustration and irritation and sometimes "breakdowns".
- Adherer to the principle "If it is working, do not repair or replace
it".
- Lack of knowledge about the replacement.
The systemd files do look like Windoze .ini files.
Well .. all of that may be true and systemd may be the devil ... but we would still have it as CentOS-7 rebuilds RHEL-7 sources. Debating whether or not systemd is a good idea is not relevant for CentOS. It is upstream, it is default, therefore it will be installed. That's just how it is.
We just had a bazillion mail thread on systemd and how it is terrible, we don't need any more.
If you want to see systemd taken out of CentOS ... then figure out how to take it out.
On 07/19/2014 11:10 AM, Johnny Hughes wrote:
On 07/19/2014 09:05 AM, Always Learning wrote:
On Sat, 2014-07-19 at 09:08 +0300, Veli-Pekka Kestilä wrote:
It is actually funny how there seems to be so many opponents of systemd who want back the old ways of doing things.
These are the causes:-
- Familiarity with something that works and can be modified without
much effort- very important consideration in the computer world.
- "Conservative" because new software is renown for creating "time
wasting" frustration and irritation and sometimes "breakdowns".
- Adherer to the principle "If it is working, do not repair or replace
it".
- Lack of knowledge about the replacement.
The systemd files do look like Windoze .ini files.
Well .. all of that may be true and systemd may be the devil ... but we would still have it as CentOS-7 rebuilds RHEL-7 sources. Debating whether or not systemd is a good idea is not relevant for CentOS. It is upstream, it is default, therefore it will be installed. That's just how it is.
We just had a bazillion mail thread on systemd and how it is terrible, we don't need any more.
If you want to see systemd taken out of CentOS ... then figure out how to take it out.
NOTE: That post was not specifically at "Always Learning" .. that just happened to be the mail in this thread I was reading at the time.
On Sat, 2014-07-19 at 11:10 -0500, Johnny Hughes wrote:
On 07/19/2014 09:05 AM, Always Learning wrote:
- Lack of knowledge about the replacement.
Well .. all of that may be true and systemd may be the devil ... but we would still have it as CentOS-7 rebuilds RHEL-7 sources. Debating whether or not systemd is a good idea is not relevant for CentOS. It is upstream, it is default, therefore it will be installed. That's just how it is.
I favour the increased knowledge of what it does and how to use it. Surely that is what the Centos Wiki is for ?
On Jul 19, 2014, at 1:39 PM, Always Learning centos@u62.u22.net wrote:
On Sat, 2014-07-19 at 11:10 -0500, Johnny Hughes wrote:
On 07/19/2014 09:05 AM, Always Learning wrote:
- Lack of knowledge about the replacement.
Well .. all of that may be true and systemd may be the devil ... but we would still have it as CentOS-7 rebuilds RHEL-7 sources. Debating whether or not systemd is a good idea is not relevant for CentOS. It is upstream, it is default, therefore it will be installed. That's just how it is.
I favour the increased knowledge of what it does and how to use it. Surely that is what the Centos Wiki is for ?
Yes it is, feel free to put all your learning about systems into improving the wiki also.
-- Regards,
Paul. England, EU.
Centos, Exim, Apache, Libre Office. Linux is the future. Micro$oft is the past.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 7/17/2014 11:39, Keith Keller wrote:
(Not suggesting that systemd actually solves this issue, only that boot time is important in some use cases.)
Well, *something* is making EL7 boot a lot faster than EL6. My EL6 test VM takes almost twice as long to boot to a console login (runlevel 3) as my EL7 test VM. If you extract the BIOS and GRUB time as fixed constants, it probably *is* twice as fast.
The advantages of Docker will swamp this benefit for the massive VM rollout case you mention, but for me and my little squad of test VMs, I'm happy to have the faster restarts.
-
Always Learning -
Johnny Hughes -
Keith Keller -
Les Mikesell -
Mark Tinberg -
Timothy Murphy -
Veli-Pekka Kestilä -
Warren Young -
William Woods