For example, systemd timers (timed systemctl services) are like cron if cron was slightly more complicated and had very good logging. :3

journalctl is a text adventure fever dream. Do systemd timers use a different logging system?

You can output journald to syslog with one config option[1].

1. https://www.freedesktop.org/software/systemd/man/systemd-jou...

Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered.

I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine.

But don't make me use journalctl just to tail a god damned file like a normal person.

Edit: I may have reached that point on friday night where the bottle of port and my grey beard have finally reached "old man yells at cloud" stage. My apologies.

> Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered.

I absolutely love the idea of journalctl (without commenting on the execution).

As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time.

Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable.

As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way.

And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)

It also allows you to read the logs in JSON, which is fantastic for automation. Parsing the syslog as a text file means a single newline in a syslog message screws your effort up. With journalctl, you can sift through error messages from specific services, confident that the results you are getting are exactly what the logs contain.

Unless, of course, some of the binaries are corrupt.

What is the advantage to having to write all the log messages twice instead of once? What is the disadvantage in having to type "journalctl -f" instead of "tail -f"?

My usual "tail" is not tail -f, but tail -n 100. In fact, I jump around a ton doing tails and heads with varying linecounts, and if it gets unweildy even after all of that, that's when I pipe to less and look at it.

My major justification is I use tail and head constantly, every single day, and it's rarely on system logging. It's java logs, it's python logs, it's rust logs. I'm not going to be giving up tail or head any time soon.

Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working.

Put another way, this is the exact WORST time to throw up more roadblocks over something. That's why I assert it should be logged twice, and for those who don't want it to be chewing up diskspace or want to relocate it, well, that's where you can configure it.

I just want my old log files back in their old locations without forcing me to sift through man pages when all I really want to do is figure out why the fucking bluetooth keeps dropping connection. I understand why others see this as a great step forward but it sounds more like the windows registry and event viewer to me than it does the configuration file and log file approach I adore from my unix systems. I'm sure the registry and event viewer has a lot of devoted fans as well; the difference is it's been there for most of my life (or at least, the parts where I was doing more than playing X-Wing vs Tie Fighter), which is why I mostly just wandered away. I'm not a sysadmin, I don't try to be and I don't want to be, and it seems like systemd is hellbent on forcing me to be one whether I want to be or not and I am so not here for it.

Then it's "journalctl -n 100". Or "journalctl | less".

> Now I have to type "journalctl --help" every single time I want to look at a system or daemon log, which isn't super common, and when I do need to I'm already frustrated something isn't working.

I don't think that keeping users from ever having to learn anything new is a good justification for doing things a particular way.

> I'm not a sysadmin, I don't try to be and I don't want to be, and it seems like systemd is hellbent on forcing me to be one

Personally I don't understand this sentiment. As a user I have found that systemd has made using Linux systems much simpler for me. Yes, I had to read a manual, but I don't think that is anything like "forcing me to be a sysadmin". Didn't you have to read the manual for tail at some point in the past?

Nope, tail is such a trivially easy program to use. There's like 2 switches that matter to me, one of which requires a value as well. Keeping things super simple is a really important thing, and I guess I had taken it for granted that everyone using gnu-style tools would be on the same wavelength - for the most part, at any rate. FWIW, I can't bear to read the awk or sed man pages either.

I fundamentally agree with you; learning something new is not necessarily a bad thing. Forcing you to learn something when you're actively trying to figure something utterly unrelated out is where it gets dicey. Not everyone wants to do the "Malcom in the Middle Hal Changing a Lightbulb" routine when there's already a Very Important Thing to Fix.

The problem with systemd is that it took something that already worked perfectly fine for my needs and said "let's overengineer the everloving pants out of this! get in the car grandpa, it's time to roll!" I didn't ask for it, I have WAY more important (to me!) things to do, and it's actively running interference with that. Surely you can see that level of frustration, right?

Put another way, I'm sure it's a LOVELY bikeshed for some. Some people have wanted a bikeshed this fantastic and wonderful for a long time, and they will use this bikeshed with great joy daily.

Meanwhile, every time I'm trying to get something I actually care about done, it's like pulling teeth. Maybe I'm using it wrong, and I'll be the first to admit I have the patience of a toddler when it comes to reading the man pages. What I can DEFINITELY say, though, is that if systemd never existed my quality of life would be doubtless better than it does with it existing. That's really the only metric I need.

Like I said: definitely in old man yells at cloud territory, maybe crossed with a dash of lazy man commits to further laziness and myopic man can't see the forest for the trees. I'm not saying you are bad to like systemd, I'm saying that it made changes I didn't ask for, it didn't do it in a way that was painless and approachable without a time commitment, and I've yet to be satisfactorily convinced that the value proposition is worth it - not for my uses, at any rate.

What I hate is not that it logs to a journal log, it is that the binary db used by journald is non-standard and undocumented.

This means that a dead system can potentially not be read by a live system, as the journal can have undocumented breaking changes.

It is documented, but the documentation is unfortunately not authoritative: https://www.freedesktop.org/wiki/Software/systemd/journal-fi...

Also, they couldn't make breaking changes to the format or it would prevent people from reading their own old log files after upgrades

Fuck, not this shit again.

If I get some 3rd party documentation, that says it may or may not be correct, and the implementation is literally the only authorative documentation then it isn't actually documented.

> they couldn't make breaking changes to the format or it would prevent people from reading their own old log files after upgrades

This is the point. They do not guarantee that you can.

Nope, they go straight to journald.

It tries to do too much, badly, and with an air of entitlement around intentionally breaking things.

Change is good, so let's change away from systemd.

If someone is able to create something that is half as good as systemd then distros will switch time it.

The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.

What is desireable to a distro maintainer is offten not what is desireable to a user or admin.

Systemd favors the distro maintainer and cloud application service provider, and maybe the appliance manufacturer.

It's the exact opposite of a useful tool empowering the the individual.

As an admin and desktop user I like systemd. I have to write less config and less boilerplate code to shore up dependencies across networking, mounts, and things like DNS than I did back in the sysv days. That time saving enables me to get on with other, more useful things.

As a lowly JS developer, I have had a positive experience with systemd. One service file and it handles logging and process management. Better than the insane options the JS community cooked up IMO.

> If someone is able to create something that is half as good as systemd then distros will switch time it.

Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.

systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years.

Unlike e.g. upstart in its native mode, systemd can run SysV init scripts.

https://unix.stackexchange.com/questions/233468/how-does-sys...

By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.

True, but on that point xe was correct because it's the one part of systemd that is neither PID1 nor optional; I was assuming session manager referred to systemd-logind.