7 ms·

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

by yarrel 6y ago

simcop2387 6y ago
Nope, they go straight to journald.
deadbunny 6y ago
You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
- isbjorn16 6y ago
  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.
  - majewsky 6y ago
    > 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.)
    - viluon 6y ago
      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.
  - shawnz 6y ago
    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"?
    - isbjorn16 6y ago
      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.
      - shawnz 6y ago
        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?
  - happymellon 6y ago
    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.
    - shawnz 6y ago
      It is documented, but the documentation is unfortunately not authoritative: https://www.freedesktop.org/wiki/Software/systemd/journal-files/ 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
      - happymellon 6y ago
        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.

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

by yarrel 6y ago

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

simcop2387 6y ago

Nope, they go straight to journald.

deadbunny 6y ago

You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...

isbjorn16 6y ago
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.
- majewsky 6y ago
  > 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.)
  - viluon 6y ago
    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.
- shawnz 6y ago
  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"?
  - isbjorn16 6y ago
    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.
    - shawnz 6y ago
      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?
- happymellon 6y ago
  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.
  - shawnz 6y ago
    It is documented, but the documentation is unfortunately not authoritative: https://www.freedesktop.org/wiki/Software/systemd/journal-files/ 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
    - happymellon 6y ago
      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.