10 ms·

Indeed, and many of us who have spent extensive time writing data center automation prefer it to the way things used to be. * Config files and startup behavior

Indeed, and many of us who have spent extensive time writing data center automation prefer it to the way things used to be. * Config files and startup behavior are all in the same format; outputters for name daemons, cron jobs, networking, name resolution, NTP, coredumps, mountpoints, and more are all the same. Hand it a data structure with the proper keys and you know it's going to work. * cgroup and namespace configuration are much more fine grained, flexible, and straightforward than docker. Have a weird vendor service that you'd like to restrict or isolate? you can do that. * Process management is mostly a solved problem after years of being ignored by POSIX. * Accounting metrics on memory, tasks, and I/O is for all your services is there * Shipping to syslog is a breeze. Yeah, it's got a learning curve but it's objectively better than a bunch of random init scripts. Which you can still use.

everforward 3y ago
I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text. Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage. I know it can forward to syslog, but at that point I'd rather just have syslog. systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.
- nolist_policy 3y ago
  From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.
  - throw0101b 3y ago
    > No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). I do. I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention. (This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)
  - everforward 3y ago
    I would totally agree with this. I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald. From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.
- charcircuit 3y ago
  The logs are stored in a database. Having a database being purely clear text makes querying it slow.
  - Ckirby 3y ago
    this is nonsense you can process millions of lines of plaintext in a tenth of a second using awk
  - everforward 3y ago
    Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs. It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.
- throw0101b 3y ago
  > logging in binary was a mistake. They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it. > The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness. * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd https://www.linkedin.com/pulse/20140924071300-170035-why-you...
Spivak 3y ago
Adding some more: * You get real honest-to-god dependency solving, no more having to number scripts so they run in the right order or working with magic comments. * .targets are the correct abstraction over runlevels that do what people actually need them to do. * How journald manages disk finally fixes the stupidity of logrotate edgecases. * sysusers/tmpfiles is by far by far the best way to manage non-human users and application specific directories. * The entire system is programmable in real programming languages without having to shell out to system("systemctl start ..."). The whole thing is dbus-first and systemctl is just a client to it like any other. * You can make your own unit types with systemd-generators if the built-in ones aren't enough for you. * The system for overrides finally solves the package management bullshit where the init script and the package manager fight. * Built-in userspace oom killer. * Makes user sessions a real thing on Linux instead of an ad-hoc set of conventions. * sd-notify for service readyness checks is fantastic * Parameterized services!
Ckirby 3y ago
[flagged]

everforward 3y ago

I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text. Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage. I know it can forward to syslog, but at that point I'd rather just have syslog. systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.

nolist_policy 3y ago
From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.
- throw0101b 3y ago
  > No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). I do. I want my (e.g.) auth.log rotated regularly and kept forever. Many other things I only care about (say) 4-6 weeks of retention. (This is in addition to off-host log shipping, which of course journald doesn't do itself so I have to run rsyslog regardlesss.)
- everforward 3y ago
  I would totally agree with this. I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald. From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.
charcircuit 3y ago
The logs are stored in a database. Having a database being purely clear text makes querying it slow.
- Ckirby 3y ago
  this is nonsense you can process millions of lines of plaintext in a tenth of a second using awk
- everforward 3y ago
  Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs. It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.
throw0101b 3y ago
> logging in binary was a mistake. They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it. > The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/6922/focus=6950 http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness. * https://www.linkedin.com/pulse/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd https://www.linkedin.com/pulse/20140924071300-170035-why-you...

Spivak 3y ago

Adding some more: * You get real honest-to-god dependency solving, no more having to number scripts so they run in the right order or working with magic comments. * .targets are the correct abstraction over runlevels that do what people actually need them to do. * How journald manages disk finally fixes the stupidity of logrotate edgecases. * sysusers/tmpfiles is by far by far the best way to manage non-human users and application specific directories. * The entire system is programmable in real programming languages without having to shell out to system("systemctl start ..."). The whole thing is dbus-first and systemctl is just a client to it like any other. * You can make your own unit types with systemd-generators if the built-in ones aren't enough for you. * The system for overrides finally solves the package management bullshit where the init script and the package manager fight. * Built-in userspace oom killer. * Makes user sessions a real thing on Linux instead of an ad-hoc set of conventions. * sd-notify for service readyness checks is fantastic * Parameterized services!

Ckirby 3y ago

[flagged]