Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A timesyncd failure and systemd's lack of debugability

utcc.utoronto.ca

Post reply on HN
Print view View original

91–100 of 126 posts

Re: A timesyncd failure and systemd's lack of debugability

#91

Post by alxlaz »

hvidgaard wrote: post #73
thaumaturgy wrote: post #34

Let's carefully step around the whole distraction that is systemd. Instead: > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. This see…

> > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. > This seems to be really common practice in modern software development, and it s…

> It is impossible to give meaningful error messages for all errors.

This problem was, however, largely non-existent back when most of the init code was shell code. It was easy to trace, easy to debug.

(Edit: obviously, "easy" if you know sh and the idioms. They are, nonetheless, far easier than stracing stuff)

It certainly had a lot of other problems (hence systemd's popularity) but debugging was definitely not one of them.

Re: A timesyncd failure and systemd's lack of debugability

#92

Post by HeadsUpHigh »

mikekchar wrote: post #40
gcb0 wrote: post #36

Earlier quoted context omitted.

That's not quite right in this case. Systemd and gnome3 were cases where the new 'version' did not need full feature parity. Both those projects were written on leisure time, with no pressure for deadline or feature. and still adopted from top down. i guess some projects forget the benevolent part of benevolent dictator for life. systemd arguments were just "boot faster" and "it's newer". Everyone knew it was going t…

You're getting down voted mainly because you are wrong. I'm actually not well versed in this, so hopefully somebody will correct my wrong version -- but at least I think it will steer you in the right direction ;-) Systemd solves real problems that have to do with virtualisation and/or containerisation. Red Hat is the company that wrote Systemd and they did it for commercial reasons (i.e. they needed these facilities…

Gnome 3 has a hard dependency at this point on logind. There are patches produced to allow it to work with consolekit but they got denied. What I hate systemd for is the fact that Redhat is making it a dependency on more and more of their projects. So much for making small tools that do one job.

Re: A timesyncd failure and systemd's lack of debugability

#93

Post by AnIdiotOnTheNet »

hvidgaard wrote: post #73
thaumaturgy wrote: post #34

Let's carefully step around the whole distraction that is systemd. Instead: > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. This see…

> > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. > This seems to be really common practice in modern software development, and it s…

If you structure your software simply and make it easy to reason about what is going on, then any half decent error message should give enough information to at least start down the right path.

But we don't get that in modern software. We get "Something went wrong :(".

Re: A timesyncd failure and systemd's lack of debugability

#94

Post by rleigh »

otabdeveloper2 wrote: post #52

Come on, it's not like shell scripts are debugable.

Err, they are very easy to debug. You can have them print out every line as they execute and follow along what was done. Prior to systemd, if there was ever anything critically broken, I could step through the entire startup from the initramfs and bring up the system line-by-line or script by script as I needed, and see exactly what was at fault.

With a script-based startup, the entire system was understandable by anyone with some rudimentary knowledge. It wasn't complicated, and it worked well. It did have its shortcomings, but the accessibility to modification and the ability to effectively debug were not amongst them. In comparison, systemd's behaviour is a black box with the unit files as input. The actual internal state is opaque, and it's inaccessible even to experts.

Re: A timesyncd failure and systemd's lack of debugability

#95

Post by dsr_ »

nickez wrote: post #70
ploxiln wrote: post #43

Earlier quoted context omitted.

With systemd, any really tricky low-level bug is systemd's fault, because systemd tries to do everything, in the most "advanced" way. And due gnome3 dependencies it's been adopted by all major distros. Before systemd, a difficult bug was not always the fault of one newfangled opinionated and unavoidable package. I read the first blog post about systemd when it was written, and thought it was really interesting. Then…

timesyncd is a network connected daemon. Why would you not isolate it as much as possible?

The job of synchronizing the system clock is not a job that belongs to the init system. It is a job that belongs to people who can write and debug the very complex cases of NTP.

The init system simply has to fire it up, take it down, and report on whether it's still running. Any further elaborations are features of the init system.

All the problems mentioned here were failures of the init system in doing things that the init system should be doing, but were hard to diagnose because this particular init system does not and never has put "easy to debug" as a high priority item.

Re: A timesyncd failure and systemd's lack of debugability

#96

Post by JdeBP »

tomjakubowski wrote: post #9
insaneirish wrote: post #2

Given things like this: "The default configuration is defined during compilation" [1] and the fact that you'd think 'timedatectl status' would tell you the NTP server you're supposedly trying to sync to (spoiler alert: it doesn't), I'm unsurprised of any further atrocities committed by systemd. [1]: https://www.freedesktop.org/software/systemd/man/timesyncd.c...

> Given things like this: "The default configuration is defined during compilation [so a configuration file is only needed when it is necessary to deviate from those defaults....]" I don't get it. What's so bad about that?

You might want to cast your mind back to https://news.ycombinator.com/item?id=9809427 .

Re: A timesyncd failure and systemd's lack of debugability

#98

Post by JdeBP »

thaumaturgy wrote: post #34

Let's carefully step around the whole distraction that is systemd. Instead: > The real problem here is that it is impossible to diagnose or debug this situation. Simply to get this far I had to read the systemd source code (to find the code in timesyncd that printed this specific error message) and then search through 25,000 lines of strace output. And I still don't know what the problem is or how to fix it. This see…

I disagree that nobody bothers. I've seen people bother about this.

Re: A timesyncd failure and systemd's lack of debugability

#99

Post by JdeBP »

lima wrote: post #44
KaiserPro wrote: post #37

Earlier quoted context omitted.

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…

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/

Re: A timesyncd failure and systemd's lack of debugability

#100

Post by insaneirish »

tomjakubowski wrote: post #9
insaneirish wrote: post #2

Given things like this: "The default configuration is defined during compilation" [1] and the fact that you'd think 'timedatectl status' would tell you the NTP server you're supposedly trying to sync to (spoiler alert: it doesn't), I'm unsurprised of any further atrocities committed by systemd. [1]: https://www.freedesktop.org/software/systemd/man/timesyncd.c...

> Given things like this: "The default configuration is defined during compilation [so a configuration file is only needed when it is necessary to deviate from those defaults....]" I don't get it. What's so bad about that?

The practical result is that on a machine without a configuration file, you can’t determine what NTP server it’s trying to use without having access to the source code (or some compile time include) or doing some other trickery.

That is a ludicrous design decision and is indicative of the developers having zero empathy towards their users.

Post reply on HN