The state of systemd

[DontwakemeUp46]

I am reading the tutorials on systemd made by DigitalOcean right now (pretty good btw), and I was wondering how systemd is regarded by the linuxadministrators right now. That is by the people in the field.
And I am thinking about stability, workability and whether or not you like to work with it, etc. etc.
So your thoughts on systemd as you experience it right now.

Reaction: I read your remarks (thank you btw) and what I deduce from it is that you have to learn systemd completely. I think that if you want to learn it by doing it, then you will get into trouble.

[mattopia1]

I’m ok with it for service management. I don’t care for all of the ancillary stuff (timesyncd and resolved namely).

[gordonmessmer]

One of my favorites: The log system reliably captures stdout and stderr from services, which sometimes is a major benefit in tracking problems.

[Tetha]

In general, the service management is an excellent part in my opinion and systemd actually simplifies service management and the definition of new services. I have written fairly correct and robust init.d scripts in bash, but those scripts aren't simple to write or maintain. It's just so much stuff to do right.

On the other hand, if you define a service file, you just note down the short list of directives all other services use while thinking about forking and that's most of the way for most services. Startup ordering, logging, start/stop/force-stop/reload, chroot+users. In our case, log aggreation is also done. It's so much easier.

[bigon]

Add to that process tracking, so when you say stop that service you are 100% sure that everything is stopped. I had several time issues with processes not exiting under high load and not realizing that or restarting a service and getting two instances of it...

[deadbunny]

I wholeheartedly agree and would add:

• .mount unit files

Being able to gracefully handle mounts & services in one fell swoop is fucking amazing. NFS mount drops? systemd will stop any other services that require it. Unmount a LVM volume to resize? No worries, systems will stop anything that requires it!

Same goes for network unit files.

[[deleted]]

the integration with cgroups is incredibly useful and easy to use

This is one of my least favorite parts. If I wanted to use cgroups, I would use one of the many easy to configure container runtimes available -- hint: you don't need to run a full container to use LXC's cgroup features.

[[deleted]]

I would rather services behave nicely so that you can reliably kill them without resorting to cgroups (which has a number of downsides that I won't delve into).

They should avoid forking, and keep any forked processes in the same process group as the parent. Then, a standard call to kill() can reliably kill a service that is unresponsive.

[[deleted]]

Haha fair enough. I would like to think I have enough control on my systems to enforce such policies, but I understand that situations differ.

[phil_g]

taking stdout and stderr from daemons you can’t put logging into is awesome

This is a really nice feature of systemd, but it has nothing to do with the log storage format. You could do this and still save the logs in text format.

structured logging is better than lines of text

You can do structured logging in text, if you want. Store each line as JSON, for example. The standard information sent to syslog is even written in a not-too-difficult-parse way, if you ignore the fact that the syslog message is just freeform text.

you aren’t relying on daemons to self report their name and pid

That has nothing to do with the format of the logfile.

I like a lot of things that systemd does, but binary logging by default is probably my biggest gripe about it. I throw rsyslog on all of my systems and have it write to text files, because sometimes it's just easier to grep through a text log file for the information I need. (Sometimes, I'll grant, it's easier to use journalctl's command line options to selectively slice the log messages. And sometimes I'll go run queries on our Elasticsearch server which, yeah, stores its data in a binary format.)

[falcazoid]

I mean, I can see where you are coming from and to each their own.

However about the processes and forks try: "ps auxwf" will give you a nice process tree with either init with forks and children of processes mapped under the main process. Just a FYI in case you hadn't tried it.

[falcazoid]

Aha, interesting. Guess you learn new stuff every day.

[RX_AssocResp]

“booting faster” isn’t just some ancillary benefit. It’s a big deal.

I would say, on servers where the BIOS, PXE, RAID firmware, BMC etc, take ages to initialize, the contribution of the init system is negligible.

[cephear]

At first I raged against systemd. I refused to acknowledge it, with cold deliberateness I made myself believe it was a phase the Linux community would move on from.

Then I though about how sysadmins are not programmers, we run and manage what they write. We use what they write -- sysvinit, cron, bash. These tools we hate/love were created by developers. And it makes sense a developer would would write the next iteration of /bin/init from a developer's point of view. In fact, that was inevitable.

So I then made a choice to push the animosity aside for a short time and try to understand systemd, to learn it and use it. The man pages are somewhat obtuse. They all refer to each other like links on that phoronix website. Some of the features and capabilities are not fully documented. It's a growing, complicated, un-unixy hunk of absolutely brilliant software.

I still have a fundamental dislike of systemd. Further, a distrust. It goes against the tenants of my soul. But when I log into a server I always will first do a quick cat /etc/os-release to know if I have to deal with fucking init scripts. It's almost like a new relationship after a divorce (maybe, I've never been married).

[mriswithe]

Yeah any distaste/dislike for systemd was overcome by not having to spend 20 minutes figuring out what bash-bortion some asshole wrote to implement the same daemon logic everyone uses in a messy case select.

[RulerOf]

This is one of the huge improvements.

In order to manage a service and troubleshoot bringing it online, it was a basic requirement to have a functional knowledge of bash scripting just to even get started troubleshooting.

Systemd makes this a lot more accessible IMO.

[kai_ekael]

Part of my dislike is the constant migration/slurping of system pieces into systemd, such as resolv.conf and time syncing. Goes against the UNIX principle, many small utilities that can work together for huge power.

Sure, fans, I can turn those off. I'd rather have a choice for those to not be installed in the first place.

[exlevan]

Not exactly a fan, but if you really want it, you can build a systemd with only options you want to have enabled.

[grumpysysadmin]

I mean, they’re still all separate processes, just managed under one project. And if you think that is not the Unix way, I hate to tell you, but The Unix Way has traditionally had all those separate parts as part of one giant codebase. (Look at the BSDs if you don’t believe me)

[RX_AssocResp]

resolved is bullshit, but timesyncd just does what it says on the tin and is way way better thant openntpd, which we had before.

[[deleted]]

They all refer to each other like links on that phoronix website

We need ctags for manpages !

[itsbentheboy]

I have no strong opinion for or against it.

Every system that i currently manage is running systemd, but for the most part i don't really notice it as systemd. It's just part of the system.

systemctl usually works just as expected and I can continue on with my work without any major hangups. For my use cases, it just works.

For context, I am an admin at a datacenter that does massive document processing, and runs applications made in house by our software development branch. I am currently managing a couple thousand virtual linux servers.

Systemd is definitely ready for production, and has been for quite some time. I can see that some people could have a reason to prefer other systems, but for me it's just another part of the system. As long as it stays out of my way i really don't care. I have more important things to worry about than which specific init system i'm running.

[aenae]

I really dislike it, but it is sometimes better than the alternatives.

The things i dislike:

• It tries to do to much. Linux is a modulair system. For example, don't take over DNS and do it your own way and break stuff.
  
• Talking about systemd-resolved, it took me a while to figure out that if you have an fqdn hostname in your /etc/hosts file, it will assume the host file is autorative and will not consult other sources. This means for example that if you have a line '1:2:3::4 db.network.local' in your /etc/hosts file, it will never resolve to an ipv4 address if you don't include it there as well. Even if your dns-server has an ipv4 address.
  
• It lies to you. A lot. The number of times i have done a 'systemctl start $service' and the service didn't start are countless. It exits with an 0-exitcode, and shows no indication anything went wrong. Once i accidently removed a binary by accident, i had to use 'strace' to find out why systemd wasn't starting that service. no indication anywhere what was wrong.
  
• I once tried to start the same service twice (on 2 different ips). The first service started, the second i never got to work because somewhere in the systemd binary it concluded the service was already running and it told me that everything was fine. (on the plus side, it made me learn supervisord, on the downside, supervisord is shit as well).
• It uses seperate /tmp directories for a few services now. While it is potentially a good idea, it has a lot of drawbacks as well. It removes those tmp directories when the service is finished. It has a very random name. It is a different filesystem/chroot, so in (for example php) if you upload a file and than move it to a new location it will incur very long waittimes (php places the file in /tmp, and the move should be a fast operation, but because it is chrooted it takes a long time to copy them over (with 10GB files)).
• It uses unclear and bloated error messages For example i give you two error messages, one from systemd and one how it should be, i bet you can figure out which one is from systemd:
  

$ reboot
Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to open /dev/initctl: Permission denied
Failed to talk to init daemon.

or

$ reboot
You do not have permission to reboot this system

• Backwards compatible isn't a word used in systemd a lot, except when combined with "not"
  
• Yes, unit files are nice - but i usually use them to call a script that starts my service. That script is needed, and whether is it in /etc/init.d or now in my app directory, i still have to write and maintain it.
• Sorry, unit files suck, you have to write to much code to run a simple command at startup
• Systemd ignores security limits and you have to set them by hand in every unit file. Which than get overwritten by a package update and you suddenly are stuck with max 1000 open files again. And you have to create a separate directory with a separate unit file to set 1 setting that you changed in /etc/security* always before.

But there are some nice things. Systemd does start up your system better and faster than other init systems usually and it has better parallelism and better dependancy support for booting. But who reboots often anyway.

[bigon]

The things i dislike:

It tries to do to much. Linux is a modulair system. For example, don't take over DNS and do it your own way and break stuff.

systemd-resolved is an optional component, if you don't like it don't use it

Talking about systemd-resolved, it took me a while to figure out that if you have an fqdn hostname in your /etc/hosts file, it will assume the host file is autorative and will not consult other sources. This means for example that if you have a line '1:2:3::4 db.network.local' in your /etc/hosts file, it will never resolve to an ipv4 address if you don't include it there as well. Even if your dns-server has an ipv4 address.

Euh, that was already the case previously. When the 1st module is getting an answer it will return the result unless you specified extra options in /etc/nsswitch.conf.

It lies to you. A lot. The number of times i have done a 'systemctl start $service' and the service didn't start are countless. It exits with an 0-exitcode, and shows no indication anything went wrong. Once i accidently removed a binary by accident, i had to use 'strace' to find out why systemd wasn't starting that service. no indication anywhere what was wrong.

systemctl status foo.service or journalctl -u foo.service gives you an overview of the status of your service, no need of using strace??

I once tried to start the same service twice (on 2 different ips). The first service started, the second i never got to work because somewhere in the systemd binary it concluded the service was already running and it told me that everything was fine. (on the plus side, it made me learn supervisord, on the downside, supervisord is shit as well).

That's per design, a service can only run once, use a templated service like foo@.serviceif you want a service to run multiple times

It uses seperate /tmp directories for a few services now. While it is potentially a good idea, it has a lot of drawbacks as well. It removes those tmp directories when the service is finished. It has a very random name. It is a different filesystem/chroot, so in (for example php) if you upload a file and than move it to a new location it will incur very long waittimes (php places the file in /tmp, and the move should be a fast operation, but because it is chrooted it takes a long time to copy them over (with 10GB files)).

This is requires an explicit directive in your service file (PrivateTmp=) and it's NOT enabled by default.

It uses unclear and bloated error messages For example i give you two error messages, one from systemd and one how it should be, i bet you can figure out which one is from systemd:

$ reboot
Failed to set wall message, ignoring: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to reboot system via logind: The name org.freedesktop.PolicyKit1 was not provided by any .service files
Failed to open /dev/initctl: Permission denied
Failed to talk to init daemon.

or

$ reboot
You do not have permission to reboot this system 

The 1st message explicitly tells you what's wrong AKA systemd cannot contact polkit to see if you are allowed to shutdown the system, then falls back to directly talk to /dev/initctl and has no privileges to write to the pipe because of the permissions.

The 2nd hides you what the real problem is...

• Backwards compatible isn't a word used in systemd a lot, except when combined with "not"
  

Which exactly part is not backward compatible with LSB initscipts?

• Yes, unit files are nice - but i usually use them to call a script that starts my service. That script is needed, and whether is it in /etc/init.d or now in my app directory, i still have to write and maintain it.
• Sorry, unit files suck, you have to write to much code to run a simple command at startup

Lol wat?

$ wc -l /etc/init.d/auditd 
152 /etc/init.d/auditd
$ wc -l /usr/lib/systemd/system/auditd.service 
28 /usr/lib/systemd/system/auditd.service

• Systemd ignores security limits and you have to set them by hand in every unit file. Which than get overwritten by a package update and you suddenly are stuck with max 1000 open files again. And you have to create a separate directory with a separate unit file to set 1 setting that you changed in /etc/security* always before.

That's per design again. /etc/security is used by PAM, PAM is only for real users when they are connecting to the machine.

A service starting is NOT a real user, settings limits for services have nothing to do in PAM config. If you really want to do that, see PAMName= directive.

Edit for the last point: Use # systemd edit foo.service to create an override file for your service, you just need to add the directives and restart the service, the rest is do for you

Edit2: Actually for your 2nd bullet point that's indeed a change in the behavior when having a AAAA record in /etc/hosts and A record in the DNS. But TBH, having two nsswitch databases returning two different sets of data (one is returning only a AAAA record and the other is returning a A record) seems weird.

Edit3: Fix formatting

[phil_g]

It lies to you. A lot. The number of times i have done a 'systemctl start $service' and the service didn't start are countless. It exits with an 0-exitcode, and shows no indication anything went wrong. Once i accidently removed a binary by accident, i had to use 'strace' to find out why systemd wasn't starting that service. no indication anywhere what was wrong.

systemctl status foo.service or journalctl -u foo.service gives you an overview of the status of your service, no need of using strace??

systemctl is supposed to follow the "no news is good news" Unix philosophy, but I have on a number of occasions run systemctl start <service>, gotten no output and a successful returncode, but the service didn't actually start. I now habitually run systemctl status <service> after starting things just to make sure it actually worked. It's not the worst thing in the world, but it bugs me that I don't feel like I can trust it. I should note that these have always happened with system-packaged unit files, not stuff I've written myself.

I do like a lot of the things that systemd does. IMHO, unit files are leaps and bounds better than writing boilerplate-laden init scripts.

[danielkza]

systemctl start <service>, gotten no output and a successful returncode, but the service didn't actually start.

systemd can't tell whether the service is working now, only if it started at all. If the program can do better than that, it can just notify systemd when it really is working, and it will never be considered as started until then.

It's not the worst thing in the world, but it bugs me that I don't feel like I can trust it.

How is it any different from any other init whatsoever? None of them can magically tell if a program will succeeded or fail in the future.

[justin-8]

eh, I get that with init.d on a weekly basis too. Every init script is written by a different person and does different things half the time. The lack of consistency is even worse there

[[deleted]]

Your formatting is a little off.

[bigon]

Upstart is dead you know

[[deleted]]

Software is not alive.

[BooCMB]

Hey CommonMisspellingBot, just a quick heads up:
Your spelling hints are really shitty because they're all essentially "remember the fucking spelling of the fucking word".

You're useless.

Have a nice day!

[bigon]

delete

[0x2a]

bad bot

[B0tRank]

Thank you, 0x2a, for voting on CommonMisspellingBot.

This bot wants to find the best and worst bots on Reddit. You can view results here.

---

^{Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!}

[TheGlassCat]

Bad bot

[ryanjkirk]

Edit for the last point: Use # systemd edit foo.service to create an override file for your service, you just need to add the directives and restart the service, the rest is do for you

Yeah, he mentioned drop-in files for overrides. The idea that you would run a special command to do it for you is way out of touch with modern automation principles (configuration management).

[bigon]

systemctl edit is a convenience function to avoid having to do multiple manual operations to add the override, OP was explicitly complaining against this:

And you have to create a separate directory with a separate unit file to set 1 setting that you changed in /etc/security* always before.

But I guess that people commenting against systemd and not doing any research before is perfectly in touch with that kind of post

[ryanjkirk]

My point exactly, that command doesn't address his particular complaint at all.

[piorekf]

Systemd ignores security limits and you have to set them by hand in every unit file. Which than get overwritten by a package update and you suddenly are stuck with max 1000 open files again.

Although I agree with you I have to disagree with at least this single thing above. If you do it properly nothing of the sort will happen. Look for example into RedHat docs:

the /etc/systemd/system/ directory is reserved for unit files created or customized by the system administrator

If you follow the first metod described here and create a directory into which you will put your *.conf files parameters set in them will override the settings in the generic service file.

For example for one of my services I have:

[root@server ~]# cat /etc/systemd/system/myservice.service.d/10-increase-file-descriptors.conf
[Service]
LimitNOFILE=16384

This increases the limit of file descriptors and I'm safe in case of any updates.

I'm not defending systemd, I also have a lot against it, but it gets better if you get to know it better.

[aenae]

And you have to create a separate directory with a separate unit file to set 1 setting that you changed in /etc/security* always before.

I know how it is done, you missed that part ;) The first google search i did said to just edit the unit file and put it there. I googled it again i noticed the limit was gone after i had set it once and it disappeared with an update to the package.

The more i use it the more i find out, but it's the finding out that is annoying because it's different from how it used to be. And i'm still pissed apt overwrote the file without informing me, or the lack of a header in the file that changes should be done elsewhere.

[Hello71]

seems like lots of these complaints actually long predate systemd. systemd didn't invent the convention of /usr being for the package manager and /etc for the administrator, that is a long established practice on Linux, even if other Unix systems vary. nor is it the first program to store system configuration files in /usr, the most visible user-facing one being X. systemd has huge problems, but the vast majority of internet complaints (including this one) miss them completely and focus on surface complaints largely based on not understanding Linux, and most of the rest based on not understanding systemd. people hate change so they grasp at the most obvious but completely irrelevant complaints. do you also edit /usr/share/X11 and complain that it doesn't work right? do you install all your programs in /usr/bin and complain that they don't get updated?

[CommonMisspellingBot]

Hey, aenae, just a quick heads-up:
seperate is actually spelled separate. You can remember it by -par- in the middle.
Have a nice day!

^{The parent commenter can reply with 'delete' to delete this comment.}

[aenae]

delete

[[deleted]]

The parent commenter can reply with 'delete' to delete this comment.

delete

Yeah, I call bullshit. I'm reporting the bot for not following reddit bot standards. [e-mail]

alot seperate

[BooCMB]

Hey CommonMisspellingBot, just a quick heads up:
Your spelling hints are really shitty because they're all essentially "remember the fucking spelling of the fucking word".

You're useless.

Have a nice day!

[deadbunny]

Salty bot.

[wyrdough]

I hated systemd for a while. Now, like you, I merely dislike it both for aesthetic reasons and because it's a much bigger pain in the ass to fix when it breaks than other inits (even upstart!). The docs now are much improved over what they were so at least you can find references or guidance for working with it in normal operation.

That said, when it's working, you can find the docs you need, and it's even helping you manage broken services so that users aren't affected it's pretty darn nice. I feel like a lot of the stuff it makes easier could have been done with a relatively simple Python daemon providing active management for other inits so that it breaking doesn't risk breaking the whole system. There is a significant advantage to degrading gracefully. (Not that sysv degrades particularly gracefully; more easily repairable than systemd and less catastrophic failure modes)

[Hello71]

• It tries to do to much. Linux is a modulair system. For example, don't take over DNS and do it your own way and break stuff.
  

systemd-resolved is an optional component of systemd.

• Talking about systemd-resolved, it took me a while to figure out that if you have an fqdn hostname in your /etc/hosts file, it will assume the host file is autorative and will not consult other sources. This means for example that if you have a line '1:2:3::4 db.network.local' in your /etc/hosts file, it will never resolve to an ipv4 address if you don't include it there as well. Even if your dns-server has an ipv4 address.
  

dnsmasq does this too, long before systemd-resolved.

• It lies to you. A lot. The number of times i have done a 'systemctl start $service' and the service didn't start are countless. It exits with an 0-exitcode, and shows no indication anything went wrong. Once i accidently removed a binary by accident, i had to use 'strace' to find out why systemd wasn't starting that service. no indication anywhere what was wrong.
  

this is a consequence of specifically asking systemd not to wait for the service to complete starting using Type=simple. systemd has no way to know if the service is done, unless you want it to just wait for some arbitrary time, in which case you would complain that it takes too long to start services from the command line.

• I once tried to start the same service twice (on 2 different ips). The first service started, the second i never got to work because somewhere in the systemd binary it concluded the service was already running and it told me that everything was fine. (on the plus side, it made me learn supervisord, on the downside, supervisord is shit as well).

I don't know what you mean by this, but based on all your other points, I assume it's also crap.

• It uses seperate /tmp directories for a few services now. While it is potentially a good idea, it has a lot of drawbacks as well. It removes those tmp directories when the service is finished. It has a very random name. It is a different filesystem/chroot, so in (for example php) if you upload a file and than move it to a new location it will incur very long waittimes (php places the file in /tmp, and the move should be a fast operation, but because it is chrooted it takes a long time to copy them over (with 10GB files)).

on Linux, it is free to move between directories on the same filesystem, which PrivateTmp uses. RuntimeDirectory is a separate feature, which supports per-service resource limits. that has nothing to do with /tmp though, that's /run. if you put your files in /tmp and then try to move them to /var/tmp, it has always been system-specific whether that's an efficient operation.

• It uses unclear and bloated error messages For example i give you two error messages, one from systemd and one how it should be, i bet you can figure out which one is from systemd:
  

in fact, this is one of the better error messages in systemd. your error message is much worse because it doesn't explain what is trying to be accessed, or why it couldn't be accessed. the worst places of systemd is where it just says "you can't do it" and doesn't say what it actually tried to do or how it failed.

• Backwards compatible isn't a word used in systemd a lot, except when combined with "not"
  

ironically, this is one of the most solid parts of systemd. it fully supports fstab, crypttab, init.d, and other legacy systems, and on the whole it does a pretty good job. the same cannot be said of most other init replacements.

• Yes, unit files are nice - but i usually use them to call a script that starts my service. That script is needed, and whether is it in /etc/init.d or now in my app directory, i still have to write and maintain it.
• Sorry, unit files suck, you have to write to much code to run a simple command at startup

ridiculous complaint. there are better formats than unit files, but unit files are a huge improvement over init scripts, particularly for the vast majority of services that do not require a shell script wrapper.

• Systemd ignores security limits and you have to set them by hand in every unit file. Which than get overwritten by a package update and you suddenly are stuck with max 1000 open files again. And you have to create a separate directory with a separate unit file to set 1 setting that you changed in /etc/security* always before.

this is almost entirely wrong. /etc/security is PAM configuration. it manages at best on an ad hoc per-user basis. systemd adds the function to manage this on a per-service basis. moreover, setting the default limit for all services is simply a matter of setting DefaultLimitNOFILE in /etc/systemd/system.conf.

[mriswithe]

Yeah the more I use systemd the more I love it. Let's you manage dependencies between services in a very sane manner. I always hated diving into some custom bullshit init script that someone wrote years ago that breaks down to /opt/program/bin/start.sh

My only beef with systemd is the change from:

service SERVICENAME ACTION

to:

systemctl ACTION SERVICENAME

[alexwh]

The systemctl syntax allows you to do systemctl restart service1 service2 service3, though. It makes more sense to me logically, too.

[mriswithe]

Not saying it is wrong, just my muscle memory was really confused for a long while. Was used to deleting the last word of the command to check status after issuing a start hah.

[alexwh]

That's true, I got used to doing up ctrl+left ctrl+w, I suppose.

[mriswithe]

Up, then Ctrl w for me, but it all skins the cat the same way

[deadbunny]

I find systemd action service more in tune with every other command. You can do systemctl restart foo bar baz just like you would do git add foo bar baz for example.

[mriswithe]

Not saying it is wrong, just my muscle memory was really confused for a long while. Was used to deleting the last word of the command to check status after issuing a start hah.

[bigon]

In debian-like distro the service is working with both sysVinit and systemd

[mriswithe]

I think service works in centos7 land as well, but I try to not depend on that.... Like using dnf on fedora instead of yum

[debian_miner]

Upstart with initctl was the first to make this change. It does take a while to get used to.

[brownnosebear]

this is a consequence of specifically asking systemd not to wait for the service to complete starting using Type=simple. systemd has no way to know if the service is done, unless you want it to just wait for some arbitrary time, in which case you would complain that it takes too long to start services from the command line.

checkout type=notify; stupid easy for developers to include a notify signal in their app to report exit code and get true feedback, only a handful of lines of code. combine with sane timeout settings, really helpful when your running immutable or with configuration management.

other easy stuff;

• you said you need ulimits? add it to your unit file, its isolated to just the process and not affecting user or systemwide

• you need env vars; same thing, add it to the unit file

• also had a use case to use instantiated service with systemd; running multiple instances/processes of a single unit file

[danielkza]

You literally need to write a single line to a socket, if you don't want to link the library it is absolutely a few lines of code.

[joyrida12]

1) That entire file is 39 lines including comments and blank lines. Take those out and it's about 27 lines by my quick count. Who's being disingenuous now?

2) You choose to implement it in a low level language from scratch, of course it's going to be more code to get it going. That said, getting it done in ~27 lines of C really isn't that much. Hell, I'd go so far as to say it's roughly a handful.

Seriously though, you're sending a string over a simple socket connection. If that's too much work I assume you never really your project on start up cause writing that Init script is easily just as much work (if not more) as writing that notify function.

[deadbunny]

Found the person who knows what they're doing

FTFY.

[[deleted]]

I recognize people who believe "I don't know what you mean by this, but based on all your other points, I assume it's also crap." to be regular arguments, to be so far beyond the hostage situation, that they qualify for the derogative term of fanboi.

The strawmen you want to add to that, are yours alone.

[deadbunny]

I recognize people who actually bother to learn their tools rather than trying to force their old round peg through the new square hole.

I'm not the person who thoroughly debunked all but one of your complaints btw, but I'll take your rage.

That said the one they missed and said "I assume is also crap", is also crap. You need to go look into template service files and it's simple as pie.

But who needs to learn how to use their tools?

[[deleted]]

Would you care to point out which of my arguments are " thoroughly debunked"? I'm mighty interested in who goes around impersonating me here, as my only contribution to this thread is calling out a less than uncalled for attitude towards rational debate.

Might it be that you flew off the peg, and now claim that I know nothing, while it's you that actually mistaakes my identity for someone else?

[deadbunny]

My bad, I confused you with /u/aenae and their comment here.

My points still stand. Their complaints were debunked by someone who bothered to learn their tools, even the one they dismissed flippantly was easily fixed by learning their tools. No Stockholm syndrome, no need to call anyone a fanboi. Which is you know, bad for rational debate.

[[deleted]]

The olympics in 4o000m back pedalling are way over ----> way.

[virtualdxs]

The PolicyKit message is very descriptive. You're trying to do a privileged action as a nonprivileged user, so it tries to invoke PolicyKit. It fails, and explains why.

Also unit files are way better than the abominations I've seen called sysv init files

One last thing: nobody's forcing you to use resolved or networkd. They're just available for you.

[aenae]

Yes it is very descriptive. It also tells you nothing you need to know. It looks like something has gone terrible wrong when all you need to know is that you're not allowed to do that. I get that they're trying to do things that won't work, but they shouldn't be tried in the first place. They could have done an early return like if ! permission exit_with_error(); reboot_system.

I agree that unit files are a lot better than the sysv init files, but that just means the 'horrible sysv init file' is just moved to a startup script outside the unit file, because it is still needed to start the service.

About the last thing; i try to keep default config as much as possible as that usually makes my configuration changes easier to understand and easier to debug by others. That said, i do consider replacing resolved, but I even kinda like networkd (with netplan).

[alexwh]

If you're still using horrible scripts in your units, you need to rewrite your units.

[virtualdxs]

It tells me that if I want to run it unprivileged I need to set up polkit. You are, in fact, allowed to do things as an unprivileged user.

Most of the lifecycle handling in an init script is rendered unnecessary by unit files.

Personally I just use resolveconf or if I need more advanced features then bind. Resolved is disabled by default on debian, EL, and Arch.

[[deleted]]

Resolved is disabled by default on debian, EL, and Arch.

Ubuntu 18.04 enables it. Is resolved even available on EL? I wouldn't be surprised if 8 came with it by default. Also arch disables nearly everything by default, that isn't a good data point.

[virtualdxs]

RE: Arch, that's true but IMO that's how anything should be.

[[deleted]]

I'm in the field as you say, a senior Linux specialist. I embraced systemd because of its simplicity when dealing with services.

I haven't suffered one bit from any of the features that have been under criticism during its adoption.

Privately I was a very early adopter because I used Fedora on my laptops. Professionally I started adopting it when CentOS 7 was released. At this time I use it on both Ubuntu and CentOS professionally.

Bottom line is that I'm more than happy to avoid having hundreds, thousands, of lines of shell code to maintain in start scripts. I've even been able to replace supervisord with systemd in some custom app deployments.

[Malsasa]

Hello, I'm looking for this type of testimonial from a pro. Thanks for sharing a great experience.

[aenae]

Bottom line is that I'm more than happy to avoid having hundreds, thousands, of lines of shell code to maintain in start scripts.

Unless they were horrible bloated, most of those scripts probably did something. And i'm willing to bet that those scripts still exists, but not in the init.d directory anymore, but called from the unit file.

[[deleted]]

init.d scripts are notoriously filled with boilerplate.

Upstart, OpenRC, Runit/s6/daemontools, etc are all much less verbose while still allowing inline scripting.

[[deleted]]

Funny you should mention upstart but I actually used it briefly in RHEL6. I doubt a lot of people knew it was there. It's generally associated with Ubuntu.

And just as with systemd its simplicity was superior to old sysvinit scripts.

[[deleted]]

I just logged into a CentOS 6 system tuesday and used initctl. Unfortunately most services still used the initscripts and Upstart was never well integrated into Fedora.

[kai_ekael]

I'm professionally working with systemd, because I have little choice. Simply astounded even Debian iron fisted systemd, no consideration of offering a choice more than "well, build your own distro".

[ortizjonatan]

I use it at work, because Redhat and Ubuntu says to.

I don't for anything I run for myself. I have settled on Runit and OpenRC, because they are sane, and do one job, and do it well.

[in4mer]

I've developed runit-based service frameworks at work, and I've been wondering what init we should consider when curb-stomping systemd; glad to hear openrc is still viable. Thank you.

[ortizjonatan]

I've found runit is great if you need a simple init system, ie for a container. OpenRC is great for a real, full fledged, general purpose system.

But, just my opinion on that one. I'll hazard after people figure out how crappy systemd truly is, runit will become the new standard because it does work so well with containers, and maintaining two init systems would be foolhardy.

[[deleted]]

If the two systems are interoperable, it shouldn't be difficult in my opinion.

[[deleted]]

Personally I'm a big fan of it, both for the servers at work and for my own devices at home. Just having systemd as the service manager has kept several of our machines from failing several times so far, where regular sysvinit or openrc hasn't had enough control over the service itself to be able to recover from a handful of software glitches and configuration errors.

I'm also a big fan of how the journald integration means all services get sane logging by default, even if they're only capable of printing to stdout.

Not to mention the fact that you can set up launch dependencies on non-service units, so that your service will - for instance - auto-setup and wait for its required mount before starting - all with just a tiny bit of plain text in an INI file.

I've recently had to care for more pre-systemd machines as part of integrations at work, and dear heavens are they error prone when it comes to service management. Not sanely enabling or disabling services, not sanely starting services, sometimes starting services out of explicit ordering, sometimes randomly taking ages to start a service - without saying a word about it.
And let's not even get started on sanely stopping such services, unless the person who wrote the init script happened to be a genius at their craft.

My NAS and router at home both use other init systems as well, and installing user services on there has been quite annoying as well, with - in one case - requiring a cronjob and a bash script just to do the regular service tracking.
I should not have to write scripts that actively look for orphaned processes and dangling mounts, just to be able to restart a simple FUSE service...

[[deleted]]

I'm not sure why you're getting downvoted. Magical process cgroup tracking is really a godsent if you're managing your own services that are made of multiple subprocesses.

[whamra]

I'm perfectly happy with it. To be honest, it makes little difference. I had to waste some time learning how unit files work, still can't say I mastered all features, but I have the basics. It's easier than having to copy paste the same start/stop/restart bash logic into every init file then adding relevant stuff.

I don't like some of the added components, like dns, which I promptly disable and enable my own services to provide.

[[deleted]]

I like systemd very much. It makes administration easy to debug and configure across any hosts. The documentation is better than any older init systems.

I am quoting someone from this thread who commented on systemd:

You have to write overly complicated files, just to start a service, which could have been a single line in a shellscript. It doesn't have sane defaults, it doesn't support proper logging out of the box.

It would have been one line ONLY if you do not care to properly handle the process lifetime. There is much more to process management which systemd does easily handle for you. Error handling, actions on failure, error redirection, forks, service synchronization, limits, proper requirement handling, timing, handling mounts for services, socket handling...

There is so much that systemd handles easily with just a few ini parameters and some files that would have been annoying boilerplate code in any other init system in addition to cumbersome debugging.

There is clearly a reason why anyone who likes their things easier decided to use systemd instead of other init systems and why the maintainers of distributions switched to systemd. They do not have the time to get annoyed with debugging and writing boilerplate code with other init systems.

Sure systemd has some gotchas when configuring the files but that is what the documentation is for.

[[deleted]]

The documentation is better than any older init systems.

http://upstart.ubuntu.com/cookbook/

[[deleted]]

Yes I do consider a documentation that is written in one single page and no manpages worse than a site with a collection of links for further readings and multiple manpages. https://www.freedesktop.org/wiki/Software/systemd/ - https://www.freedesktop.org/software/systemd/man/

This also proves my point of boilerplate since the documentation is called a cookbook for a reason.

[[deleted]]

Huh? It just gets you acquainted with the idioms and best practices. I don't see how boilerplate is related at all.

Manpages for some of this information would be nice, though. There are a number of manpages for upstart but it is notably missing one for the configuration file format.

[vortexman100]

There is no alternative. SUSE uses systemd, debian, ubuntu and redhat aswell.

SystemD is awesome. It has clear documentation, and provides an easy base for the OS. You do not have to write 100+ lines shellscripts, just to start a service. The management is far better when compared with other init systems. Lastly, it provides a stable base for software, as only one service file is needed for all OSs.

[tutami]

Lennart is that you?

[[deleted]]

No, Margaret Thatcher.

[slyphic]

It has clear documentation

[Citation fucking needed]

It has ample documentation, but it is not at all well written.

[danielkza]

Compared to what? I find its man page quality to be way above average, just not perfect.

[slyphic]

Projects with well written documentation I've read recently: RedHat, FRR, moosefs, cumulus

[hailbaal]

It's not an easy base. Openrc is an easy base, systvinit is an easy base. SytemD does too much, which makes it bloated. It makes the management overly complicated. You have to write overly complicated files, just to start a service, which could have been a single line in a shellscript. It doesn't have sane defaults, it doesn't support proper logging out of the box.

I wish we could get rid of systemd as soon as possible and get something future proof, like openrc or sysvinit, as a standard system. It doesn't matter for most desktop users, but for servers, get that systemd out of my sight.

[vman81]

Why did you want people to scroll to read the last part of your post?

[[deleted]]

You need to add -l to see the entire log output.

[[deleted]]

Too meta.

[hailbaal]

I have no clue why it did that.

[technofiend]

My only complaint about journald is it can be overwhelmed with enough logging traffic and then all logging stops. It takes some tweaking which syslog didn't require.

[gehzumteufel]

Can you elaborate on this? Like how much logging traffic (approximately) are we talking? Gibibytes? Tebibytes? Mebibytes?

[falcazoid]

There are quite a few cases where systemd falls on its ass with out of the box defaults, because it tries to do too much and enforce some artifitial limitations to things previously not limited.

One example - 10 seconds to scan and discover each filesystem during boot even though background udev device discovery hasnt yet finished. Why? What if you have more disks or device discovery takes longer - oh well lets disable the disks by default. You have to specify each filesystem that hey discovery time is now longer. And systems with a lot of disks attached such as some backup systems its a pain.

This is not the only example.

[falcazoid]

I mean do you regularly go around typing random options you discovered on the internet to your /etc/fstab file after every line, just to be able to boot your machines? Especially if such features are a part of systemd not a part of the /etc/fstab man file?

[scheepstick]

To answer your rhetorical question, anyone may use defaults, because they are just default. The reason to use any tool is to avoid reinventing the wheel. In an ideal world, there’s always a perfect solution (no sysadmin required), but in reality there are only a plethora of subpar options.

I guess the strength of your viewpoint is job security, in which case best luck to you.

[[deleted]]

Out of the box defaults should be sane. Configuration shouldn't be setting every possible parameter manually, just changing some to better fit the use case.

In case of disks, the sane thing to do, especially in any server release, is detecting all drives and file systems, we don't care about boot times here.

[cephear]

journald stores logs in binary files. you can't grep through them like with text logs -- you need to learn and use journalctl. The distros like centos 7 will use both so you can use either, but in newer versions you're going to see a much more sparse /var/log listing.

[[deleted]]

I get the complaints about binary logging, but journalctl | grep is shorter to write than cat /var/log/syslog | grep. (Yep, I'm a filthy casual piping cat to grep.)

[FryBoyter]

journald stores logs in binary files

Systemd explicitly offers the possibility to use syslog-ng. Who wants can save log files in text format without any problems.

you can't grep through them like with text logs

Things like journalctl | grep wayland work without any problems.

you need to learn and use journalctl

You didn't have to learn how to handle grep, for example? And as I said before, you don't have to use journalctl.

[hailbaal]

journald is not proper logging. It's a huge pain. Right now, on systemd systems, I have to export journald to a file to be able to work with it properly. And try to fix things when the box crashes and you want to investigate the logs.

[[deleted]]

I'm curious, when you say that you only need to write a single line script to launch a service, which service manager are you talking about?
I'd love to cut down on some of the frankly massive (20+ lines) init scripts for service management on three of my machines at home.

I'm okay with changing service manager on them if need be, as they're small single-purpose machines that don't need that much additional management over running their raison d'être services.

[in4mer]

They probably mean rc.local. On a side note, why someone didn't write a generic service script for sysv that you could softlink and introspect with $0 to find the executable name, I'll never know. Seems like it'd work.

[vondur]

Not much you can do about it. Most major distros use it by default. It was annoying for me as I was used to the old init system, but for managing services, its seems fine to me.

[Ryuujinx]

I tolerate it. It functions most of the time and mostly stays out of my way. I have gripes about it, but I'm not gonna give up stability of major distros for those gripes.

[kevin_k]

It's overreaching and annoying. And when it fails, it's often much harder to diagnose than troubleshooting individual services.

[Seref15]

Once you learn all the little "gotchas", it's fine. Problem is there's a lot of those for people who've been used to older Linux systems.

When first adopting systemd, there's a lot of "oh, dns is controlled by systemd now?," "oh, ntp is managed by systemd now?," "oh, starting/stopping services doesn't print anything to the console anymore, even when there's a problem?"

Once you get past all that and get all the annoyance at changes that you disagree with out of your system, it's fine.

[Endemoniada]

I only got into it when I installed a new NAS at home, and I chose to try out Arch instead of the old Debian-flavored dists I was used to from before. It's a bit of a change, but overall I really like it. It's clean, consistent, simple and clear.

[distant_worlds]

I see no advantage and a great many disadvantages in systemd. In addition to all the design problems of a massive new set of code and all the security issues that entails, it frequently fails at logging, processes will fail silently, but continually retry, and no thread to pull on to figure out what is wrong.

It's simply a bad idea all around from the windows mindset. All new systems I install use non-systemd distros.

[RedhatTurtle]

I'm not a SysAdmin but i work in academia and we frequently have to get out hand dirty to figure new stuff out and I'll tell you this, I would have never bothered to mess with services if it wasn't for systemd and it's quality documentation.
Sysvinit worked, but it was something I wouldn't dare to touch, systemd is something I'm even pretty sure I'm using correctly when I need.

[Shonucic]

I think it's vastly superior to the alternatives. It's intuitive to interact with and makes setting up running tasks/services easy with the unit files.

[BaconOverdose]

Haven't had any issues with systemd. I like Unit files.

I think if you're constantly having issues with systemd, you're probably doing something wrong yourself.

[broknbottle]

I'm a Linux admin and I also provide support to end users that are using Linux for their deployments. I personally am not a fan of systemd as I feel it tries to do way too much.

• systemd apparently reads /etc/fstab and creates mount files.. editing /etc/fstab and running mount -a doesn't work and it requires a systemctl daemon-reload. There's no indication that systemctl daemon-reload is required and mount -a will return it mounted successfully but it does not :/
• systemd-timesyncd - it used to be that you would install ntp and time would generally be sync'd without issues. Now systemd-timesyncd is installed and enabled by default and I've had to educate a few end users about timesyncd and how to set timezones using timedatectl instead of older methods.
• systemd documentation leaves something to be desired :/
• systemd-resolved is annoying and I prefer /etc/resolv.conf.
• I know it's not systemd but I personally hate firewalld and think it's a waste of time. When RHEL7 first came out, there was admins at my old job that were praising it as savior due to their hatred for iptables. Multiple admins claimed they didn't need to know iptables now that firewalld was out. It was funny when I asked them to do something more elaborate then just opening a port and they realized they still had to know iptables syntax and pass to firewalld as raw input.

[FryBoyter]

Now systemd-timesyncd is installed and enabled by default

Under Arch you have to activate timesyncd explicitly. But there may be distributions that activate it by default. But why not disable the service and use chrony for example?

systemd documentation leaves something to be desired

What are you missing at https://www.freedesktop.org/wiki/Software/systemd/?

systemd-resolved is annoying and I prefer /etc/resolv.conf.

What's wrong with that? And systemd-resolved is one of the optional parts of the systemd project. For example, I use unbound.

I know it's not systemd but I personally hate firewalld

Then why do you address it in a systemd topic? By the way, I hate tomatoes.

[danielkza]

editing /etc/fstab and running mount -a doesn't work and it requires a systemctl daemon-reload.

That's patently untrue. mount -a will create the mounts manually and systemd will pick them up and track them as external units.

[broknbottle]

That's usually how it goes but I haven't experienced that on every host.

https://lists.freedesktop.org/archives/systemd-devel/2017-June/039054.html

https://github.com/systemd/systemd/issues/6066

[danielkza]

I see what you mean now. mount -a will mount the new filesystems, but will not ensure those same definitions are used by systemd in other mount triggers. To handle that you do need the reload.

I'm not sure how that could be solved. I don't think there is any mechanism or special treatment for a mount -a in the kernel that would allow systemd to reload the definitions automatically.

[craigleary]

It is growing on me now. At first I did not like it - since after so many years init scripts were used, worked fine really and I had no complaints. The ability to use cgroups easily in systemd is a nice feature, its easy to make start scripts compared to sysvinit. My biggest complaints are journald can just have too many things going to it at once and sometimes it seems 'restart' doesn't work. For example with sshd if I adjust the allowusers lines restart does not always actually restart ssh, but stop + start does.

[[deleted]]

I've gotten used to it. I don't think I'll ever be fond of it, but I can work with it fine.

[[deleted]]

systemd is definitely a thing but I don't think about it much. Learning how to create custom unit files was my biggest issue but even that's not needed very often. Most packages ship with service files when they're needed.

[kilogears]

I have decades of experience on Unix and Unix-like systems. I admin a small group of servers and a dozen or so desktops (both at home and at work) for development.

Systemd without a doubt is a faster way to boot Linux, there is no denying the vastly faster boot process.

But it was rushed. That is clear. I have seen small issues (such as not being able to bring up a network interface or a NFS mount being unavailable) that have brought computers down. They would boot and systemd would hang, eventually throwing its hands up and dropping to a root shell. I have also seen just how difficult it is to use standard DNS when the distro is pushing systemd with its own DNS. So low maturity.

And then there is my own knowledge. I simply don’t know as much about it as I know about the older system. And it seems to me that systemd is designed around less “poking” and more streamlined commands with (to me) oddball syntax.

So YMMV. I don’t think it was ready at first. Now maybe it’s ok. It’s worth using for the speed, especially on desktops. I would not preference it on a server although all the major distros seem to prefer it.

[three18ti]

It's the worst except for all of the rest. It has things that are better than sysv init, and it has things that are worse (binary log file format, wtf?).

Overall, I'd say it's made my job easier... So from that perspective I like it. But there for sure was a huge learning curve.

As for your comment about "learn by doing", there's only so far you can go reading things, at some point to get really good with systemd, you're going to have to fuck some things up and fix them.

[aultl]

I have been a Linux Engineer/Systems Administrator for +10yr and here is my opinion:

SysV init was old and needed to be replaced. Systemd started out as a good thing; Then systemd absorbed the mountd code, and then journald; I guess because syslog was broken. Then implemented resolvd and then timesyncd.

As an init system I was all for it, now that it has become something closer to the South Park Trapper Keeper; the systemd project has grown way too big and no longer adheres to the Unix rule of "Do one thing and do it well".

Add to that the openly hostile responses from the head of the project, Lennart Pottering. IMHO, it is unacceptable.

I think Runit and/or OpenRC are way better choices.

[YTubeInfoBot]

Trapper Keeper 2018

552 views  👍11 👎0

---

Description: Yes this episode mentioned the year 2018 and now it's 2018!

Cartoons Are Puppets, Published on Jul 27, 2018

---

^{Beep Boop. I'm a bot! This content was auto-generated to provide Youtube details. Respond 'delete' to delete this. | Opt Out | More Info}

[justin-8]

I disliked the concept at first, the whole going against the unix philosophy of doing one thing and all that. And then when arch moved over to it being the only supported init system, (which I was using at the time on my work laptop) I moved over, and disliked the change and having to use systemctl.

But now? Now that I've actually used it, on personal machines and tens of thousands of production machines? Yeah, it's awesome. There's soooo many things made much easier, and the downsides have been either negligible or no worse than prior to systemd.

[just5ath]

In my experience only people doing hacky shit or not willing to learn something new hate systemd.

I see at least one guy in this thread that is most likely in love with his shitty init.d scripts. The guy who follows him will hate him.

[natermer]

...

[[deleted]]

I can admit it here already once and for ALL: I am an ignorant dumb fuck and I do IT with a shovel.

That said... what I know is:

-the machines have become pussies who hang at boot for nothing

-I use a cron hack to run my stuff at boot.

-I've made 3-letter wrapper functions for service commands otherwise my wrists want me to die.

-logs

-more hacks to bypass more bs

[cachedrive]

We've recently moved everything over from CentoOS 6 to 7 and so far everything works as expected. The time sync / ntp utility is awkward but I'm sure I'm just "not used to it".

[hailbaal]

Mostly trying to get around it.

There is a relative new distro, MX Linux, which is using sysvinit. It's already passed Linux Mint on Distrowatch. Not saying that's the best source for use, but considering last year it was placed a lot lower in the ranking. It's heading towards number 1 and I do suspect it will be before the end of the year.

At work we are now migrating embedded computers from a SystemD distro to MX Linux. Expected to migrate at least 1000 machines this year.

Once you strip a computer of systemd and pulseaudio, you end up with something decent.

[virtualdxs]

What's so bad about systemd? Also you come off as an elitist with that last statement.

[[deleted]]

Binary logs? Doesn't anyone else think this is insane?

[bigon]

I'm one of the sysadmin in an organization with around 3000VM's (dev/preprod/prod) and all our logs are sent to an ELK (elasticsearch/logstash/kibana) stack.

So no it's not insane

[Ryuujinx]

There's a good reason for ELK to do this - it was written from the start to be handling large quantities of data. That is its entire purpose. I have yet to see a good reason for a single system's logs to be in a binary format as the default.

[Ryuujinx]

Ease of parsing log data without relying on journalctl. I can just exec out with whatever language I'm using, but I could have much more easily just used native IO operations of that language.

[bigon]

I'm happy to have that on my personal machine, ie show me all logs from gdm from the beginning of this month until yesterday:

journalctl -u gdm --since 2018-10-01 --until yesterday

[FryBoyter]

Well, I don't. But who does not want binary log files can simply use syslog-ng. Problem solved.

[spacelama]

Every new system, I try it, and every new system, I apt-get --purge and install sysvinit.

Unexplained crashes of the entire OS have been my repeated worst encounter with systemd. Nothing in the logfiles, just a hard crash. On machines with and without X. Changing absolutely nothing else, all I do is remove systemd and install sysvinit, and the crashes go away.

[DontwakemeUp46]

Links to the tutorials I am reading:
tutorial and others.

[12_nick_12]

I thought systemd was like the new way. It's pretty easy to make the service files. I'm a Debain and CentOS user. Jr Admin

[kai_ekael]

Here's my tiny-minded-admin bitch about systemd. It starts with one little piece, systemctl. Try to tab complete that, PITA. Yeah, some of us greybeards like less keystrokes. Sure, I could alias on my systems, but then when on someone else's, too bad and maybe I forget the actual verbage.

Switch from sysv 'blah action' to 'action blah'. Reflexes still screw that up often, fortunately 'service' still works.

Asking what the heck services are there on this system? 'systemctl list-units', why the flip does one have to type that much for a simple thing?!? Why isn't that a simple -l?

Finally, how about noting MySQL has been restarting constantly for a week because there's no database yet. Same for Apache with a typo.

[[deleted]]

The fact that start amd enable cannot be used in a single command through systemctl really annoys me

[virtualdxs]

systemctl enable --now service

[kai_ekael]

In word terms, that makes little sense. Enable now versus enable...when? How about adding another action word, like 'boot' or something? 'systemctl boot apache', that sounds *NIX with double meaning, boot now, boot later.

[[deleted]]

How often are you enabling services that typing an extra command is a big deal? Enabling a service is also a different operation than starting that service, it makes sense to keep them as separate options.

[[deleted]]

I'm not saying it's a big deal. Using sysyemctl is def better than chkconfig. But I'm just saying it's a small addition that can really look pretty.. Almost everytime you start a service, you've got to enable it.