3 ms·

I agree, and I am one of the people who has some major gripes with systemd through experience. I admit it's a reality and people should learn it, but the proble

I agree, and I am one of the people who has some major gripes with systemd through experience. I admit it's a reality and people should learn it, but the problem is not many people have, and sometimes it really makes things that used to be much easier not necessarily more difficult (though sometimes), but rather more complicated (there is a difference). For example, I always found writing a sysvinit service pretty straight forward, but systemd units can get unweildy especially when doing anything complex, though I will admit some of the features are nice if you can figure them out, such as when in the init proc to start, vs having to do that manually in sysvinit scripts. It also often fails to admit when it is failing, for example, nobody I know uses journald as the main or only logging system, and are still piping to local (r)syslog(ng) and then to elk/splunk, etc, because journald is simply not up to par. In general, and I'm just being honest here, besides these mostly work-aroundable issues, it is the seeming disingenuousness of those who automatically rail against anybody who criticises systemd that makes me not like it. Call me a contrarian, but I hate being told I must like X and if I don't I'm dumb and behind the times, and my nature is to push back against that. In that vein, I support the efforts of Devuan and similar projects if only to support a counter-balance.

habarnam 7y ago
> [..] elk/splunk, etc, because journald is simply not up to par. Could you expand on what's not up to par in journald vs. rsyslog? Watching textfiles for changes vs. receiving data on a non blocking socket is definitely _not_ more efficient (nor "better" in my opinion).
- arminiusreturns 7y ago
  Mostly related to the tooling around those things, especially when dealing with groups of machines sending logs to a central system. It's worth remembering you are still using journald when using one of the syslogs, it's just forwarding all the journal messages to the syslog socket. As the tooling catches up this gap will close. For example the json output of journald can be really useful, that said, most of the tools still require some change of the output from the binary format which they can't read to a text format whether that be json or syslog... and the binary format in general being a general pain point if (read: when) things break (such as corruption of the whole journal past corruption point vs one section of text in syslog). It's worth remembering that journald was designed for local system use. It's just one more of the reasons I had some hesitation with systemd but got shouted down by everyone on the systemd bandwagon.

habarnam 7y ago

> [..] elk/splunk, etc, because journald is simply not up to par. Could you expand on what's not up to par in journald vs. rsyslog? Watching textfiles for changes vs. receiving data on a non blocking socket is definitely _not_ more efficient (nor "better" in my opinion).

arminiusreturns 7y ago
Mostly related to the tooling around those things, especially when dealing with groups of machines sending logs to a central system. It's worth remembering you are still using journald when using one of the syslogs, it's just forwarding all the journal messages to the syslog socket. As the tooling catches up this gap will close. For example the json output of journald can be really useful, that said, most of the tools still require some change of the output from the binary format which they can't read to a text format whether that be json or syslog... and the binary format in general being a general pain point if (read: when) things break (such as corruption of the whole journal past corruption point vs one section of text in syslog). It's worth remembering that journald was designed for local system use. It's just one more of the reasons I had some hesitation with systemd but got shouted down by everyone on the systemd bandwagon.