5 ms·

I really wondered whether people would sympathize with me or just flame me. I guess I can explain my 'imaginary' problems a bit. Like normal people, I had seve

by esaym 12y ago

I really wondered whether people would sympathize with me or just flame me. I guess I can explain my 'imaginary' problems a bit. Like normal people, I had several random things thrown in rc.local(set drive power settings,disable blue tooth on laptops, set raid sync rates,ect). The first issue was, systemd never even executed this file. I had to go do random googling just to get it to execute. After that, it was hit or miss on whether everything within the file would even get successfully executed. I'm guessing because some dependencies or modules aren't loaded yet, which shouldn't matter since rc.local is normally ran last. Sure, I could take each individual command and make its own init file which is what systemd docs recommend over rc.local. But seriously, why should I have to go to that length to fix something that has been working fine for 15 years?

esaym 12y ago
In the end, I have had to rewrite my init scripts for custom stuff and do extra work and I am left wondering why I even tried it in the first place. The only speed difference (which from what I can tell is the only reason anyone uses systemd) I have seen is on my desktop machine. Start up is way faster, and shut downs too. Although strangely shutdowns hang randomly for over a minute sometimes. But on my laptops, I have noticed no difference. In summary, systemd has not simplified my life. I am not really sure what the rave about it even is. And no, I am not the one threatening the developers. I really don't care enough. I just find it odd that so many praise it so heavily, and I don't feel that way at all. I also know of no sysadmins that are looking forward to its global rollout....
- JoshTriplett 12y ago
  > The only speed difference (which from what I can tell is the only reason anyone uses systemd) Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).
  - SwellJoe 12y ago
    In the long run, having a unified interface to every service on the system is a win. In the short run, we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before. I've been a UNIX/Linux system administrator coming up on 20 years now (professionally since about '99), and I understand the pain. It's hard to break the habits of all that time; it's always worked before. In a pinch we've always been able to stick some shell commands somewhere and have it fire up the stuff we wanted to fire up. But, it's nice to have one "thing" to ask questions of that will tell us a significant amount of data about the state of our system. It's something Windows Server has had for a long time (for Microsoft-provided core stuff; third party stuff has always sucked way worse than the state of things on Linux has ever been), and was arguably one of the (very few) reasons one might choose Windows over Linux on a server. I have reservations about systemd. It's big, seemingly over-engineered and intrusive into places that init never went, and does some things in seemingly fragile ways (someone else mentioned that dependencies failing can lead to failure to boot, which is not something init ever really had a problem with). But, it's better than init, on nearly every axis. And, it is the new de facto standard. So, I will learn it. I will work to make all the software I work on (which has an installed base in the millions, in the case of Webmin) work well with it. And, I'll probably even come to like it, eventually.
    - esaym 12y ago
      " we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before" Yes! Exactly! When you start breaking people's stuff that was working you will certainly not be getting compliments!
JoshTriplett 12y ago
~$ grep -r 'rc\.local' /lib/systemd/system /lib/systemd/system/rc-local.service:# systemd-rc-local-generator if /etc/rc.local is executable. /lib/systemd/system/rc-local.service:Description=/etc/rc.local Compatibility /lib/systemd/system/rc-local.service:ConditionFileIsExecutable=/etc/rc.local /lib/systemd/system/rc-local.service:ExecStart=/etc/rc.local start
SwellJoe 12y ago
"I really wondered whether people would sympathize with me or just flame me." It was not my intention to flame you. From your tone and sparse message, I assumed you were making yet another unfounded accusation about systemd; so many people on both sides (but mostly on the anti-systemd side) have been making ridiculous and untrue statements so often and for so long that I tend to just expect random made up nonsense to fly with reckless abandon. In your case, you have had a bad usability experience with systemd; and I can't deny your experience. I wasn't there. That said, it is my understanding that rc.local continues to work fine on systems that choose to enable the compatibility layer. Fedora is my desktop and laptop OS of choice, and I don't think I did anything to make my rc.local files work. I don't use them for much, but I do have some custom hard disk spin down times and such setup on one of my machines, which continued to function after upgrading to a systemd-based version. If your distro opted not to enable the compatibility layer by default, I suspect there's an easy way to do it yourself with a single command line or installation of a package. Our servers all run CentOS and we've put a couple of new CentOS 7 systems online recently, and while we don't have any rc.local bits running on them, we do still have a few old style initscripts (in our products, embarrassingly enough, even though our bootup and shutdown module supports systemd and upstart, we still ship initscripts to start our own stuff), and they have continued to function correctly on CentOS 7. In short, it has not been my experience that doing things the old way has been dramatically cut off for people who need to continue doing so for the time being. In my, admittedly limited, experience, I haven't noticed any difference except the "service" command now recommends systemctl when you run it.

by esaym 12y ago

esaym 12y ago

In the end, I have had to rewrite my init scripts for custom stuff and do extra work and I am left wondering why I even tried it in the first place. The only speed difference (which from what I can tell is the only reason anyone uses systemd) I have seen is on my desktop machine. Start up is way faster, and shut downs too. Although strangely shutdowns hang randomly for over a minute sometimes. But on my laptops, I have noticed no difference. In summary, systemd has not simplified my life. I am not really sure what the rave about it even is. And no, I am not the one threatening the developers. I really don't care enough. I just find it odd that so many praise it so heavily, and I don't feel that way at all. I also know of no sysadmins that are looking forward to its global rollout....

JoshTriplett 12y ago
> The only speed difference (which from what I can tell is the only reason anyone uses systemd) Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).
- SwellJoe 12y ago
  In the long run, having a unified interface to every service on the system is a win. In the short run, we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before. I've been a UNIX/Linux system administrator coming up on 20 years now (professionally since about '99), and I understand the pain. It's hard to break the habits of all that time; it's always worked before. In a pinch we've always been able to stick some shell commands somewhere and have it fire up the stuff we wanted to fire up. But, it's nice to have one "thing" to ask questions of that will tell us a significant amount of data about the state of our system. It's something Windows Server has had for a long time (for Microsoft-provided core stuff; third party stuff has always sucked way worse than the state of things on Linux has ever been), and was arguably one of the (very few) reasons one might choose Windows over Linux on a server. I have reservations about systemd. It's big, seemingly over-engineered and intrusive into places that init never went, and does some things in seemingly fragile ways (someone else mentioned that dependencies failing can lead to failure to boot, which is not something init ever really had a problem with). But, it's better than init, on nearly every axis. And, it is the new de facto standard. So, I will learn it. I will work to make all the software I work on (which has an installed base in the millions, in the case of Webmin) work well with it. And, I'll probably even come to like it, eventually.
  - esaym 12y ago
    " we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before" Yes! Exactly! When you start breaking people's stuff that was working you will certainly not be getting compliments!

JoshTriplett 12y ago

~$ grep -r 'rc\.local' /lib/systemd/system /lib/systemd/system/rc-local.service:# systemd-rc-local-generator if /etc/rc.local is executable. /lib/systemd/system/rc-local.service:Description=/etc/rc.local Compatibility /lib/systemd/system/rc-local.service:ConditionFileIsExecutable=/etc/rc.local /lib/systemd/system/rc-local.service:ExecStart=/etc/rc.local start

SwellJoe 12y ago

"I really wondered whether people would sympathize with me or just flame me." It was not my intention to flame you. From your tone and sparse message, I assumed you were making yet another unfounded accusation about systemd; so many people on both sides (but mostly on the anti-systemd side) have been making ridiculous and untrue statements so often and for so long that I tend to just expect random made up nonsense to fly with reckless abandon. In your case, you have had a bad usability experience with systemd; and I can't deny your experience. I wasn't there. That said, it is my understanding that rc.local continues to work fine on systems that choose to enable the compatibility layer. Fedora is my desktop and laptop OS of choice, and I don't think I did anything to make my rc.local files work. I don't use them for much, but I do have some custom hard disk spin down times and such setup on one of my machines, which continued to function after upgrading to a systemd-based version. If your distro opted not to enable the compatibility layer by default, I suspect there's an easy way to do it yourself with a single command line or installation of a package. Our servers all run CentOS and we've put a couple of new CentOS 7 systems online recently, and while we don't have any rc.local bits running on them, we do still have a few old style initscripts (in our products, embarrassingly enough, even though our bootup and shutdown module supports systemd and upstart, we still ship initscripts to start our own stuff), and they have continued to function correctly on CentOS 7. In short, it has not been my experience that doing things the old way has been dramatically cut off for people who need to continue doing so for the time being. In my, admittedly limited, experience, I haven't noticed any difference except the "service" command now recommends systemctl when you run it.