Re: [systemd-devel] service runs - but it's not really there
On 29/01/2021 13:02, Reindl Harald wrote: Am 29.01.21 um 13:55 schrieb lejeczek: ● user@0.service - User Manager for UID 0 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled) Active: active (running) since Thu 2021-01-28 17:13:01 GMT; 2h 34min ago Main PID: 854314 (systemd) Status: "Startup finished in 44ms." Tasks: 35 Memory: 69.3M CGroup: /user.slice/user-0.slice/user@0.service ├─init.scope │ ├─854314 /usr/lib/systemd/systemd --user │ └─854319 (sd-pam) └─syncthing.service exists and gets auto started by "systemd" without any asking really. This is really very bad, no? What am I missing here? systemd at the very least will spawn your per-user dbus daemon, which is needs to be available for many programs to function. Even others require systemd themselves. Lennart -- Lennart Poettering, Berlin I think I found it, in my opinion a very cheeky bastard - syncthing - who does this: [Install] WantedBy=default.target which results in: -> $ llr /etc/systemd/user/default.target.wants/ total 0 lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> /usr/lib/systemd/user/syncthing.service So those of you on RHEL and derivatives (I assume that same rpm goes to all those) - suffices to install "syncthing" an you have your "roor" does as above and if you are not aware then the "root" does that with you not even knowing. As a matter of sharing opinions - is that a good & healthy practice to make & distribute packages like that? what is your problem? it's an ordinary user session and not some mystery of "root does as above" RTFM https://www.freedesktop.org/software/systemd/man/u...@.service.html instead talking about "very cheeky bastard - syncthin" I doubt I can explain or express it any better, If you do not get it it's fine. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service runs - but it's not really there
On 28/01/2021 21:32, Lennart Poettering wrote: On Do, 28.01.21 20:06, lejeczek (pelj...@yahoo.co.uk) wrote: Hi guys This absolutely boggled my mind, my brain exploded, but go easy on me as I ain't an expert. I have, meaning the "root" but other users too, _NO_ "~/.config/systemd" - thus, how I understand it, no service definitions which are user-made, yet this.. ● user@0.service - User Manager for UID 0 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled) Active: active (running) since Thu 2021-01-28 17:13:01 GMT; 2h 34min ago Main PID: 854314 (systemd) Status: "Startup finished in 44ms." Tasks: 35 Memory: 69.3M CGroup: /user.slice/user-0.slice/user@0.service ├─init.scope │ ├─854314 /usr/lib/systemd/systemd --user │ └─854319 (sd-pam) └─syncthing.service exists and gets auto started by "systemd" without any asking really. This is really very bad, no? What am I missing here? systemd at the very least will spawn your per-user dbus daemon, which is needs to be available for many programs to function. Even others require systemd themselves. Lennart -- Lennart Poettering, Berlin I think I found it, in my opinion a very cheeky bastard - syncthing - who does this: [Install] WantedBy=default.target which results in: -> $ llr /etc/systemd/user/default.target.wants/ total 0 lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> /usr/lib/systemd/user/syncthing.service So those of you on RHEL and derivatives (I assume that same rpm goes to all those) - suffices to install "syncthing" an you have your "roor" does as above and if you are not aware then the "root" does that with you not even knowing. As a matter of sharing opinions - is that a good & healthy practice to make & distribute packages like that? many thanks, L. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service runs - but it's not really there
Am 29.01.21 um 16:27 schrieb lejeczek: I think I found it, in my opinion a very cheeky bastard - syncthing - who does this: [Install] WantedBy=default.target which results in: -> $ llr /etc/systemd/user/default.target.wants/ total 0 lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> /usr/lib/systemd/user/syncthing.service So those of you on RHEL and derivatives (I assume that same rpm goes to all those) - suffices to install "syncthing" an you have your "roor" does as above and if you are not aware then the "root" does that with you not even knowing. As a matter of sharing opinions - is that a good & healthy practice to make & distribute packages like that? what is your problem? it's an ordinary user session and not some mystery of "root does as above" RTFM https://www.freedesktop.org/software/systemd/man/u...@.service.html instead talking about "very cheeky bastard - syncthin" I doubt I can explain or express it any better, If you do not get it it's fine there is nothing to explain - you found something you don't understand and see a not existing issue either read manuals or ignore it - but move on ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a socket unit that finds an active service fails
On Fr, 29.01.21 12:30, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I wonder whether this is a bug: > When starting a socket unit that finds ist service active already, I get an > error > systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already > active, refusing. > systemd[1]: Failed to listen on Libvirt TLS IP socket. > > When using systemd units in a pacemaker cluster this is fatal: > pacemaker-controld[7467]: notice: Transition 316 action 81 > (prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error' > > Maybe the special problem is that two socket units (libvirtd-ro.socket, > libvirtd-tls.socket) exist to start the same service (libvirtd.service). > > I'm clueless how to handle that. Ideas? The socket activation logic works so that the activation sockets are passed to the service being activated during execve(). Thus, if a service is already running we can't pass in more sockets: you have to restart the service so that there's another execve() we can pass the newly started sockets over. My guess is that your service — if it finds that it didn't get a socket passed in that it needs — just creates the socket itself as a fallback... It's generally a good idea for services to have Requires= + After= on the sockets that actviate it, to make sure that the sockets are always started before the service itself, and the situation you are seeing cannot happen. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl reading incorrect file
On Fr, 29.01.21 11:34, John Lane (syst...@jelmail.com) wrote: > > > > Is it possible you are playing some weird games with your machine ID > > or boot ID? > > > > Maybe. Yes. I have a oneshot service that writes /etc/machine-id using > constant hardware-based info. But I've been using that for over two > years without any issues. Ahum. That's not supported, unless you do it before you transition to the host. The machine ID must stay constant while the host system is up and running. It's cached everywhere, including in PID 1 and journald, and if you write it at some arbitrary spot this will break all over the place. Maybe you were lucky so far, but the file should not be changed at arbitrary times. > The reason for settting machine id to a predictable value is because of > a need to refer to it in scripts etc meant it needed to be known > up-front, before the first install, but be somehow tied to the machine's > hardware. So that's what we did. Write it from the initrd. You can also set it via a kernel command line option. There was also the idea of initializing it from an env var passed to PID 1. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a socket unit that finds an active service fails
For me it is pretty logical, as in: the service started in relation to socket unit gets the respective socket. If service is already started there is no way to pass additional socket to it without restarting it. It may even listen exactly on the socket specified, just creating it on it's own. W dniu 29.01.2021 o 12:30, Ulrich Windl pisze: > Hi! > > I wonder whether this is a bug: > When starting a socket unit that finds ist service active already, I get an > error > systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already > active, refusing. > systemd[1]: Failed to listen on Libvirt TLS IP socket. > > When using systemd units in a pacemaker cluster this is fatal: > pacemaker-controld[7467]: notice: Transition 316 action 81 > (prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error' > > Maybe the special problem is that two socket units (libvirtd-ro.socket, > libvirtd-tls.socket) exist to start the same service (libvirtd.service). > > I'm clueless how to handle that. Ideas? > > Regards, > Ulrich > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service runs - but it's not really there
Am 29.01.21 um 13:55 schrieb lejeczek: ● user@0.service - User Manager for UID 0 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled) Active: active (running) since Thu 2021-01-28 17:13:01 GMT; 2h 34min ago Main PID: 854314 (systemd) Status: "Startup finished in 44ms." Tasks: 35 Memory: 69.3M CGroup: /user.slice/user-0.slice/user@0.service ├─init.scope │ ├─854314 /usr/lib/systemd/systemd --user │ └─854319 (sd-pam) └─syncthing.service exists and gets auto started by "systemd" without any asking really. This is really very bad, no? What am I missing here? systemd at the very least will spawn your per-user dbus daemon, which is needs to be available for many programs to function. Even others require systemd themselves. Lennart -- Lennart Poettering, Berlin I think I found it, in my opinion a very cheeky bastard - syncthing - who does this: [Install] WantedBy=default.target which results in: -> $ llr /etc/systemd/user/default.target.wants/ total 0 lrwxrwxrwx. 1 root root 39 Jan 26 10:39 syncthing.service -> /usr/lib/systemd/user/syncthing.service So those of you on RHEL and derivatives (I assume that same rpm goes to all those) - suffices to install "syncthing" an you have your "roor" does as above and if you are not aware then the "root" does that with you not even knowing. As a matter of sharing opinions - is that a good & healthy practice to make & distribute packages like that? what is your problem? it's an ordinary user session and not some mystery of "root does as above" RTFM https://www.freedesktop.org/software/systemd/man/u...@.service.html instead talking about "very cheeky bastard - syncthin" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl reading incorrect file
> > Is it possible you are playing some weird games with your machine ID > or boot ID? > Maybe. Yes. I have a oneshot service that writes /etc/machine-id using constant hardware-based info. But I've been using that for over two years without any issues. I did notice this when trying to investigate machine and boot ids: $ # systemd-id128 machine-id Failed to get machine-ID: Invalid argument whereas on my other machines this returns the expected value. So I looked at the source for systemd-id128, eventually in ./libsystemd/sd-id128/id128-util.c I discovered that the machine id value is parsed and must contain enough digits for a uuid with/without the hyphens. I know... as `man machine-id` says ;) My oneshot service uses enough of /sys/devices/virtual/dmi/id/board_serial to set a 32-character hexadecimal lowercase machine id. On my other machines this returned enough data to form a 32-character id but it didn't on the new one, so the machine id had insufficient characters in it. I modified that service to ensure the machine id has the required number of characters. Problem solved! Thanks for the pointer which helped me locate and resolve my issue. The reason for settting machine id to a predictable value is because of a need to refer to it in scripts etc meant it needed to be known up-front, before the first install, but be somehow tied to the machine's hardware. So that's what we did. As an aside... Changing the machine id after the machine has booted, like my oneshot service does, doesn't affect the current journal. Either a restart of the journal or a reboot is required. This isn't a massive problem as, after that first boot, the machine id is already in /etc/machine-id and doesn't actually change. But I'd like to do it properly so it works on the first boot also... is there a pointer to the correct way to use a script to set the machine id during boot? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Starting a socket unit that finds an active service fails
Hi! I wonder whether this is a bug: When starting a socket unit that finds ist service active already, I get an error systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already active, refusing. systemd[1]: Failed to listen on Libvirt TLS IP socket. When using systemd units in a pacemaker cluster this is fatal: pacemaker-controld[7467]: notice: Transition 316 action 81 (prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error' Maybe the special problem is that two socket units (libvirtd-ro.socket, libvirtd-tls.socket) exist to start the same service (libvirtd.service). I'm clueless how to handle that. Ideas? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
