5 ms·

My main complaint is that journald is unreliable and is losing log entries (or lines, if you will). I had an automation recipe that would start a bunch of clou

by pferde 7y ago

My main complaint is that journald is unreliable and is losing log entries (or lines, if you will). I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances. We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line. Again journald is unreliable and as a whole should be nuked from the orbit.

freedomben 7y ago
Interesting, this is the first time I've ever heard this. How long ago did this happen?
- pferde 7y ago
  Sometimes between August and September, and it was on Suse Linux Enterprise Server 12. The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
newnewpdro 7y ago
Filtering journal contents by metadata is known to be unreliable. It's not that the logs are missing, it's that they're not getting included by your query. The way journald associates log lines with process metadata is inherently racy. This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
- pferde 7y ago
  That makes sense, I guess, in a rather warped and bizarre way. The point still stands - journald is unreliable, and after getting burnt like this it will be years before I start trusting it again.
  - newnewpdro 7y ago
    FYI, in case you wanted to document your pain, it might help prioritize fixing it fully: https://github.com/systemd/systemd/issues/2913 https://github.com/systemd/systemd/issues/2913
- dannyw 7y ago
  Great, so why don't we just keep text logs as text files?
  - mateuszf 7y ago
    Filtering text files in a structured way is even harder.
    - pmoriarty 7y ago
      Having unstructured text reliably be in log files is far better than having a broken log daemon forced upon you.
    - eecc 7y ago
      Dedicated tools exist for that...
Yizahi 7y ago
I concur. We also saw an issue with journald missing whole hours of logs, randomly, on our embedded platform. Couldn't replace all of them with log files due to SSD degradation (we actually calculated it we were missing target device lifespan, this is not a consumer problem of course). Basically we added log files where we could, plus remote logs and left journald as-is, it can't be replaced and can't be fixed.

by pferde 7y ago

freedomben 7y ago

Interesting, this is the first time I've ever heard this. How long ago did this happen?

pferde 7y ago
Sometimes between August and September, and it was on Suse Linux Enterprise Server 12. The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.

newnewpdro 7y ago

Filtering journal contents by metadata is known to be unreliable. It's not that the logs are missing, it's that they're not getting included by your query. The way journald associates log lines with process metadata is inherently racy. This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.

pferde 7y ago
That makes sense, I guess, in a rather warped and bizarre way. The point still stands - journald is unreliable, and after getting burnt like this it will be years before I start trusting it again.
- newnewpdro 7y ago
  FYI, in case you wanted to document your pain, it might help prioritize fixing it fully: https://github.com/systemd/systemd/issues/2913 https://github.com/systemd/systemd/issues/2913
dannyw 7y ago
Great, so why don't we just keep text logs as text files?
- mateuszf 7y ago
  Filtering text files in a structured way is even harder.
  - pmoriarty 7y ago
    Having unstructured text reliably be in log files is far better than having a broken log daemon forced upon you.
  - eecc 7y ago
    Dedicated tools exist for that...

Yizahi 7y ago

I concur. We also saw an issue with journald missing whole hours of logs, randomly, on our embedded platform. Couldn't replace all of them with log files due to SSD degradation (we actually calculated it we were missing target device lifespan, this is not a consumer problem of course). Basically we added log files where we could, plus remote logs and left journald as-is, it can't be replaced and can't be fixed.