4 ms·

Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. If it dynamically creates

Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. If it dynamically creates systemd units or sets their properties (systemd-homed, systemd-networkd, systemd-resolved) using the dbus endpoints, it's systemd-something. If it uses systemd libraries and lives in the systemd repo because it shares baseline docde, it's systemd-something. systemd is modular in the sense that those components are build-time flags. For homed, for example: https://github.com/systemd/systemd/blob/main/meson_options.txt#L125 https://github.com/systemd/systemd/blob/main/meson_options.t... Again, not confusing. Literally looking at the systemd repo for longer than 30 seconds would show you both why this it's considered modular, and why it's systemd-whatever Pulse doesn't.

ElectricalUnion 4y ago
> Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. It is because systemd confuses what should be split concepts into one big overarching thing. 'org.freedesktop.systemd1' (the actual systemd init D-Bus interface) somehow is still implied that it is vital to the entire systemd-something ecosystem while it's not really. A example being systemd-hostnamed and hostnamectl complaining that 'System has not been booted with systemd as init system (PID 1). Can't operate.' [1] while in fact they use 'org.freedesktop.hostname1.${something}' [2] and that is supposed to not be bolted with the entire rest of systemd besides using sd_bus. [1] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f8103c98dd0e79a24838e26/src/shared/bus-util.c#L293 https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81... [2] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f8103c98dd0e79a24838e26/src/hostname/hostnamed.c#L1342 https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81...
- Crysstalis 4y ago
  That looks like a bug, if you really have a need to do that you should report it.
- evol262 4y ago
  This looks like a good first contribution. hostnamectl DOES talk to sd_dbus, which DOES require systemd, which DOES require being PID1, and this message only pops up if you're in a container without the full subsystem running, access to the right cgroups, etc. The naming is simply part of how dbus structures things, not to say that it's not part of it. I'm sure that, in retrospect, they wish they would have used "org.systemd...", but hindsight is 20/20. If there's a scenario other than container without the right mounts/etc where this can come up, you should file a bug. If there isn't, you could see if you can submit a patch to improve the message. It's not an indication that systemd confuses concepts. Its can indication that a) dbus is kinda shit, and b) I doubt if the systemd mapped out hypothetical dbus names 5 years in the future.

ElectricalUnion 4y ago

> Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. It is because systemd confuses what should be split concepts into one big overarching thing. 'org.freedesktop.systemd1' (the actual systemd init D-Bus interface) somehow is still implied that it is vital to the entire systemd-something ecosystem while it's not really. A example being systemd-hostnamed and hostnamectl complaining that 'System has not been booted with systemd as init system (PID 1). Can't operate.' [1] while in fact they use 'org.freedesktop.hostname1.${something}' [2] and that is supposed to not be bolted with the entire rest of systemd besides using sd_bus. [1] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f8103c98dd0e79a24838e26/src/shared/bus-util.c#L293 https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81... [2] https://github.com/systemd/systemd/blob/93258c7d72fae23c9f8103c98dd0e79a24838e26/src/hostname/hostnamed.c#L1342 https://github.com/systemd/systemd/blob/93258c7d72fae23c9f81...

Crysstalis 4y ago
That looks like a bug, if you really have a need to do that you should report it.
evol262 4y ago
This looks like a good first contribution. hostnamectl DOES talk to sd_dbus, which DOES require systemd, which DOES require being PID1, and this message only pops up if you're in a container without the full subsystem running, access to the right cgroups, etc. The naming is simply part of how dbus structures things, not to say that it's not part of it. I'm sure that, in retrospect, they wish they would have used "org.systemd...", but hindsight is 20/20. If there's a scenario other than container without the right mounts/etc where this can come up, you should file a bug. If there isn't, you could see if you can submit a patch to improve the message. It's not an indication that systemd confuses concepts. Its can indication that a) dbus is kinda shit, and b) I doubt if the systemd mapped out hypothetical dbus names 5 years in the future.