I can see many packages on rawhide which still use /var/run (which is a symbolic link to /run)

sh$ grep -RniI "/var/run/" /usr/lib/systemd/system
/usr/lib/systemd/system/sysinit.target.wants/plymouth-start.service:10:ExecStart=/usr/sbin/plymouthd --mode=boot --pid-file=/var/run/plymouth/pid --attach-to-session
/usr/lib/systemd/system/initrd-switch-root.target.wants/plymouth-start.service:10:ExecStart=/usr/sbin/plymouthd --mode=boot --pid-file=/var/run/plymouth/pid --attach-to-session
/usr/lib/systemd/system/oddjobd.service:7:PIDFile=/var/run/oddjobd.pid
/usr/lib/systemd/system/oddjobd.service:8:ExecStart=/usr/sbin/oddjobd -n -p /var/run/oddjobd.pid -t 300
/usr/lib/systemd/system/mdmonitor.service:7:PIDFile=/var/run/mdadm/mdadm.pid
/usr/lib/systemd/system/mdmonitor.service:9:ExecStart=/sbin/mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
/usr/lib/systemd/system/chronyd.service:10:PIDFile=/var/run/chronyd.pid
/usr/lib/systemd/system/plymouth-start.service:10:ExecStart=/usr/sbin/plymouthd --mode=boot --pid-file=/var/run/plymouth/pid --attach-to-session
/usr/lib/systemd/system/iscsiuio.service:13:PIDFile=/var/run/iscsiuio.pid
/usr/lib/systemd/system/iscsid.service:11:PIDFile=/var/run/iscsid.pid
/usr/lib/systemd/system/irda.service:7:PIDFile=/var/run/irattach.pid
/usr/lib/systemd/system/radvd.service:9:PIDFile=/var/run/radvd/radvd.pid
/usr/lib/systemd/system/spice-vdagentd.service:11:ExecStartPre=/bin/rm -f /var/run/spice-vdagentd/spice-vdagent-sock
/usr/lib/systemd/system/spice-vdagentd.service:13:PIDFile=/var/run/spice-vdagentd/spice-vdagentd.pid
/usr/lib/systemd/system/tog-pegasus.service:9:PIDFile=/var/run/tog-pegasus/cimserver.pid
/usr/lib/systemd/system/pcscd.socket:5:ListenStream=/var/run/pcscd/pcscd.comm
/usr/lib/systemd/system/virtlockd-admin.socket:6:ListenStream=/var/run/libvirt/virtlockd-admin-sock
/usr/lib/systemd/system/virtlockd.socket:6:ListenStream=/var/run/libvirt/virtlockd-sock
/usr/lib/systemd/system/virtlogd-admin.socket:6:ListenStream=/var/run/libvirt/virtlogd-admin-sock
/usr/lib/systemd/system/virtlogd.socket:6:ListenStream=/var/run/libvirt/virtlogd-sock
/usr/lib/systemd/system/openhpid.service:7:PIDFile=/var/run/openhpid.pid
/usr/lib/systemd/system/sssd-secrets.socket:6:ListenStream=/var/run/secrets.socket
/usr/lib/systemd/system/sssd.service:13:PIDFile=/var/run/sssd.pid
/usr/lib/systemd/system/sssd-kcm.socket:7:ListenStream=/var/run/.heim_org.h5l.kcm-socket
/usr/lib/systemd/system/cups.socket:6:ListenStream=/var/run/cups/cups.sock
/usr/lib/systemd/system/certmonger.service:7:PIDFile=/var/run/certmonger.pid
/usr/lib/systemd/system/certmonger.service:9:ExecStart=/usr/sbin/certmonger -S -p /var/run/certmonger.pid -n $OPTS
/usr/lib/systemd/system/auditd.service:16:PIDFile=/var/run/auditd.pid
/usr/lib/systemd/system/gssproxy.service:13:PIDFile=/var/run/gssproxy.pid
/usr/lib/systemd/system/nfs-blkmap.service:12:PIDFile=/var/run/blkmapd.pid
/usr/lib/systemd/system/nfs-lock.service:18:PIDFile=/var/run/rpc.statd.pid
/usr/lib/systemd/system/rpc-statd.service:18:PIDFile=/var/run/rpc.statd.pid
/usr/lib/systemd/system/fancontrol.service:8:PIDFile=/var/run/fancontrol.pid
/usr/lib/systemd/system/kadmin.service:9:PIDFile=/var/run/kadmind.pid
/usr/lib/systemd/system/kadmin.service:11:ExecStart=/usr/sbin/kadmind -P /var/run/kadmind.pid $KADMIND_ARGS
/usr/lib/systemd/system/krb5kdc.service:8:PIDFile=/var/run/krb5kdc.pid
/usr/lib/systemd/system/krb5kdc.service:10:ExecStart=/usr/sbin/krb5kdc -P /var/run/krb5kdc.pid $KRB5KDC_ARGS

I tried to find something in fedora packaging guidelines for systemd[1].
But I cannot see any explicit note about /run/ vs /var/run.

Zbigniew,
could you provide your opinion from systemd POV?


[1] https://fedoraproject.org/wiki/Packaging:Systemd?rd=Packaging:Guidelines:Systemd

I know (believe me). I am addressing these issues on a case-by-case basis.

The entries with PIDFile arent important (but one should use /run there aswell while one is at it) since systemd only reads and deletes pidfiles.

The named-socket entries with "ListenStream" are important because systemd creates these on behalf of the service. THe way systemd does this *can* cause issues in some scenario's

If you want to here the long explanation:

Were trying to migrate away from /var/run to /run (since about half a decade). However some components force us to keep a /var/run symlink for compatibility (API breakage). However eventually the idea is to get rid of /var/run

If everyone just keeps using /var/run out of habit, then that does not help.

The real issue is this:

Some components are SELinux aware (example: systemd, systemd-tmpfiles, rpm)
These components sometimes interpret configuration (units, tmpfiles config, rpm specs) and process these configs accordingly.

A tmpfs file system is mounted on /run, an extended attribute file system is mounted on /, /var, /var/run

Take for example the sssd-secrets.socket unit:

You tell systemd to create /var/run/sssd-secrets.socket
systemd calls selinux and asks selinux: "hey i am about to create this socket, what context should i associate with that socket?"
If the selinux policy does not know about /var/run then SELinux will tell systemd to use a label for /var since /var/run is just a link file on /var.
This label might then not be allowed to associate with the underlying filesystem (tmpfs) mounted on /run. Because it does not make sense for "var" contexts to associate with tmpfs file systems.

So systemd will not be allowed to create the socket with the wrong context, and sssd does not start etc etc.

But really, all this aside. Just use /run and forget about /var/run unless you are forced by API's to use /var/run. Then maybe one day we will be able to get rid of /var/run

What dac.override said.

Also, /run is mounted very early, but /var is sometimes mounted later. For a majority of services this doesn't matter, because they are started later, but going through /var adds an additional dependency.

tl;dr version is that most of the time they are equivalent, but in various corner cases they are not, so it's cleaner and better to use /run.

Oh, and a Guidelines link:
https://fedoraproject.org/wiki/Packaging:Guidelines#.2Frun
> /var/run is a legacy symlink to /run

I'm coming here from a similar request for libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=1554079

Is the /run convention used by every systemd distro, presumably it's not just a fedora thing?

(In reply to Cole Robinson from comment #7)
> I'm coming here from a similar request for libvirt:
> https://bugzilla.redhat.com/show_bug.cgi?id=1554079
> 
> Is the /run convention used by every systemd distro, presumably it's not
> just a fedora thing?

I do not know but that can be easily solved at configure time with --runstatedir
which will be introduced in autoconf 2.70.

So my patch just allows to use change that to runstatedir instead of using
$(localstatedir)/run.
https://pagure.io/SSSD/sssd/pull-request/3689

And sssd would still use /var/run by default due to following fallback
https://pagure.io/SSSD/sssd/blob/master/f/src/conf_macros.m4#_884

And in case of somebody would like to test it then it can be changed at spec file
diff --git a/sssd.spec b/sssd.spec
index 25314596b..dfe31c7ff 100644
--- a/contrib/sssd.spec.in
+++ b/contrib/sssd.spec.in
@@ -743,6 +743,7 @@ autoreconf -ivf
     --enable-nsslibdir=/%{_lib} \
     --enable-pammoddir=/%{_lib}/security \
     --enable-nfsidmaplibdir=%{_libdir}/libnfsidmap \
+    --with-pid-path=/run \
     --disable-static \
     --disable-rpath \
 %if %{with sssd_user}
@@ -758,7 +759,8 @@ autoreconf -ivf
     %{?with_kcm_option} \
     %{?experimental}
 
-make %{?_smp_mflags} all
+make %{?_smp_mflags} all \
+     runstatedir=/run

 

But IMHO we should wait till autoconf 2.70 and have runstatedir configured in
rpm macro "%configure"

(In reply to Lukas Slebodnik from comment #8)
> (In reply to Cole Robinson from comment #7)
> > I'm coming here from a similar request for libvirt:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1554079
> > 
> > Is the /run convention used by every systemd distro, presumably it's not
> > just a fedora thing?
> 
> I do not know but that can be easily solved at configure time with
> --runstatedir
> which will be introduced in autoconf 2.70.
> 
> So my patch just allows to use change that to runstatedir instead of using
> $(localstatedir)/run.
> https://pagure.io/SSSD/sssd/pull-request/3689
> 
Fixing link to PR https://pagure.io/SSSD/sssd/pull-request/3691

> And sssd would still use /var/run by default due to following fallback
> https://pagure.io/SSSD/sssd/blob/master/f/src/conf_macros.m4#_884
> 
> And in case of somebody would like to test it then it can be changed at spec
> file
> diff --git a/sssd.spec b/sssd.spec
> index 25314596b..dfe31c7ff 100644
> --- a/contrib/sssd.spec.in
> +++ b/contrib/sssd.spec.in
> @@ -743,6 +743,7 @@ autoreconf -ivf
>      --enable-nsslibdir=/%{_lib} \
>      --enable-pammoddir=/%{_lib}/security \
>      --enable-nfsidmaplibdir=%{_libdir}/libnfsidmap \
> +    --with-pid-path=/run \
>      --disable-static \
>      --disable-rpath \
>  %if %{with sssd_user}
> @@ -758,7 +759,8 @@ autoreconf -ivf
>      %{?with_kcm_option} \
>      %{?experimental}
>  
> -make %{?_smp_mflags} all
> +make %{?_smp_mflags} all \
> +     runstatedir=/run
> 
>  
> 
> But IMHO we should wait till autoconf 2.70 and have runstatedir configured in
> rpm macro "%configure"

BTW previous "patch" for spec would work only until removing symlink /var/run because krb5 has hardcoded path to kCM socket /var/run/.heim_org.h5l.kcm-socket

And because /etc/krb5.conf.d/kcm_default_ccache is marked as %config(noreplace) we would need to either coordinate change together with krb5 or use another krb5 config file to use new path for kcm socket.

Anyway, I hope that removing symlink /var/run will be done in fedora as "System Wide Change". So far I cannot see it in f29 one. http://fedoraproject.org/wiki/Releases/29/ChangeSet

> Anyway, I hope that removing symlink /var/run will be done in fedora as "System Wide Change".

That's not going to happen, at least in the foreseeable future. Countless things would be broken.

That is also not what I am requesting this for (although I see how this is related). I just would like rpm specs, systemd socket units and tmpfiles snippets to reference /run instead of /var/run where possible. The symlink itself is not a big issue for me.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

*** Bug 1707862 has been marked as a duplicate of this bug. ***

This appears to have been fixed in b2e48deec7feaeca2824835caf38e1f26f146c50 at least in one of the services. Not sure if more work is needed..

I'm running version 30 and such warnings about PIDFile are numerous in the log.

Fedora 30; dmesg:
systemd[1]: /usr/lib/systemd/system/sssd.service:11: PIDFile= references path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly.

Confirming presence on Fedora 30

*** Bug 1722123 has been marked as a duplicate of this bug. ***

*** Bug 1729727 has been marked as a duplicate of this bug. ***

Comfirming presence on Fedora 31 (Rawhide)

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Could we change the version from 29 to 31 or 32?

Apr 15 23:09:25 localhost.localdomain systemd[1]: /usr/lib/systemd/system/sssd.service:13: PIDFile= references a path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly.
Apr 15 23:09:25 localhost.localdomain systemd[1]: /usr/lib/systemd/system/sssd-kcm.socket:7: ListenStream= references a path below legacy directory /var/run/, updating /var/run/.heim_org.h5l.kcm-socket → /run/.heim_org.h5l.kcm-socket; please update the unit file accordingly.

Debugging another sssd issue, I was reminded of how annoying it was that the journal has so may of these legacy /var/run warnings.
Is there any reason why this setting in the sssd service units cannot be changed? I see the point of the system wide change not happening yet, but converting one service at a time to get one step closer to using /run everywhere, and getting rid of needless warnings in the journal as well

Frankly, I have no idea. It's a five minute operation for the authors of a service (with most of the time
spent on writing the commit message). Having a bug like this open for 26+ months is beyond me.

Hmm, this has been actually fixed upstream for more then two years but apparently the previous maintainer forgot to patch spec file to include this change. I'm going to do new release soon so I will include it.

(In reply to Pavel Březina from comment #26)
> Hmm, this has been actually fixed upstream for more then two years but
> apparently the previous maintainer forgot to patch spec file to include this
> change. I'm going to do new release soon so I will include it.

Patch was pushed just to f32. But it is missing in rawhide and f31.
Rawhide is more critical.

FEDORA-2020-63a418c824 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-63a418c824

FEDORA-2020-63a418c824 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.