A timesyncd failure and systemd's lack of debugability • Hacker News Board

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

#101

Post by JdeBP » Thu, Aug 09, 2018, 1:01 PM UTC

lomnakkus wrote: post #58

erik_seaberg wrote: post #5

systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about speed than determinism on a laptop). But there's no reason to choose a uid and mkdir dynamically. You want these errors at install time, not at the box's next (probably unattended) restart.

Personally, I think even having to choose a UID at install time or dynamically is a pretty sad indictment of just how broken the user system on Linux (and pretty much every UNIX-like) is. It leads to a huge amount of incidental complexity where there's a much simpler way: User IDs should just be randomly chosen UUIDs -- either generated by upstreams or by the distros. Any metadata attached to the user UID could just…

One can, and many people have, over the years.

Some of the more interesting ideas that people have had, in my view, have been:

* ID systems that introduce hierarchies, allowing (say) a user to create multiple sub-users (one for running the WWW browser, one for running the office suite, one for running the chat program, ...);

* proper nonce ID creation with segregation guarantees (c.f. nonce SIDs in the Windows NT world); and

* IDs that are reference counted, accessible via descriptors, passable from process to process via descriptor-passing mechanisms, and explicitly supplied in system calls for opening/creating things.

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

#102

Post by JdeBP » Thu, Aug 09, 2018, 1:13 PM UTC

erik_seaberg wrote: post #5

systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about speed than determinism on a laptop). But there's no reason to choose a uid and mkdir dynamically. You want these errors at install time, not at the box's next (probably unattended) restart.

Actually, wanting this stuff not at install/configure time is one of the primary driving forces behind the mechanism. Lennart Poettering notes that it moves the relevant tasks out of package pre/post-install/deinstall scripts and into service startup and shutdown.

Ironically, the alternative approach here is more descriptive and less imperative package management.

Witness manifest files on the old BSD pkg system. Rather than every package maintainer writing an install/deinstall script to invoke the relevant account database tools, packages place a @newuser or @newgroup directive in the file and the packaging system handles creating and deleting the account at appropriate times.

* https://man.openbsd.org/pkg_create.1

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

#103

Post by throw2016 » Thu, Aug 09, 2018, 2:11 PM UTC

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…

This containerization and virtualization thing is repeated without evidence. There is nothing systemd specific to running containers. Containers and VMs work perfectly well on Alpine, Gentoo and any distribution.

Namespaces and cgroups are provided by the kernel. Any init system can use them. Cgroups are mounted at /sys/fs/cgroups and while there continues to be some friction on how these are mounted and used with systemd going its own way, other init systems like openrc manage them perfectly well.

The rest of it is standard networking, mounts and autostart services started by the container managers like LXC, Docker, libvirt for VMs and these can be done by any init system.

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

#104

Post by kps » Thu, Aug 09, 2018, 2:25 PM UTC

dantiberian wrote: post #88

gnud wrote: post #75

Earlier quoted context omitted.

You obviously didn't read the article before deciding this wasn't systemd's fault. The bug is the lack of any error handling in the DynamicUser feature of systemd. The original failure is not logged anywhere - and launching timesyncd just goes ahead even though the setup for it fails completely. Naturally timesyncd then fails to start. (Or perhaps the bug is the whole DynamicUser feature. From reading the bug report,…

The other part necessary to trigger the bug is that uid 0 is not root and is not able to read the user-only mounts. root would still be able to read the user-only FUSE mount.

User 0 is root, and it is not able to read everything on other machines — as has been the case for decades.

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

#105

Post by rkeene2 » Thu, Aug 09, 2018, 2:38 PM UTC

beagle3 wrote: post #81

I have switched between ntpd, openntpd, timesyncd and a couple of others I might have forgotten, and the only one that's worked reliably is ntpd, but I was trying to stay off it, because historically it had quite a few vulnerabilities. I manage hundred of stand-along edge devices, mostly hardened PCs who have to bear up to 50 deg celsius environment from time to time; I've observered 5-10 times that RTCs were wrong b…

You could always use htpd [0]. :-)

[0] http://rkeene.org/docs/oss/htp/htp.pdf

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

#106

Post by crististm » Thu, Aug 09, 2018, 2:56 PM UTC

bantunes wrote: post #86

crististm wrote: post #76

Earlier quoted context omitted.

Systemd is the light that people don't want to look at and embrace, heh? What I see is a an appalling amount of arrogance that comes with the "I'll solve all your current and future problems". Systemd actually doesn't and in fact can't do what it pretends. The evidence is in the never ending list of posts like these that pop up all the time. And the arrogance of pretending to be the top of the init.d hierarchy of ini…

> The evidence is in the never ending list of posts like these that pop up all the time. So posts hating on something are proof that something doesn't work? The open-source way used to be "come up with an alternative and win on merit". These days, since what systemd is trying to do is complex, it seems to be "complain about it online but keep using it" which leads to a super toxic user base, which might explain why b…

My understanding is that you are conveniently blind to several facts and this allows you to create a naive narative about what open source is supposed to be and what sustemd is leaving to the rest of us to do. Thus your downvotes.

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

#107

Post by ploxiln » Thu, Aug 09, 2018, 4:15 PM UTC

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?

"as much as possible" would be to put it in a virtual machine, or actually separate physical hardware, maybe in a multi-million-dollar bank vault to prevent physical tampering.

Then there's a reasonable amount of isolation, which would be to run it under its own user, which can only write to one or two directories, and can't read user directories or non-world-readable system config files. This is already common practice. (Creating this user at package install time, or in the initial base distro config, is completely sufficient. And simpler.)

"as much as possible" is really not worth it (and sucks resources away from implementing reasonable security practices elsewhere).

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

#108

Post by digi_owl » Thu, Aug 09, 2018, 5:15 PM UTC

steevdave wrote: post #56

newnewpdro wrote: post #28

TL;DR: systemd has bugs. Mountain out of a mole hill. Lack of debuggability? It's not like this is some threaded golang program you'll lose your mind attempting to make sense of in strace. systemd is a single-threaded C program, if you consider this as not debuggable it's your failing not systemd's. There are valid complaints to be made about systemd, but from what I've seen the crux of the problem is generally the h…

The lack of contributors has a lot to do with Lennart's (apologies if I misspelled his name) attitude early on in systemd's development. I have no idea if it has changed, as I gave up trying to get things fixed. The one issue I still have with systemd is the way it handles the kernel's command line. I work with Chromebooks a lot, using software that isn't ChromeOS. The cool thing is that they can use FIT images so yo…

Ah yes, debug parsing. Didn't that attract Torvalds' ire some time ago when it was found that it made systemd flood the kernels log buffer with "junk" data?

Then again the other guy in the systemd team, Sievers, have a long history of pissing the kernel people off with out of the blue unilateral decisions.

I just worry when their buddy GKH is given the reins of the kernel when Torvalds steps down...

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

#109

Post by TooBrokeToBeg » Thu, Aug 09, 2018, 5:24 PM UTC

jhasse wrote: post #51

hedora wrote: post #18

Earlier quoted context omitted.

It means that a configuration file on two similar machines could have radically different behaviors.

That's always the case due to different software versions.

This implies they can be different with the same versions.

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

#110

Post by digi_owl » Thu, Aug 09, 2018, 5:30 PM UTC

thwarted wrote: post #42

mikekchar wrote: post #40

Earlier quoted context omitted.

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…

Systemd solves real problems that have to do with virtualisation and/or containerisation. systemd predates the industry love affair with containerization and virtualization for workload management, although work on containerization within systemd may have helped increase awareness of containerization's value. I don't remember early reasons to use systemd mentioning either; the rationales trotted out in favor of syste…

Systemd as a project has developed a history of moving goalposts. Their initial talk was about boot speed by using dependency trees and parallel execution.

But when containerization caught the zeitgeist, they were quick to trot out nspawn as an alternative to, say, Docker (never mind that Docker and RH devs had a bit of a spat around the same time).

Since then they have been shifting the goalposts towards whole system management, perhaps best likened to Windows Active Directory, by adding more and more sub-systems that frankly has crap all to do with booting.

On top of all this it seems the people involved regularly end up pulling grsec style "fixing" of systems that work in real life but are "broken" according to some spec or other (sometimes ignoring decades of hard earned experience in the process, as was the case with their DNS reimplementation).