| View previous topic :: View next topic |
| Author |
Message |
Fulgurance
Veteran
Joined: 15 Feb 2017
Posts: 1199
|
 Posted: Wed Mar 01, 2017 9:42 am Post subject: Systemd and Openrc |
 |
|
| Hello, I have been looking for answers to this question for a while, but I do not find any specific answers. What are the advantages and disadvantages of systemd and openrc? Above all please respond objectively. I do not wish to participate in a war lol. |
|
| Back to top |
|
 |
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland
|
| Posted: Wed Mar 01, 2017 10:11 am Post subject: |
|
|
Disclaimer: I use both, OpenRC and systemd on my PCs.
- systemd generally boots faster if you have lots of services starting at boot, because of the parallel service startup. OpenRC has the feature too, but it's not considered stable yet.
- One could say that systemd has simplier service/init files, where's OpenRC has shell scripts which are easy to write and read if you are familiar with shell scripting already.
- systemd isn't just one utility/binary. It pulls a lot of other tools with it. Some of which it cannot run without. Opinion: Most notoriously the jounal system (binary logs). OpenRC, however, is an enchatement to sysvinit, and does not require much stuff.
- If you plan to build your system with any other libc than glibc, then you have to choose something else than systemd.
Oh, and I think this topic belongs to "Gentoo Chat". Any mod here reading this? 
Last edited by Zucca on Thu Mar 02, 2017 3:27 pm; edited 5 times in total |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54216
Location: 56N 3W
|
| Posted: Wed Mar 01, 2017 10:12 am Post subject: |
|
|
Fulgurance,
Please read The Politics of systemd Part 2 and its predecessor, The Politics of systemd
We have 54 pages and growing on this topic. You won't get new answers here.
This topic will be merged with The Politics of systemd Part 2 when the first non technical response is posted, or locked like so many others, if it turns to a flamefest.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ian.au
Guru
Joined: 07 Apr 2011
Posts: 591
Location: Australia
|
| Posted: Wed Mar 01, 2017 8:32 pm Post subject: Re: Systemd and Openrc |
|
|
| Fulgurance wrote: | | Hello, I have been looking for answers to this question for a while, but I do not find any specific answers. What are the advantages and disadvantages of systemd and openrc? Above all please respond objectively. I do not wish to participate in a war lol. |
The advantage of systemd is that it is the only way recent Gnome3 desktops are officially supported. If you are only running Gnome3 for personal use you can run Gnome3 without systemd via dantrell's overlay, there's a sticky support thread on the forums for that.
I haven't found any other particular upside to systemd, and wouldn't trust it on anything other than a desktop, but maybe others have found some use-cases where it provides some benefit.
I run both, both are stable and functional, so choose what best suits your use-case. If you're new to gentoo and want to learn one init, openRC is far better supported on the forums, as many of the experienced users here don't use systemd.
It's difficult to be more objective unless you state what the purpose of your install will be.
Cheers, |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland
|
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Thu Mar 02, 2017 2:34 pm Post subject: |
|
|
I use OpenRC in my existing Gentoo Linux installations, and systemd in Sabayon Linux installations. The latter (binary) distro, based on Gentoo, dropped support for OpenRC a few years ago.
Zucca summarised well the main differences, although I have not found boot time to be dramatically different in my experiments on older hardware (I have not compared OpenRC and systemd on newer hardware). With an Acer Aspire 5536-643G25Mn laptop (dual-core CPU; 3 GB RAM) — no match for today’s state-of-the-art hardware — the times to boot from the GRUB 2 menu to the DM login screen for a fully-updated 64-bit Sabayon Linux Xfce installation were as follows:
OpenRC with rc_parallel=”NO”..........33 seconds
OpenRC with rc_parallel=”YES”.........31 seconds
systemd.........................................29 seconds
In the vast majority of cases I do not have to touch OpenRC initscripts or systemd unit files, so on that score I feel there is little to influence one's choice. Command syntax of course differs between the two, and you can make up your own mind as to which you prefer by consulting articles that compare the two, such as the following two Gentoo Wiki articles:
https://wiki.gentoo.org/wiki/OpenRC_to_Systemd_Cheatsheet
https://wiki.gentoo.org/wiki/Systemd#Native_services
One point to consider is that the developers of some upstream applications develop with systemd in mind and tend to ignore the latest versions of ConsoleKit (a.k.a. ConsoleKit2 after it was forked). For example, until a recent patch was submitted (committed but not yet included in a release), in order to suspend and hibernate from the greeter screen the LightDM display manager only used systemd-logind, falling back to upower <0.99.0 (so, in reality, only systemd-logind), meaning that users without systemd could not suspend/hibernate from the greeter screen (not a big deal in this particular example).
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
Goverp
Veteran
Joined: 07 Mar 2007
Posts: 1995
|
| Posted: Fri Mar 03, 2017 10:17 am Post subject: |
|
|
As mentioned above, systemd comes with its own logging implementation journald, that's very different to syslog-ng and the like. In particular, it doesn't do networked logging, except by installing extra stuff to redirect logs to say syslog-ng. Its front-end, journalctl, has some useful smarts, such as partitioning the logs into separate pieces for each system boot, but that's not exactly rocket science with say less reading /var/log/messages.
_________________
Greybeard |
|
| Back to top |
|
|
C5ace
Guru
Joined: 23 Dec 2013
Posts: 472
Location: Brisbane, Australia
|
| Posted: Fri Mar 03, 2017 10:26 am Post subject: |
|
|
| I moved away from OpenSuse to Gentoo with openrc when they changed to systemd. The main reason was that I could not read the log files with a standard text editor like nano through SSH. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland
|
| Posted: Fri Mar 03, 2017 1:05 pm Post subject: |
|
|
| C5ace wrote: | | I moved away from OpenSuse to Gentoo with openrc when they changed to systemd. The main reason was that I could not read the log files with a standard text editor like nano through SSH. |
You can tell journald to redirect the logs to (for example) syslog-ng. How ever in my experience, if you encounter a crash/system freeze journald doesn't (have time?) redirect the very last messages. Although that was quite a long time ago. The issue may have been fixed.
Other problem with journald is log file corruption that usually happens when system freezes. There is however some ways to recover.
The good side with jounald is that systemd can use it to quickly display log messages of a single particular service/program when you query for the status of the service/program in question.
Because systemd is somewhat a new, completely different init+service manager, I keep only stable versions of systemd installed on my ~amd64 desktop. This is because I trust Gentoo package maintainers more than systemd upstream to choose which version of systemd is stable enough. ;)
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
i4dnf
Apprentice
Joined: 18 Sep 2005
Posts: 271
Location: Bucharest, Romania
|
| Posted: Fri Mar 03, 2017 2:25 pm Post subject: |
|
|
| Zucca wrote: | | The good side with jounald is that systemd can use it to quickly display log messages of a single particular service/program when you query for the status of the service/program in question. |
Or you can configure syslog-ng to split the logs based on whatever rule you want (facility/boot/program etc), and all the various logs are still accessible/redable, without needing a running systemd/journald instance, and even in the event of a system crash, as long as the medium on which they are stored is accessible/readable.
_________________
"The only difference between me and a madman is that I am not MAD" (SALVATOR DALI) |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Mar 03, 2017 8:35 pm Post subject: |
|
|
| One real, objective advantage of systemd is that it makes other distros suck far less. We already had OpenRC, but distros like Fedora, Debian etc. were still living in the dark ages of a giant hairball of ad-hoc init.d shell scripts. If you have to admin a bunch of disparate OSes regularly then limiting their options can be seen as a good thing. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3339
Location: Rasi, Finland
|
| Posted: Fri Mar 03, 2017 9:00 pm Post subject: |
|
|
| i4dnf wrote: | | Or you can configure syslog-ng to split the logs based on whatever rule you want... |
Yes. But with journald you don't need to configure that. You can specifically ask certain logs. Although propely formatted syslog logs are simply parseable using common *NIX tools, like grep... and can be highly compressed. It's not uncommon to have journald binary logs that exceed few gigabytes, although this can be limited by editing journald.conf.
I have not found many pros from the systemd-journald when compared to plain text logs. However systemd requires journald for some reason. I guess it uses it as a database too to quickly analyze what has happened.
Maybe someole else with more knowledge on systemd-journald can enlighten us...
Oh, and please everyone: let's keep this topic in track. We already have some other topics that are there to bash systemd. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Mar 03, 2017 9:04 pm Post subject: |
|
|
To the tune of Irving Berlin's "Anything You Can Do", anything journald can do, syslog-ng can do better.
Including populating a database for independent parsing and analysis. Yeah, it can be some work to setup, but syslog-ng facilitates a modular arrangement, with its @include. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Fri Mar 03, 2017 9:54 pm Post subject: |
|
|
| Quote: | | Oh, and please everyone: let's keep this topic in track. |
Half-hearted apologies for my half-hearted bash of systemd. This thread has been very informative for me. I would probably not seek them otherwise, so the well-expressed, informed comparisons are a genuine treat. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Mar 03, 2017 11:04 pm Post subject: |
|
|
| Zucca wrote: | | Oh, and please everyone: let's keep this topic in track. We already have some other topics that are there to bash systemd. ;) |
Zucca ... thus speaks the voice of neutrality ... I'm almost inclined to think that I could say something reasonable on the subject and not have it labelled "bashing" (or what-have-you), but ok, you all have a discussion about systemd as though it were some isolated event with no more significance than "journald x,y,z".
best ... khay |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3131
|
| Posted: Sat Mar 04, 2017 10:15 am Post subject: |
|
|
| Quote: | | One real, objective advantage of systemd is that it makes other distros suck far less. We already had OpenRC, but distros like Fedora, Debian etc. were still living in the dark ages of a giant hairball of ad-hoc init.d shell scripts. If you have to admin a bunch of disparate OSes regularly then limiting their options can be seen as a good thing. |
Ubuntu: Using systemd together with their old init system (upstart?) certainly sucks less than using only the old init system 
I dare to disagree.
Hell, even really old. purely sequential shell-based init (you know, the one with scripts numbered by subsystem) was better than that. It had 2 major advantages: It was embarrassingly simple (easy to understand) and it was embarrassingly simple (impossible to break)
Performance issues? Well, sure, I'd rather my phone switched on instantly, but I really don't care that much if my PC boots in 5 seconds or 50 seconds. 500 seconds would bother me much more, but we're not there, so whatever.
Anyway, what's so wrong about ad-hock init scripts? As long as they are executed in the correct order.... |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Sat Mar 04, 2017 5:46 pm Post subject: |
|
|
| szatox wrote: | | Anyway, what's so wrong about ad-hock init scripts? |
The problem with ad-hoc scripts, much like the problem with very low level languages, is that there is nothing in the language to encourage good practice. Some authors will write to strictly Bourne-compatible sh. Others will write with Bash extensions. Some will have excellent error handling that helps the user through every likely problem. Others will assume everything always works, and any errors will result in bizarre and sometimes misleading messages. Some will take varying measures to protect the user from stupid mistakes (including stupid security mistakes). Others will trust the user to be infallible.
On the other side, adding structure can prevent some of these problems, but falls into the GUI trap. With enough structure, it becomes possible to do only those things that the structure-builder wants you to do. Deviating from that plan becomes painful. If the structure-builder is a domain expert and provides for all the things you reasonably should want to do, this works out very well. Otherwise, it ends badly, either with tasks that are impossible or that resort to grafting ad-hoc scripts into the middle of an otherwise structured system.
For this purpose, I would say Gentoo's OpenRC based system is not purely ad-hoc scripts, since it provides a library of helper functions to address common tasks (print in color, change indent level, accept standard option names, etc.). I have not used it enough to judge whether it provides enough structure. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Mar 04, 2017 7:20 pm Post subject: |
|
|
| szatox wrote: | | Anyway, what's so wrong about ad-hock init scripts? As long as they are executed in the correct order.... |
The average Debian initscript (the ones I've had to deal with at least) tend to be 10x as long as the equivalent in OpenRC (100x as long as a runit script). They have no guards against common errors like double-starting unless someone writes or copies the code to do that. There's no consistency in metadata or runtime state, half of them are missing LSB headers and don't work with insserv, and they all spray lockfiles and pidfiles everywhere (sometimes failing to clean up after themselves, sometimes forcing the user to do so by hand).
As for Upstart, it was nice in theory but it just ended up as a fat wrapper around the bulk of LSB scripts they never ported. The only reason it didn't quietly die like einit/initng was a BDFL in a position to order it deployed to millions of users. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom
|
| Posted: Sat Mar 04, 2017 8:48 pm Post subject: |
|
|
Regarding systemd-journald vs OpenRC+syslog-ng, has anyone done any performance benchmarking of the two alternatives on identical hardware? The reason I ask is because, in my limited experience, systemd-journald appears able to begin logging earlier than OpenRC+syslog-ng. I'll give you two examples from a few years ago on similar (not identical) hardware:
1. I noticed that syslog-ng did not record the microcode update for the first CPU core when the kernel early microcode update was applied, whereas systemd-journald logged the update for the first CPU core, i.e. systemd-journald appeared capable of capturing events that occur earlier in the boot process.
2. While debugging a problem with NetworkManager, I noticed /var/log/messages did not contain the earliest NetworkManager messages at boot, so I configured /etc/rc.conf to make the starting of NetworkManager contingent on syslog-ng having started, just so I could check what the first NetworkManager messages were. On another machine, systemd-journald did log those early first NetworkManager messages without me needing to delay the starting of NetworkManager.
I hasten to add that the above were not controlled experiments, but I was left with the impression that systemd-journald is able to capture earlier events than OpenRC+syslog-ng can capture on identical hardware. From my limited knowledge of the architectures of the two systems, this seems plausible given that systemd has so much in PID1. But, as I say, this is my impression and would need to be benchmarked properly on identical hardware with comparable Gentoo installations (systemd & sysVinit+OpenRC+syslog-ng excepted, of course).
Putting aside any performance differences, I personally prefer ASCII logging due to its ease of access and manipulation on my laptops and headless server, and lower possibility of corruption in comparison to binary log files. (On a very minor note, I prefer syslog-ng's line wrapping to journald's default approach of truncating lines to the width of the terminal, although of course it is possible to configure journald to wrap rather than truncate.)
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.
Fitzcarraldo's blog |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Sat Mar 04, 2017 9:31 pm Post subject: |
|
|
On my system, syslog-ng is a "late starter," somewhere in the default group.
dmesg picks up the early kernel stuff.
I've never studied or cared about getting syslog-ng to "start early," so not much help there. If I have a service that is giving me fits, I have been know to tell it to log itself (no logging daemon involved).
I think there is no question that systemd is capable of starting logging before the "quickest syslog-ng" could. |
|
| Back to top |
|
|
shevy
n00b
Joined: 28 Aug 2017
Posts: 16
|
| Posted: Sun Mar 11, 2018 3:22 am Post subject: |
|
|
> Regarding systemd-journald vs OpenRC+syslog-ng,
I do not entirely understand this.
Systemd evidently has its format specified and uses it, but could you not use OpenRC and then on top of it
any other logger/model? If the systemd devs would not deliberately want to run as the BORG to bundle
everything together, one could even do something crazy like combine systemd-binary logs (if it were
implemented as a library) and combine it with OpenRC. Not that I'd recommend or know anyone who
would have such a crazy idea see it implemented ... just saying!
> The average Debian initscript (the ones I've had to deal with at least) tend to be 10x as long
Yeah, they started from an extremely low quality/standard. I found shell scripts to be prone to
ugliness. Has nobody tried to use other languages or even a simple custom format that is
easier to use?
> Otherwise, it ends badly, either with tasks that are impossible or that resort to grafting ad-hoc
> scripts into the middle of an otherwise structured system.
I agree with this but why aren't proper programming languages used? I am not even suggesting
any language - just anything other than shell scripts. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Sun Mar 11, 2018 4:24 am Post subject: |
|
|
The problem breaks into 3 parts: systemd and openRC and everyone else. Systemd was written to fix "everyone else." OpenRC and systemd are both modern implementations meant to fix the same problem.
The biggest problem with systemd is that it is a large project that does everything therefore breakages can be very difficult to trance and tend to affect large areas of the system. In one case it even corrupted my entire install in arch. 
OpenRC is much simpler therefore less prone to breakages. It also doesn't keep a complex PID 1 running since if a PID 1 program crashes it takes the system with it. (technically OpenRC doesn't include the process at all since it belongs to another program, but details) Systemd places itself as PID 1. Systemd unit files are very simple while OpenRC scripts can be very complex. However, Open RC scripts are much more flexible particularly in regards to dependencies.
Systemd does include many features that may or may not be useful. The "ohh, shiny" feature creep. If you want them, fine but chances are you won't even notice 99% of them.
I think the biggest review of systemd, in my opinion, is that a very large percentage of professional system admins rushed to install non-systemd LTS Linux systems stating that systemd was resource hungry, prone to breakage, and didn't offer them anything worth the extra effort.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
