Hacker News Reader

Comment by KaiserPro | Hacker News Reader

Before systemd the error were shell errors.

before systemd the bundled logger wrote to a file, didn't direct people to journald, that lags like a champ when a log file is > 1 meg.

before systemd errors in config files were on specific lines

I don't have bias against systemd I have bias against it's flaws.

I like its config file. I hate it's documentation.

I like that it has a cron like feature, I hate that its pretty impossible to debug.

_whats my bias_? I have >>5k machines to look after, I don't want to think about systemd. (and no, not all of them drain into splunk. that costs money.)

Worst of all, I hate the attitude: every problem is a deep and personal critism.

it's not, in the same way that when a bug brings down your entire estate at 4am isn't a personal attack on me. It's just terribly annoying, and I want it fixed.

View on HN

I'll take the rare systemd bug over the buggy hell that most sysv init scripts were.

In fact, I run both distros with and without systemd and broken init scripts are a constant headache, while I've yet to encounter a single issue caused by systemd.

Your and zaarn's comments are the classic fallacious dichotomy between van Smoorenburg init+rc and systemd, called out by the Uselessd Guy years ago. One day, the world will have a systemd discussion without an instance of this fallacy cropping up.

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

sysvinit has it's warts too and it can get quite ugly.

For example, atm I need to have 3 services. Two of these services need to run at the same time, they can run separately but then they are not useful. The third services can only run with both services online and is first run 15 minutes after boot (not earlier!) and then every hour but the hourly run MUST NOT run before the first run of the boot (ie the very first run may happen 15 minutes after boot, even if the hourly run would have happened in that time, it cannot)

This is not trivially achievable with cron and classical init other than resorting to complicated shell scripts in both.

With SystemD I can cut down on the complexity by declaring this dependency in the service files and the timers in systemd are sufficiently configurable to achieve what I need.

Sure, systemd isn't flawless, but it's a mile better than the average init script I'd have to hack together otherwise. Journald isn't pretty either but with the right configuration you can cut down on the lag.

And before systemd problems like the above wouldn't have errors in specific lines either, some shell script would be subtly wrong and the entire charade would collapse in an instant.

You don't have to think about systemd at all. Ansible and other modern tooling can abstract managing the machines for you (atm I managing about 200 VMs in Ansible playbooks and it works great)

I probably would have resorted to another process manager if I were on sysvinit such as supervisord, god, monit etc to avoid making those scripts.

I used supervisord for anything complex, which is where I think systemd get's it's syntax from.

Anisble abstracts some stuff (ensure running, running as use, etc) but for more complex stuff (process type, dependency management etc) you're on your own shipping system files.

My main beef is actually three things:

1) crap error messages,

2) crap validataion

3) journalctl being a crap VIM wrapper.

of all of them, journalctl is the most obnoxious. Instead of deffering to the system viewer it enforces their crap viewer. It truncates by default, and without restarting the viewer, or forcing it through less. (Why didn't they use less by default? less code to maintain..)

Journalctl uses less as a pager by default, you can set the env variable SYSTEMD_PAGER to specifiy what pager to use (or just PAGER) and SYSTEMD_LESS to specify parameters to pass to less.

journalctl has no own pager implementation and if no pager is installed then none is used.

I give you validation and error messages, systemd is a bit sparse on that front. Would be easier if there was a way for programs and services to signal back error messages to report.

edit:

You can actually enforce non-wrapping by setting SYSTEMD_LESS to FRXMK (the S option that is otherwise included causes truncating, if omitted you get wrapping)

This can all be configured in /etc/profile, .bashrc and friends

Reply on news.ycombinator.com