Run0, a systemd based alternative to sudo, announced

journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there.

> I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

My memory of this time was that every single application had its own unique method of handling logs and its own unique location for storing them. So sure, once you found the logs you didn't have to Google how to find the relevant dates if the application is using logrotate as you describe, but finding the logs in the first place was always a challenge. Systemd is nice in that it provides a single place where all logs go and a single interface for navigating them.

Yeah, this is a bit of an odd complaint. If I were this bothered by having to type those, I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago.

Which involves glob’ing. I assume it allows to monitor several services at the same time.

Can systemd do that?

With regular logs, I can go to /var/log, ls the dir, and get a nice list of what's being logged. There will be, for example, an `apache.log` file that has all the logs relevant to apache.

You sure would have forgotten about it when you tried to get onto another machine without the magic set of aliases

I am also prepared for someone to chime in that "log egress tools exist" to move up the Maslow's Hierarchy of Log Needs

And you don't need to worry about "is this service rotating logs appropriately?"

In the old ways, that was apparent because of the presence of the log file.

Granted, this isn't the problem it used to be for us, however, it would come up because we'd have our services named things like `foo-ws` and knowing that `foo-ws` existed on a given box might be tricky were it not for the log files.

It's much easier in the systemd world to see the state of the system, the state of the service, and the logs of a service because it enforces this consistency.

    journalctl -f -u <TAB>

That said, when I'm in a hurry and going to do a thing that I've been doing every day of my life, I'm really not a big fan of having to stop what I'm doing and reexamine a tool I've used all my life to figure out how to use it. I learned this stuff decades ago and I'm not anxious to relearn how to do it for a fractional improvement, and I'm not even really 100% sure that this new "inflate and snap" shoe model is actually an improvement, except for very specific use cases.

Once you deal with that you’ll realize journald is just in the way and needs to be modified to output a human readable log by default.

For how long?

I've been around for decades at this point with people telling me how the newest and greatest thing will obsolete everything that came before it.

The best way to look through logs is still to materialize them in as text in a files hierarchy and use find with grep to look for issues.

There should be a command like "journalctl --top" that would list all logging services with amount of logs, oldest and latest log times, and last few lines of each, to improve that experience. Maybe there is already a way to do something similar?

Debian switched to systemd about 12 years ago, so at least that long.

Perhaps it was available prior to then, but so were daemontools, upstart, and probably a variety of other alternatives.

a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime of the log, for instance), than this.

look, i think systemd isn’t.. terrible. i also think it’s suffered a bit of complexity fetishisation, and it seems as though that this resulting complexity may have become invisible to you.

run0 doesn’t seem like a bad idea. but i am wincing a bit at the thought of unrestricted javascript determining access control.

Journald would be perfect if I didn't have to know a thing about it. Work in background, move stuff from stdin/stdout to /var/log/journald/service.log, move old stuff in /var/log/journald/archive/service/2024-04/15.log.gz. I'd be happy. Why do I need this cryptic CLI I don't understand. It brings nothing but pain.

It can largely do everything it replaces, but differently, in some cases with improvements. Every year it increases its scope of 'problems' its solved.

But the issue is it hasn't _ACTUALLY_ solved a problem for me in about a decade, its only introduced problems. Its replaced things that worked perfectly for me and millions of other users for years/decades with something that... also works... but differently. Now to accomplish the _SAME_ outcome without any personal benefit I have to re-learn their new and usually opinionated way.

There was a time I could log into a system, find logs, parse dates and do everything in these discussions reletave to logs, rotation. Regardless of service because the standards were close enough and the basic tooling (tail/find/tar/grep/awk etc.) worked everywhere always, and you never had to google even if the service was one you never worked on before.

For systemd its the opposite, its almost a guarantee you have to google something along the line when interacting with new systems and services. And as soon as their newly enforced opinions and way of doing things is getting comfortable they go and replace something else that was also working... perfectly fine.

If it actively solved problems for the majority of users we wouldn't hate it so much. Instead it requires more mental overhead than anything other than XORG to deal with and constantly manage than anything else in the linux ecosystem.

It does and we don't. The only "we" who are "hating it so much" is a tiny vocal minority.

I wouldn't call the opposition tiny, although the vocal portion of any group tends to be the smallest. This would be my first online comment on it so I'm certainly part of the non-vocal group you ignore, that in my experience is significantly larger than the vocal side of group you dismiss.