[oS-en] What means this error? (systemd)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Lately I'm seeing a lot of these: <3.6> 2023-03-01T22:56:13.184610+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:56:13.490948+01:00 Telcontar systemd 5495 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. <3.5> 2023-03-01T22:56:13.547410+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly. <3.6> 2023-03-01T22:57:03.897124+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:57:04.182654+01:00 Telcontar systemd 5579 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. <3.5> 2023-03-01T22:57:04.239124+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly. <3.6> 2023-03-01T22:57:44.853856+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:57:45.151554+01:00 Telcontar systemd 5626 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. <3.5> 2023-03-01T22:57:45.215647+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly. <3.6> 2023-03-01T22:58:29.288683+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:58:29.552762+01:00 Telcontar systemd 5682 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. <3.5> 2023-03-01T22:58:29.610571+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly. <3.6> 2023-03-01T22:58:35.053561+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:58:35.345362+01:00 Telcontar systemd 5712 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1. <3.5> 2023-03-01T22:58:35.407234+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly. That file is: [Unit] Description=NFS status monitor for NFSv2/3 locking. DefaultDependencies=no Conflicts=umount.target Requires=nss-lookup.target rpcbind.socket Wants=rpc-statd-notify.service After=network.target nss-lookup.target rpcbind.socket PartOf=nfs-utils.service [Service] Environment=RPC_STATD_NO_NOTIFY=1 Type=forking PIDFile=/var/run/rpc.statd.pid <========= ExecStart=/usr/sbin/rpc.statd What is wrong? Can I do something about it? - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY//Lwhwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVi0AAoIsCQX+pfmFaleXyh2zG CIS5vT/4AJ0R2pLEDnTo8TiS8eFQRPsStMshqQ== =Dug+ -----END PGP SIGNATURE-----
On 2023-03-01 16:03, Carlos E. R. wrote:
[Unit] Description=NFS status monitor for NFSv2/3 locking. DefaultDependencies=no Conflicts=umount.target Requires=nss-lookup.target rpcbind.socket Wants=rpc-statd-notify.service After=network.target nss-lookup.target rpcbind.socket
PartOf=nfs-utils.service
[Service] Environment=RPC_STATD_NO_NOTIFY=1 Type=forking PIDFile=/var/run/rpc.statd.pid <========= ExecStart=/usr/sbin/rpc.statd
What is wrong? Can I do something about it?
/var/run appears to be deprecated; at least in 15.4 it is just a link to /run and I suppose will disappear one of these days. Nothing is wrong, really. Whoever maintains that package simply needs to update the service file. Yes, you can do something about it: systemctl edit --full rpc-statd.service and make the following change: PIDFile=/var/run/rpc.statd.pid ===> PIDFile=/run/rpc.statd.pid There is no need to restart the service, as systemctl will execute an effective "daemon-reload" on exit. Do note that this cannot be used to edit units remotely.
Carlos E. R. wrote:
Lately I'm seeing a lot of these:
<3.6> 2023-03-01T22:56:13.184610+01:00 Telcontar systemd 1 - - Reloading. <3.3> 2023-03-01T22:56:13.490948+01:00 Telcontar systemd 5495 - - /usr/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.
This suggests there is something not quite right in your /etc/fstab ?
<3.5> 2023-03-01T22:56:13.547410+01:00 Telcontar systemd 1 - - /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly.
What is wrong?
The text is quite clear I think :-) PIDFile= references a path below legacy directory /var/run/, updating /var/run/rpc.statd.pid → /run/rpc.statd.pid; please update the unit file accordingly.
Can I do something about it?
Maybe start by working out why your systemd is being reloaded all the time. On my system, I also see some of those messages "PIDFile= references a ...", but syslog suppresses most of them. I can provoke a few with "systemctl cat rpc-statd". You could report it or you could just fix it locally with a drop-in override. -- Per Jessen, Zürich (3.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
You could report it or you could just fix it locally with a drop-in override.
Ah, interesting - it cannot be fixed with a drop-in. It is some sort of systemd 'lint' check, it only looks at the text config, not the end-result. Well, then you're left with editing the unit file directly (or report it and wait for an update). -- Per Jessen, Zürich (3.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-02 09:52, Per Jessen wrote:
Per Jessen wrote:
You could report it or you could just fix it locally with a drop-in override.
Ah, interesting - it cannot be fixed with a drop-in. It is some sort of systemd 'lint' check, it only looks at the text config, not the end-result.
Well, then you're left with editing the unit file directly (or report it and wait for an update).
I may try both -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-02 04:35, Carlos E. R. wrote:
On 2023-03-02 09:52, Per Jessen wrote:
Per Jessen wrote:
You could report it or you could just fix it locally with a drop-in override.
Ah, interesting - it cannot be fixed with a drop-in. It is some sort of systemd 'lint' check, it only looks at the text config, not the end-result.
Well, then you're left with editing the unit file directly (or report it and wait for an update).
I may try both
I already gave you the solution, Carlos -- hours ago. I have no idea if it is safe to edit the file directly, use systemctl edit -- that is what it is there for. Then I would suggest you start reading the man pages, especially systemd, systemctl and systemd.service.
On 2023-03-02 12:07, Darryl Gregorash wrote:
On 2023-03-02 04:35, Carlos E. R. wrote:
On 2023-03-02 09:52, Per Jessen wrote:
Per Jessen wrote:
You could report it or you could just fix it locally with a drop-in override.
Ah, interesting - it cannot be fixed with a drop-in. It is some sort of systemd 'lint' check, it only looks at the text config, not the end-result.
Well, then you're left with editing the unit file directly (or report it and wait for an update).
I may try both
I already gave you the solution, Carlos -- hours ago.
Yes, yes, thanks, I saw it. I was going to answer your post after trying it. Waiting for tea to make an effect on the fog ;-) I should have mentioned your post before.
I have no idea if it is safe to edit the file directly, use systemctl edit -- that is what it is there for.
Yes, of course.
Then I would suggest you start reading the man pages, especially systemd, systemctl and systemd.service.
Sure, I do, but that doesn't mean I understand it all. Systemd is too vast, there are many relationships. Man pages are usually a list of options to consult by somebody that already knows the relations, not an explanation on how things work and how to adapt or use. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-03-02 05:26, Carlos E. R. wrote:
On 2023-03-02 12:07, Darryl Gregorash wrote:
Then I would suggest you start reading the man pages, especially systemd, systemctl and systemd.service.
Sure, I do, but that doesn't mean I understand it all. Systemd is too vast, there are many relationships. Man pages are usually a list of options to consult by somebody that already knows the relations, not an explanation on how things work and how to adapt or use.
When I first started trying to figure out how systemd service files work, I found a rather decent reference that explained things a lot better than any of the man pages. Alas, I never bookmarked that reference, but I'm looking to see if I can find it again. Meanwhile, just google "systemd reference" or "systemd manual", because there are a few places where there is a bit of expansion on the meager details the man pages give. But the man pages are still better than nothing -- and when in a pinch, clearly you know how to submit an email to these mailing lists.... ;)
On Thu, 2 Mar 2023 06:18:46 -0600, Darryl Gregorash <raven@accesscomm.ca> wrote:
When I first started trying to figure out how systemd service files work, I found a rather decent reference that explained things a lot better than any of the man pages.
This is the one to read: Rethinking PID 1 https://0pointer.de/blog/projects/systemd.html -- Robert Webb
Carlos E. R. wrote:
Then I would suggest you start reading the man pages, especially systemd, systemctl and systemd.service.
Sure, I do, but that doesn't mean I understand it all. Systemd is too vast, there are many relationships.
Well, you just pick a place to start :-)
Man pages are usually a list of options to consult by somebody that already knows the relations, not an explanation on how things work and how to adapt or use.
systemd is probably one of the best documented softwares out there. man pages are manual pages, they are mostly for reference, when you can't remember that stupid incantation. Having said that, the systemd man pages are excellent too - systemd.service and systemd.unit, for instance. -- Per Jessen, Zürich (5.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-02 13:26, Per Jessen wrote:
Carlos E. R. wrote:
Then I would suggest you start reading the man pages, especially systemd, systemctl and systemd.service.
Sure, I do, but that doesn't mean I understand it all. Systemd is too vast, there are many relationships.
Well, you just pick a place to start :-)
Man pages are usually a list of options to consult by somebody that already knows the relations, not an explanation on how things work and how to adapt or use.
systemd is probably one of the best documented softwares out there.
man pages are manual pages, they are mostly for reference, when you can't remember that stupid incantation. Having said that, the systemd man pages are excellent too - systemd.service and systemd.unit, for instance.
I just googled "systemd for dummies", no hits. But: <https://www.linux-magazine.com/Issues/2017/200/Tutorials-Systemd> Tutorials – Systemd Article from Issue 200/2017 Author(s): Ben Everard <https://wiki.archlinux.org/title/systemd> systemd <https://everyday.codes/linux/services-in-systemd-in-depth-tutorial/> Services in Systemd: In-Depth Tutorial june 22, 2020 by michael krasnov | tags: devops, systemd No hit on the openSUSE wiki. If I insist (systemd howto at opensuse.org) then: <https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-systemd.html> 10 The systemd daemon <https://en.opensuse.org/openSUSE:Systemd_tips> openSUSE:Systemd tips -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
No hit on the openSUSE wiki.
I wouldn't have expected any, no. I'm surprised you managed to skip the main source: https://www.freedesktop.org/wiki/Software/systemd The wikipedia article is also very good: https://en.wikipedia.org/wiki/Systemd -- Per Jessen, Zürich (5.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-03-02 15:39, Per Jessen wrote:
Carlos E. R. wrote:
No hit on the openSUSE wiki.
I wouldn't have expected any, no.
I'm surprised you managed to skip the main source: https://www.freedesktop.org/wiki/Software/systemd
The wikipedia article is also very good: https://en.wikipedia.org/wiki/Systemd
Well, those I posted are the first few google hits. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (4)
-
Carlos E. R. -
Darryl Gregorash -
Per Jessen -
Robert Webb