5 ms·

But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.

by lucian1900 12y ago

edwintorok 12y ago
Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
- pessimizer 12y ago
  >Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
  - felixgallo 12y ago
    Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
    - EmanueleAina 12y ago
      I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
- lucian1900 12y ago
  Structured data is very useful. Just because many unix folks have managed to extract some meaning out of random text for so long doesn't mean it's a good idea. This is the same thing I see about HTTP/2. It's good to finally remove a huge number of parsing errors and inefficiencies!
  - edwintorok 12y ago
    I'd be less opposed to journald if it used SQLite instead of its own format, but I still think that logs don't belong in a binary file by default: https://news.ycombinator.com/item?id=7210570 https://news.ycombinator.com/item?id=7210570
    - KayEss 12y ago
      The problem with sqlite for this is that as you write more and rows into a table then the writes get progressively slower -- it simply isn't able to do O(1) writes over a long period of time so you'd have to rotate the database files themselves. I've been solving this problem by writing a non-pretty printed JSON blob to one line in a log file. Structured, but still text and very easy to stream. I build a separate binary index that gives more efficient time based lookups, but it isn't needed to understand and process the log file.
      - edwintorok 12y ago
        Did you release your code that does that?
        KayEss 12y ago
        No. It's in a monitoring system we've been working on, but the principle is pretty simple. We may well end up open sourcing quite the rest of it sometime in the future -- a lot of the code already is.
    - EmanueleAina 12y ago
      People already complain about systemd dependencies, I'm sure pulling in SQLite would have generated more complaints than a quite simple custom binary format. :)
digi_owl 12y ago
And that's part of the problem. Some systemd parts makes sense for server, some make sense for desktop, but trying to select just those that fit scenario X is a pain in the behind.
- lucian1900 12y ago
  It's really good on a desktop as well, particularly for laptops. Services come and go based on what's plugged in, etc. systemd is the launchd for Linux I've been wanting for years.

But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.

edwintorok 12y ago

Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).

pessimizer 12y ago
>Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
- felixgallo 12y ago
  Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
  - EmanueleAina 12y ago
    I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
lucian1900 12y ago
Structured data is very useful. Just because many unix folks have managed to extract some meaning out of random text for so long doesn't mean it's a good idea. This is the same thing I see about HTTP/2. It's good to finally remove a huge number of parsing errors and inefficiencies!
- edwintorok 12y ago
  I'd be less opposed to journald if it used SQLite instead of its own format, but I still think that logs don't belong in a binary file by default: https://news.ycombinator.com/item?id=7210570 https://news.ycombinator.com/item?id=7210570
  - KayEss 12y ago
    The problem with sqlite for this is that as you write more and rows into a table then the writes get progressively slower -- it simply isn't able to do O(1) writes over a long period of time so you'd have to rotate the database files themselves. I've been solving this problem by writing a non-pretty printed JSON blob to one line in a log file. Structured, but still text and very easy to stream. I build a separate binary index that gives more efficient time based lookups, but it isn't needed to understand and process the log file.
    - edwintorok 12y ago
      Did you release your code that does that?
      - KayEss 12y ago
        No. It's in a monitoring system we've been working on, but the principle is pretty simple. We may well end up open sourcing quite the rest of it sometime in the future -- a lot of the code already is.
  - EmanueleAina 12y ago
    People already complain about systemd dependencies, I'm sure pulling in SQLite would have generated more complaints than a quite simple custom binary format. :)

digi_owl 12y ago

And that's part of the problem. Some systemd parts makes sense for server, some make sense for desktop, but trying to select just those that fit scenario X is a pain in the behind.

lucian1900 12y ago
It's really good on a desktop as well, particularly for laptops. Services come and go based on what's plugged in, etc. systemd is the launchd for Linux I've been wanting for years.