4 ms·

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. journalctl supports -f, which by your own account you w

> I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. 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.

saghm 3y ago
> journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there 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.
- stoperaticless 3y ago
  Never tried it, but if the complainer wrote: tail -f *.logs Which involves glob’ing. I assume it allows to monitor several services at the same time. Can systemd do that?
  - tapoxi 3y ago
    Yes, journalctl -u postgres -u redis -f etc
    - mintplant 3y ago
      Or just `journalctl -f` to follow all logs.
  - _flux 3y ago
    It's the basic function what journalctl -f does by default: follow the global log all jobs write into. -u etc are for filtering that.
- mdaniel 3y ago
  > I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago. 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
cogman10 3y ago
I think my biggest gripe with journalctl is (and this may just be because I'm novice at using it) that discovering what sort of logs are on the system feels a lot more complex. 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.
- tapoxi 3y ago
  It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache And you don't need to worry about "is this service rotating logs appropriately?"
  - cogman10 3y ago
    The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box. 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.
    - tapoxi 3y ago
      I mean "systemctl status" shows all services and their hierarchy, there's also "systemctl list-unit-files" if you want to see things that aren't part of the current target (runlevel). 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.
      - cogman10 3y ago
        Ah, good to know. I figured it might be the case that I just needed to RTFM.
    - 3y ago
cduzz 3y ago
I appreciate that someone's invented shoes you inflate and snap. I can see some advantages. 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.
- acdha 3y ago
  Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.
  - llm_trw 3y ago
    >think of it as learning one tool which works for everything. 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.
    - olddustytrail 3y ago
      > For how long? Debian switched to systemd about 12 years ago, so at least that long.
      - llm_trw 3y ago
        Find came out in 1974.
      - cduzz 3y ago
Asmod4n 3y ago
Oh the joy it is to have a corrupted log file which the program that wrote it refuses to even read. 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.
citrin_ru 3y ago
'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.
- rezonant 3y ago
  While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.
SoftTalker 3y ago
Not my memory at all. In almost all cases the logs were in /var/log and written by syslog. Unless the whole service was in a chroot directory, or the program was written by an amateur who didn't follow logging conventions.
hmmm-i-wonder 3y ago
This and many other discussions misses the point that most people that don't like systemd have with it. 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.
- intelfx 3y ago
  > If it actively solved problems for the majority of users we wouldn't hate it so much It does and we don't. The only "we" who are "hating it so much" is a tiny vocal minority.
  - hmmm-i-wonder 3y ago
    Ahh the vocal minority in support makes its appearance! 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.

saghm 3y ago

> journalctl supports -f, which by your own account you were already using for tail, so I'm not clear what's worse there 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.

stoperaticless 3y ago
Never tried it, but if the complainer wrote: tail -f *.logs Which involves glob’ing. I assume it allows to monitor several services at the same time. Can systemd do that?
- tapoxi 3y ago
  Yes, journalctl -u postgres -u redis -f etc
  - mintplant 3y ago
    Or just `journalctl -f` to follow all logs.
- _flux 3y ago
  It's the basic function what journalctl -f does by default: follow the global log all jobs write into. -u etc are for filtering that.
mdaniel 3y ago
> I'd just make an alias to "journalctl --follow --nopager"` and would have forgotten about it years ago. 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

cogman10 3y ago

I think my biggest gripe with journalctl is (and this may just be because I'm novice at using it) that discovering what sort of logs are on the system feels a lot more complex. 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.

tapoxi 3y ago
It's just journalctl -u apache -f, assuming your distribution calls the unit file "apache", and the last few messages of the logfile appear with systemctl status apache And you don't need to worry about "is this service rotating logs appropriately?"
- cogman10 3y ago
  The important thing for me at least isn't he `-u apache` but rather knowing that `apache` exists as one of the installed services on this box. 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.
  - tapoxi 3y ago
    I mean "systemctl status" shows all services and their hierarchy, there's also "systemctl list-unit-files" if you want to see things that aren't part of the current target (runlevel). 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.
    - cogman10 3y ago
      Ah, good to know. I figured it might be the case that I just needed to RTFM.
  - 3y ago

cduzz 3y ago

I appreciate that someone's invented shoes you inflate and snap. I can see some advantages. 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.

acdha 3y ago
Don’t think of it as relearning a tool, think of it as learning one tool which works for everything. You no longer have to implement your own log rotation, compression, etc. or work out which configuration each program needs to do that in the manner you expect – for example, “is it safe to rotate a log file?” requires you to know implementation details on each program.
- llm_trw 3y ago
  >think of it as learning one tool which works for everything. 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.
  - olddustytrail 3y ago
    > For how long? Debian switched to systemd about 12 years ago, so at least that long.
    - llm_trw 3y ago
      Find came out in 1974.
    - cduzz 3y ago

Asmod4n 3y ago

Oh the joy it is to have a corrupted log file which the program that wrote it refuses to even read. 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.

citrin_ru 3y ago

'journalctl -u service -f' takes many seconds to start showing logs (even with 4GB journal size limit which not that much). 'tail -f /var/log/service' works without a noticeable delay (be it 1kb or 100Gb log file). For me it's a huge regression.

rezonant 3y ago
While I'm very pro journalctl, this is very true. They should put some work into the initial read performance on big journals.

SoftTalker 3y ago

Not my memory at all. In almost all cases the logs were in /var/log and written by syslog. Unless the whole service was in a chroot directory, or the program was written by an amateur who didn't follow logging conventions.

hmmm-i-wonder 3y ago

This and many other discussions misses the point that most people that don't like systemd have with it. 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.

intelfx 3y ago
> If it actively solved problems for the majority of users we wouldn't hate it so much It does and we don't. The only "we" who are "hating it so much" is a tiny vocal minority.
- hmmm-i-wonder 3y ago
  Ahh the vocal minority in support makes its appearance! 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.