4 ms·

What kind of desktop do you have where your journal is constantly getting corrupted? Most distributions log both to the journal and to /var/log/, so I'm seriou

What kind of desktop do you have where your journal is constantly getting corrupted? Most distributions log both to the journal and to /var/log/, so I'm seriously struggling to understand the complaint here. GP's message about centralized logging is saying that if logs are that important to you, you will keep them stored in a centralized location. You should be able to catch the server on fire and have logs recorded centrally up until that point. This would be the case with or without journald. You started with a strawman about caring about logs, and ended complaining about sysfs.

0xbadcafebee 5y ago
Yeah I digressed quite a bit, sorry. > I'm seriously struggling to understand the complaint here The complaint was trying to explain a parent commenter's point about journald "They’re really nice until everything on the node is completely broken. Then they are a massive obstruction to access and understanding what went wrong due to the opaqueness." Point: Logs are really annoying to manage on systems with journald. Counter-point: Ship your logs somewhere else / you probably don't have these problems in real life Counter-Counter: If we're not supposed to use these tools on our hosts, exactly why are they installed?
- fullstop 5y ago
  Logs are written to both the journal and /var/log/ I would argue that logs are less annoying to manage on systems with journald, once you take the time to learn how to leverage the tools. I would also argue that shipping mission-critical logs off-server is a worthy endeavor, regardless of logging system used. I like journald because it lets me isolate logs for a particular unit without grepping and accidentally including output from unrelated services. It's faster to find the data that I need between time ranges rather than manually comparing time stamps. I can count on one finger the number of times the journal has been corrupted on the servers that I manage, and it was because of hardware failure.
  - deleted 5y ago
    [deleted]
  - mousepilot 5y ago
    I have this fantasy that all the pro systemd posts are really just bots run by leonard
    - fullstop 5y ago
      I, Leonard, do not know of what you speak. ;-)

0xbadcafebee 5y ago

Yeah I digressed quite a bit, sorry. > I'm seriously struggling to understand the complaint here The complaint was trying to explain a parent commenter's point about journald "They’re really nice until everything on the node is completely broken. Then they are a massive obstruction to access and understanding what went wrong due to the opaqueness." Point: Logs are really annoying to manage on systems with journald. Counter-point: Ship your logs somewhere else / you probably don't have these problems in real life Counter-Counter: If we're not supposed to use these tools on our hosts, exactly why are they installed?

fullstop 5y ago
Logs are written to both the journal and /var/log/ I would argue that logs are less annoying to manage on systems with journald, once you take the time to learn how to leverage the tools. I would also argue that shipping mission-critical logs off-server is a worthy endeavor, regardless of logging system used. I like journald because it lets me isolate logs for a particular unit without grepping and accidentally including output from unrelated services. It's faster to find the data that I need between time ranges rather than manually comparing time stamps. I can count on one finger the number of times the journal has been corrupted on the servers that I manage, and it was because of hardware failure.
- deleted 5y ago
  [deleted]
- mousepilot 5y ago
  I have this fantasy that all the pro systemd posts are really just bots run by leonard
  - fullstop 5y ago
    I, Leonard, do not know of what you speak. ;-)