31–40 of 126 posts
Earlier quoted context omitted.
But you wrote: > I think "who is saying this, doing they have an underlying bias against this thing they are attacking"?
There is nothing wrong with examining the motive behind someone's argument. That's very different than an ad hominem attack.
Earlier quoted context omitted.
> I like systemd, it's a pity some vocal people aren't enthusiastic about it. To give some context as to why, for non-C++ developers systemd makes things very difficult to debug and understand in general. Moreover the biggest issue /I/ personally have is the fact it was essentially forced on me by the mainstream distro maintainers. When you discuss the merits and fallbacks of systemd it’s common for people to either…
Systemd is straight C, not C++.
The two wretched sisters.
Earlier quoted context omitted.
But you wrote: > I think "who is saying this, doing they have an underlying bias against this thing they are attacking"?
There is nothing wrong with examining the motive behind someone's argument. That's very different than an ad hominem attack.
Whenever I see a post that does nothing but dismiss an argument based on who made it, I do question the poster. There is a chance it is warranted, but in those cases evidence is at least presented. This post didn't even offer that.
> 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 sucks.
There's a rush to rewrite old software and to match some or most of that software's feature set, enough to get people to adopt it, but useful error messages and other diagnostics represent a lot of extra work and so nobody bothers.
Not enough programmers are spending time as systems administrators, trying to keep plates spinning, and so they aren't learning to appreciate the value of software that helps you troubleshoot it when something goes wrong. It's turning into the long-running conflict between mechanics and automotive engineers, where mechanics are tired of things like, "To replace [simple part that needs to be replaced every 5 years]: begin unbolting the entire front of the car. The front of the car uses 23 similar, but different, types of fasteners; keep track of them."
It needs to be a rule that if somebody's going to rewrite some software, they've got to match or improve the logging and error handling in it. Error handling needs to start getting the kind of attention and shaming for bad behavior that bottom-barrel security practices gets.
> this server drifted more than half a second out of synchronization before I found this issue entirely by coincidence Did `systemctl status` not report "degraded" for this failure? Maybe the problem is that there was no monitoring set up for failing services?
I'm pretty sure, by the way the OP described the problem that both the service state _and_ the product of the service are being monitored
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…
systemd arguments were just "boot faster" and "it's newer". Everyone knew it was going to be broken, buggy, lacking features. As those were never actual goals.
In fact, the goals had features never intended for init. So we could say they were rushing for feature anti-parity.
https://www.tecmint.com/systemd-replaces-init-in-linux/
see the table at the end. All the features systemd have show "no" for init. And "verbose debug", something you would consider very essential on a piece of software responsible for making your machine something broken and unusable, just show "no" for systemd, and nobody ever cared, because: boot faster (or so they say)
systemd is a mistake. But i guess now it is a permanent mistake.
Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…
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.
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.
But that's not all it does and the dependencies of systemd alongside making systemd a dependency, results in a very different observable reality.
The follow up article ( https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdDynami... ) explains the underlying problem. Basically, to get around root-only readable directories, a special mount namespace is created when Dynamic Users are used. That fails when there are mount points that systemd can't access, which was due to FUSE filesystems mounted inside owner-only home directories, combined with an NFS mount. Th…
That's what
After=nss-user-lookup.target
----
Edit: However, there is an interesting problem related to that: when you use socket activation for the user-providing daemon itself, you'll get a boot deadlock. For instance, one of the common LDAP solutions, nss-pam-ldapd, uses NSS and PAM modules that use a local socket to talk to a daemon (nslcd) that handles actually speaking LDAP. If you adjust that daemon & its service file to use socket activation (a trivial patch), the system will deadlock! Systemd will start the nslcd socket, but then when systemd starts dbus.service as a special hack it will then call dbus_init() to register itself on the bus. This will cause dbus-daemon to use the NSS module and hit the nslcd socket. Since this happens very early, systemd probably hasn't started nslcd itself yet. Because systemd is single threaded, and it's waiting on dbus-daemon to reply, it won't be able to handle the request to start nslcd, and the boot process deadlocks. Eventually, something will time out, and it will hobble along in to a half-working system. You can hack around this by manually ordering nslcd.service before dbus.service.
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…
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…
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 in order to fulfil contracts with paying customers). Red Hat contributes greatly to Gnome. I haven't checked, but I believe they are far and away the biggest contributor. They have financial reasons for doing so, but I don't really understand what they are.
The connection between Systemd and Gnome is real, but not quite what you think. Systemd does make some stuff in Gnome easier to do, but it isn't really necessary at all. Systemd was not developed for Gnome -- it was adopted by Gnome. It's a bit of a dog food problem. Most Gnome developers (i.e. Red Hat developers) have a vested interest in Systemd being successful. They want to make sure they are using it where they can. They saw no particular reason to make Gnome 3 compatible with any other init system because: 1. It would be more work and why should they pay for work that isn't in their interest 2. They want more people to adopt Systemd because that puts Red Hat in a good position to sell more contracts.
It's totally understandable and not really underhanded. I personally hate it with a passion, but things I hate are not always evil :-)