Bug 835848 - Services pcscd, dbus, avahi-daemon, rtkit-daemon and rpcbind still depending on var-run.mount
Services pcscd, dbus, avahi-daemon, rtkit-daemon and rpcbind still depending ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-27 05:49 EDT by Florian Ermisch
Modified: 2012-12-20 11:03 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 11:03:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for Fedora17 based on upstream fix (628 bytes, patch)
2012-08-10 19:52 EDT, Noam Meltzer
no flags Details | Diff

  None (edit)
Description Florian Ermisch 2012-06-27 05:49:53 EDT
Description of problem:
Service pcscd (and serveral others, see below) depend on 'var-run.mount' which doesn't exist on Fedora 17.

Version-Release number of selected component (if applicable):
Name        : systemd
Arch        : x86_64
Version     : 44
Release     : 14.fc17

dbus-1.4.10-4.fc17.x86_64
ConsoleKit-0.4.5-2.fc17.x86_64
avahi-0.6.31-3.fc17.x86_64
pcsc-lite-1.8.3-1.fc17.x86_64
rpcbind-0.2.0-16.fc17.x86_64
rtkit-0.10-2.fc17.x86_64

(from export LC_ALL=C; for SVC in $(sudo grep var-run.mount /var/log/messages | sed -e 's/.*\(\(systemd\|dbus\)\[[0-9]*\]:\)/\2[PID]:/' | sort -u | sed -e "s/.*for unit [']*\([a-z-]*.\(service\|socket\)\).*/\1/" -e "s/.* \([a-z-]*\.\(service\|socket\)\) failed to.*/\1/" | sort -u); do yum --noplugins whatprovides "*/$SVC" ; done | grep fc17 | sort -u)

How reproducible:
Run pcsc-lite on Fedora 16 and upgrade to Fedora 17.

Steps to Reproduce:
1. Install pcsc-lite on Fedora 16
2. Upgrade to Fedora 17
3. Try to start pcscd
  
Actual results:
Cannot use my smartcard because pcscd won't start (the other failed services don't affect me [yet]).

Expected results:
It should be possible to use a smartcard that worked on F16.

Additional info:
Fedora 16 installed on btrfs-root, upgraded to Fedora 17 via yum because PreUpgrade didn't work.

-bash-4.2$ sudo grep var-run.mount /var/log/messages | sed -e 's/.*\(\(systemd\|dbus\)\[[0-9]*\]:\)/\2[PID]:/' | sort -u
dbus[PID]: [system] Activation via systemd failed for unit 'console-kit-daemon.service': Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
dbus[PID]: [system] Activation via systemd failed for unit 'rtkit-daemon.service': Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
systemd[PID]: Cannot add dependency job for unit avahi-daemon.socket, ignoring: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
systemd[PID]: Cannot add dependency job for unit dbus.socket, ignoring: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
systemd[PID]: Cannot add dependency job for unit pcscd.socket, ignoring: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
systemd[PID]: Cannot add dependency job for unit rpcbind.socket, ignoring: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
systemd[PID]: pcscd.socket failed to queue socket startup job: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
Comment 1 Michal Schmidt 2012-06-27 05:58:41 EDT
Do you get these errors on every boot?
Comment 2 Florian Ermisch 2012-06-27 06:33:43 EDT
Just did a reboot. So far one error from console-kit-daemon.service:
-bash-4.2$ sudo tail /var/log/messages
Jun 27 12:15:56 fuji-cyber61 ntpd[1141]: Listening on routing socket on fd #22 for interface updates
Jun 27 12:15:56 fuji-cyber61 systemd[1]: Startup finished in 1s 320ms 340us (kernel) + 49s 597ms 33us (initrd) + 2min 38s 124ms 778us (userspace) = 3min 29s 42ms 151us.
Jun 27 12:15:56 fuji-cyber61 ntpd[1141]: 0.0.0.0 c016 06 restart
Jun 27 12:15:56 fuji-cyber61 ntpd[1141]: 0.0.0.0 c012 02 freq_set kernel 22.226 PPM
Jun 27 12:16:03 fuji-cyber61 ntpd[1141]: 0.0.0.0 c615 05 clock_sync
Jun 27 12:19:12 fuji-cyber61 systemd-logind[687]: New session 1 of user floh.
Jun 27 12:19:12 fuji-cyber61 dbus-daemon[752]: dbus[752]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
Jun 27 12:19:12 fuji-cyber61 dbus[752]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='console-kit-daemon.service'
Jun 27 12:19:12 fuji-cyber61 dbus-daemon[752]: dbus[752]: [system] Activation via systemd failed for unit 'console-kit-daemon.service': Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
Jun 27 12:19:12 fuji-cyber61 dbus[752]: [system] Activation via systemd failed for unit 'console-kit-daemon.service': Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.

pcscd is enabled but didn't cause an error at boot. I guess it wasn't started because of a missing dependancy:

-bash-4.2$ sudo systemctl is-enabled pcscd.service && echo $?
static
0
-bash-4.2$ sudo systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
          Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
          Active: inactive (dead)
          CGroup: name=systemd:/system/pcscd.service

-bash-4.2$ sudo systemctl restart pcscd.service
Failed to issue method call: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.

The system is up to date:
-bash-4.2$ env LC_ALL=C sudo yum update
Loaded plugins: security
No Packages marked for Update
Comment 3 Florian Ermisch 2012-06-27 06:36:10 EDT
(In reply to comment #2)
> Just did a reboot. So far one error from console-kit-daemon.service:
> [...]

What I meant: Yes, as far as I know on every boot.
Comment 4 Bill Nottingham 2012-06-27 10:13:11 EDT
Can you attach your fstab?
Comment 5 Florian Ermisch 2012-06-28 15:51:44 EDT
(In reply to comment #4)
> Can you attach your fstab?

-bash-4.2$ cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Mon Nov 21 21:18:25 2011
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=459a78cc-7ca1-4f90-baf4-c6a2723dc71b /                       btrfs   defaults        1 1
UUID=07f7e98c-1c4c-4a61-bf67-3f3b968a8b49 swap                    swap    defaults        0 0

##/dev/sda5     /mnt/freebsd    ufs     ro,noauto,ufstype=ufs2,comment=systemd.automount 0 0
# /dev/sda6: freebsd-swap
##/dev/sda7     /mnt/freebsd/var        ufs     ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0
# /dev/sda8: freebsd-tmp
##/dev/sda9     /mnt/freebsd/usr        ufs     ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0
##/dev/sda10    /mnt/freebsd/export     ufs     ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0

LABEL=PENDRIVE /media/pendrive vfat noauto,user,uid=floh 0 0
-bash-4.2$ 

Nothing interesting to see here I guess.
And for the systemd.automount lines I think I still owe you guys a bugreport...
Comment 6 Florian Ermisch 2012-06-28 16:05:53 EDT
Oh, I tried to find the file(s) where the dependency of this services on var-run.mount is specified but couldn't find one in /etc/systemd or /usr/lib/systemd.

This is the only file containing "var-run.mount"...:
-bash-4.2$ find /etc/systemd/ /usr/lib/systemd/ -type f -exec grep var-run.mount {} \; -ls 
Requires=var-run.mount nss-lookup.target network.target remote-fs.target time-sync.target
2098899    4 -rw-r--r--   1 root     root          542 Jun 17 20:03 /usr/lib/systemd/system/citadel.service

...and it comes from a third party repo:
-bash-4.2$ yum repolist citadel                                                                          
Geladene Plugins: security                                                                               
Repo-ID                               Repo-Name:                                                   Status
citadel                               Citadel packages for Fedora_17                               68    
repolist: 68
Comment 8 Noam Meltzer 2012-08-10 19:50:43 EDT
I have encountered a similar problem with systemd.
Trying to start lvm2-monitor.service and/or firewalld.service showed the same error message:

[root@noam-lt 17]# systemctl start lvm2-monitor.service
Failed to issue method call: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.

I have applied a patch based on Michal Schmidt upstream commit which at least for me works around the problem.
I will attach a suggested patch for Fedora17 systemd in a moment.
Comment 9 Noam Meltzer 2012-08-10 19:52:08 EDT
Created attachment 603648 [details]
Patch for Fedora17 based on upstream fix
Comment 10 Michal Schmidt 2012-08-13 04:30:03 EDT
Noam,
I shall have a new systemd update for F17 ready this week. A patch for this bug will be included, though it will not be the same as your patch. Thanks anyway.
Comment 11 Florian Ermisch 2012-09-10 10:48:28 EDT
(In reply to comment #10)
> Noam,
> I shall have a new systemd update for F17 ready this week. A patch for this
> bug will be included, though it will not be the same as your patch. Thanks
> anyway.

In which version of th systemd-pkg will this one be?
wpa_supplicant won't start either and it get's kinda annoying to manually run wpa_supplicant and dhclient on every boot now that I have to use wireless ^^"

anything I could do to accelerate the process?
Comment 12 Bill Nottingham 2012-09-10 13:39:43 EDT
On every boot? There's nothing preventing you from enabling the services yourself locally (and wpa_supplicant has never been enabled by default other than when started as a NM dependency, as I recall.)
Comment 13 Florian Ermisch 2012-09-11 13:32:06 EDT
(In reply to comment #12)
> On every boot? There's nothing preventing you from enabling the services
> yourself locally (and wpa_supplicant has never been enabled by default other
> than when started as a NM dependency, as I recall.)

I'm not talking about starting the /service/ wpa_supplicant manually, because it fails just like pcscd:

fc61f16:~$ sudo service wpa_supplicant start
[sudo] password for floh: 
Redirecting to /bin/systemctl start  wpa_supplicant.service
Failed to issue method call: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
fc61f16:~$ sudo service pcscd start
Redirecting to /bin/systemctl start  pcscd.service
Failed to issue method call: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.

Why should I enable a service I _know_ isn't starting because of some out-dated dependency information?

He, and if I would be using NM it probably won't start because it depends on wpa_supplicant or at least won't be able to do anything with the wireless unless I start wpa_supplicant by hand (sudo /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i wlan1 -B)...
Comment 14 Bill Nottingham 2012-09-12 15:01:57 EDT
I think the var-run.mount error is an entirely different generic bug.
Comment 15 Florian Ermisch 2012-09-14 08:01:35 EDT
(In reply to comment #14)
> I think the var-run.mount error is an entirely different generic bug.

Well, but it's the bug I tried to report and get fixed... :(
Comment 18 Fedora Update System 2012-09-20 15:55:50 EDT
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Comment 19 Fedora Update System 2012-09-22 02:37:05 EDT
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2012-09-27 20:17:29 EDT
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 21 Fedora Update System 2012-10-01 16:09:52 EDT
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 22 Thorsten Vaupel 2012-10-04 07:45:30 EDT
(In reply to comment #14)
> I think the var-run.mount error is an entirely different generic bug.

I agree with you. It seems to me this is a problem of unexpected unit creation and dependency processing in systemd.

Precondition: you need a var-run.mount unit file.

[root@vm3 ~]# systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
          Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
          Active: inactive (dead)
          CGroup: name=systemd:/system/pcscd.service

[root@vm3 ~]# systemctl --type=mount --all list-units
UNIT                          LOAD   ACTIVE   SUB     JOB DESCRIPTION
-.mount                       loaded active   mounted     /
boot.mount                    loaded active   mounted     /boot
dev-hugepages.mount           loaded active   mounted     Huge Pages File System
dev-mqueue.mount              loaded active   mounted     POSIX Message Queue File System
media.mount                   loaded active   mounted     Media Directory
proc-sys-fs-binfmt_misc.mount loaded inactive dead        Arbitrary Executable File Formats File System
sys-fs-fuse-connections.mount loaded inactive dead        FUSE Control File System
sys-kernel-config.mount       loaded active   mounted     Configuration File System
sys-kernel-debug.mount        loaded active   mounted     Debug File System

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

9 units listed.

I wonder about the result of the next command!!!

[root@vm3 ~]# systemctl --property=Where show var-run.mount
Where=/var/run
[root@vm3 ~]# systemctl --type=mount --all list-units
UNIT                          LOAD   ACTIVE   SUB     JOB DESCRIPTION
-.mount                       loaded active   mounted     /
boot.mount                    loaded active   mounted     /boot
dev-hugepages.mount           loaded active   mounted     Huge Pages File System
dev-mqueue.mount              loaded active   mounted     POSIX Message Queue File System
media.mount                   loaded active   mounted     Media Directory
proc-sys-fs-binfmt_misc.mount loaded inactive dead        Arbitrary Executable File Formats File System
sys-fs-fuse-connections.mount loaded inactive dead        FUSE Control File System
sys-kernel-config.mount       loaded active   mounted     Configuration File System
sys-kernel-debug.mount        loaded active   mounted     Debug File System
var-run.mount                 error  inactive dead        /var/run

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

10 units listed.
[root@vm3 ~]# systemctl --property=Requires show pcscd.socket
Requires=sysinit.target -.mount var-run.mount
[root@vm3 ~]# systemctl start pcscd.service
Failed to issue method call: Unit var-run.mount failed to load: No such file or directory. See system logs and 'systemctl status var-run.mount' for details.
[root@vm3 ~]# sed -i -e 's/\/var\/run/\/run/' /usr/lib/systemd/system/pcscd.socket 
[root@vm3 ~]# systemctl daemon-reload
[root@vm3 ~]# systemctl --type=mount --all list-units
UNIT                          LOAD   ACTIVE   SUB     JOB DESCRIPTION
-.mount                       loaded active   mounted     /
boot.mount                    loaded active   mounted     /boot
dev-hugepages.mount           loaded active   mounted     Huge Pages File System
dev-mqueue.mount              loaded active   mounted     POSIX Message Queue File System
media.mount                   loaded active   mounted     Media Directory
proc-sys-fs-binfmt_misc.mount loaded inactive dead        Arbitrary Executable File Formats File System
sys-fs-fuse-connections.mount loaded inactive dead        FUSE Control File System
sys-kernel-config.mount       loaded active   mounted     Configuration File System
sys-kernel-debug.mount        loaded active   mounted     Debug File System
var-run.mount                 error  inactive dead        /var/run

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

10 units listed.
[root@vm3 ~]# systemctl start pcscd.service
[root@vm3 ~]# systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
          Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
          Active: active (running) since Thu, 04 Oct 2012 13:27:09 +0200; 24s ago
        Main PID: 927 (pcscd)
          CGroup: name=systemd:/system/pcscd.service
                  └ 927 /usr/sbin/pcscd --foreground --auto-exit

Oct 04 13:27:09 vm3 pcscd[927]: 00000000 utils.c:53:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory
Comment 23 Florian Ermisch 2012-10-07 13:17:54 EDT
OK, I guess I got what's the problem here (that systemd decided those services need var-run.mount even if it's not explicitly stated in the unit definitions) but none of the packages mentioned above became available for me (which does make sense because I'm still on Fedora 17...).
Comment 24 Thorsten Vaupel 2012-10-10 11:00:14 EDT
I would like to drill a bit deeper. At the moment /var/run is a symlink to /run. This has changed two times in recent history (see http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html for details). Made your system this transition? Also interesting is the status of var-run.mount.
Comment 25 Florian Ermisch 2012-10-10 14:59:43 EDT
(In reply to comment #24)
> ... Made your system this transition? Also interesting is the status
> of var-run.mount.

As far as I remember I kinda had to make this transition by hand because what the Fedora wiki told me about upgrading from F16 to F17 didn't work.

fc61f16:~$ mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
fc61f16:~$ ls -dl /var/run/
drwxr-xr-x. 26 root root 920 10. Okt 19:38 /var/run/
fc61f16:~$ ls -l /var/run
lrwxrwxrwx. 1 root root 6 21. Nov 2011  /var/run -> ../run

The status of var-run.mount is:

fc61f16:~$ systemctl status var-run.mount
var-run.mount - /var/run
          Loaded: error (Reason: No such file or directory)
          Active: inactive (dead)
           Where: /var/run
          CGroup: name=systemd:/system/var-run.mount
Comment 26 Thorsten Vaupel 2012-10-11 15:49:45 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Can you attach your fstab?
> 
> -bash-4.2$ cat /etc/fstab 
> 
> #
> # /etc/fstab
> # Created by anaconda on Mon Nov 21 21:18:25 2011
> #
> # Accessible filesystems, by reference, are maintained under '/dev/disk'
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
> #
> UUID=459a78cc-7ca1-4f90-baf4-c6a2723dc71b /                       btrfs  
> defaults        1 1
> UUID=07f7e98c-1c4c-4a61-bf67-3f3b968a8b49 swap                    swap   
> defaults        0 0
> 
> ##/dev/sda5     /mnt/freebsd    ufs    
> ro,noauto,ufstype=ufs2,comment=systemd.automount 0 0
> # /dev/sda6: freebsd-swap
> ##/dev/sda7     /mnt/freebsd/var        ufs    
> ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0
> # /dev/sda8: freebsd-tmp
> ##/dev/sda9     /mnt/freebsd/usr        ufs    
> ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0
> ##/dev/sda10    /mnt/freebsd/export     ufs    
> ro,noauto,ufstype=ufs2,comment=systemd.automount  0 0
> 
> LABEL=PENDRIVE /media/pendrive vfat noauto,user,uid=floh 0 0
> -bash-4.2$ 
> 
> Nothing interesting to see here I guess.
> And for the systemd.automount lines I think I still owe you guys a
> bugreport...

All requested information is already provided.
Comment 27 Thorsten Vaupel 2012-10-12 05:26:31 EDT
Summary:

1. There is no mount point /var/run. Instead /var/run is a symlink to /run.
2. Systemd still deploys the mount unit var-run.mount but the mandatory
   property "What" is unset, so it is inactive (dead).
3. A dependency on var-run.mount is appended to pcscd.socket. This is caused by
   the assignment of ListenStream=/var/run/pcscd/pcscd.comm in the
   socket unit file /usr/lib/systemd/system/pcscd.socket.
4. pcscd.service depends on pcscd.socket.
5. Final result: pcscd.service cannot start.

You can intercept at point 3 (see comment #22). Please prove the workaround I've suggested.
Comment 28 Fedora Update System 2012-10-12 12:46:36 EDT
systemd-44-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-20.fc17
Comment 29 Florian Ermisch 2012-10-12 14:30:25 EDT
(In reply to comment #27)
> ...
> 3. A dependency on var-run.mount is appended to pcscd.socket. This is caused
> by
>    the assignment of ListenStream=/var/run/pcscd/pcscd.comm in the
>    socket unit file /usr/lib/systemd/system/pcscd.socket.
> ...
> You can intercept at point 3 (see comment #22). Please prove the workaround
> I've suggested.

Consider your workaround for pcscd.service proven:

fc61f16:~$ systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/pcscd.service

fc61f16:~$ sudo systemctl start pcscd.service
[sudo] password for floh: 
fc61f16:~$ systemctl status pcscd.service
pcscd.service - PC/SC Smart Card Daemon
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
	  Active: active (running) since Fri, 12 Oct 2012 20:16:34 +0200; 20s ago
	Main PID: 2582 (pcscd)
	  CGroup: name=systemd:/system/pcscd.service
		  └ 2582 /usr/sbin/pcscd --foreground --auto-exit

Oct 12 20:16:34 fc61f16 pcscd[2582]: 00000000 utils.c:53:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory
fc61f16:~$


Should I install systemd-44-20.fc17 from updates-testing or does someone need me to keep the current state to test other workarounds?
Comment 30 Fedora Update System 2012-10-12 20:21:07 EDT
Package systemd-44-20.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-44-20.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16035/systemd-44-20.fc17
then log in and leave karma (feedback).
Comment 31 Thorsten Vaupel 2012-10-13 06:01:23 EDT
Please remember to undo the workaround first. I'm almost confident that this package will solve your problem finally.
Comment 32 Florian Ermisch 2012-10-14 09:33:37 EDT
(In reply to comment #31)
> Please remember to undo the workaround first. I'm almost confident that this
> package will solve your problem finally.

Undone workaround and upgraded to systemd-44-20.fc17. 
I can start pcscd.service manually but it won't start at boot although it's enables via 'sudo chkconfig pcscd enable'... Gotta take a look at the logs, but not right now.
Comment 33 Michal Schmidt 2012-10-16 03:34:54 EDT
pcscd.service does not install itself into any targets. It relies fully on socket activation via pcscd.socket. Therefore not seeing the service as active after boot is alright. It just means that no client tried to talk to it yet, or that the daemon exited itself after some idle time.

Check
systemctl status pcscd.{socket,service}
Comment 34 Florian Ermisch 2012-10-16 13:11:57 EDT
(In reply to comment #33)
> pcscd.service does not install itself into any targets. It relies fully on
> socket activation via pcscd.socket. Therefore not seeing the service as
> active after boot is alright. It just means that no client tried to talk to
> it yet, or that the daemon exited itself after some idle time.
> 
> Check
> systemctl status pcscd.{socket,service}

My fault, I totally forgot about this systemd feature ^^"

After boot:
fc61f16:~$ systemctl status pcscd.{socket,service}
pcscd.socket - PC/SC Smart Card Daemon Activation Socket
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled)
	  Active: active (listening) since Tue, 16 Oct 2012 18:49:51 +0200; 5min ago
	  CGroup: name=systemd:/system/pcscd.socket


pcscd.service - PC/SC Smart Card Daemon
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/pcscd.service


This changes as soon as I start an application trying to access the smartcard (which works again):

fc61f16:~$ systemctl status pcscd.{socket,service}
pcscd.socket - PC/SC Smart Card Daemon Activation Socket
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.socket; enabled)
	  Active: active (running) since Tue, 16 Oct 2012 18:49:51 +0200; 9min ago
	  CGroup: name=systemd:/system/pcscd.socket


pcscd.service - PC/SC Smart Card Daemon
	  Loaded: loaded (/usr/lib/systemd/system/pcscd.service; static)
	  Active: active (running) since Tue, 16 Oct 2012 18:58:43 +0200; 14s ago
	Main PID: 2662 (pcscd)
	  CGroup: name=systemd:/system/pcscd.service
		  └ 2662 /usr/sbin/pcscd --foreground --auto-exit

Oct 16 18:58:43 fc61f16 pcscd[2662]: 00000000 utils.c:53:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory
Oct 16 18:58:43 fc61f16 pcscd[2662]: 00108862 commands.c:870:CmdEscape error on byte 10


Looks like there's some /var/run stuff left somewhere but the service works again and systemd knows it PID:

fc61f16:~$ ps -o pid,user,args -p 2662
  PID USER     COMMAND
 2662 root     /usr/sbin/pcscd --foreground --auto-exit

(The same as in the output above.)


Thanks everyone!
Comment 35 Fedora Update System 2012-12-20 11:03:04 EST
systemd-44-20.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.