Bug 851131 - systemd affects autofs reliability
systemd affects autofs reliability
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 843116
  Show dependency treegraph
 
Reported: 2012-08-23 06:13 EDT by Michal Hlavinka
Modified: 2013-01-08 03:30 EST (History)
13 users (show)

See Also:
Fixed In Version: systemd-44-23.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:43:09 EDT
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)

  None (edit)
Description Michal Hlavinka 2012-08-23 06:13:36 EDT
Description of problem:
Dovecot does not work, if users have autofs mounted home directories, because autofs does not seem to work reliably. Dovecot reported following error:

Error: chdir(/home/auto/afsuser) failed: Too many levels of symbolic links

Then I tried simple test:
================================
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <syslog.h>

int main(int argc, char **argv)
{
  char buf[200];
  int r = chdir("/home/nas/afsuser"), en=errno;
  snprintf(buf, 200, "Return code is: %d, errno=%d : %m\n", r, errno);
  syslog(LOG_ERR,buf);
  fprintf(stderr,buf);
  return r ? en : 0;
}
================================

added it to dovecot.service:
ExecStartPre=/opt/chdircheck

and added autoreboot.service
================================
[Unit]
Description=auto reboot
After=local-fs.target network.target
After=autofs.service
After=dovecot.service
After=chdircheck.service

[Service]
Type=oneshot
ExecStart=/usr/bin/reboot

[Install]
WantedBy=multi-user.target
================================

I also added debug "-d -v" to OPTIONS in /etc/sysconfig/autofs

after tens of reboots I checked /var/log/messages and there were 50 log messages, all of them:
automount[542]: dev_ioctl_send_ready: token = 1
chdircheck: Return code is: -1, errno=40 : Too many levels of symbolic links
automount[542]: mounted /home/nas/afsuser

so it was not working, with very odd chdir error

I verified that automount is started before dovecot:
cat /var/log/boot.log:
         Starting Automounts filesystems on demand...
.........
[  OK  ] Started Automounts filesystems on demand.
         Starting Dovecot IMAP/POP3 email server...
[  OK  ] Started Dovecot IMAP/POP3 email server.


I tried if it's race condition, so I removed it from dovecot and added it to autofs.service:
ExecStartPost=/opt/chdircheck

but it was working fine:

chdircheck: Return code is: 0, errno=0 : Success

so there is no problem with when dovecot/autofs is started.

Another test, I put chdircheck in own service:
================================
[Unit]
Description=autofs chdir check
After=local-fs.target network.target
After=autofs.service

[Service]
Type=oneshot
ExecStart=/opt/chdircheck

[Install]
WantedBy=multi-user.target
================================

tens of reboots again... working all the time. So, what is the difference? Why it works in autofs.service and own service, but not in dovecot.service? There is extra settings in dovecot.service, so I put it in too:
NonBlocking=yes
PrivateTmp=true

and it stopped working. Seems these options have negative side-effect why chdir stops waiting for mount to complete.


Version-Release number of selected component (if applicable):
systemd-44-17.fc17.x86_64
kernel-3.5.2-1.fc17.x86_64
autofs-5.0.6-22.fc17.x86_64

How reproducible:
always

Steps to Reproduce:
1) add new user
mkdir /home/auto
adduser -d /home/auto/afsuser afsuser
passwd afsuser

2) make home automount
new /etc/auto.home with following line:
afsuser -fstype=ext3,loop,rw :/home/disk.img
added "/home/auto /etc/auto.home" to /etc/auto.master
chkconfig autofs on
dd if=/dev/zero of=/home/disk.img bs=1M count=100
mkfs.ext3 -F /home/disk.img
mount /home/disk.img /mnt -oloop
mv /home/auto/afsuser /mnt
umount /mnt

3) gcc -o /opt/chdircheck chdircheck.c
# the source code is above

4) create chdircheck.service
# service content is above

5) add 
NonBlocking=yes
PrivateTmp=true
to service file

6) reboot
7) check log
grep chdircheck /var/log/messages | tail -n 1
  
Actual results:
chdircheck: Return code is: -1, errno=40 : Too many levels of symbolic links

Expected results:
chdircheck: Return code is: 0, errno=0 : Success

Additional info:
Without
NonBlocking=yes
PrivateTmp=true
it works fine
Comment 1 Michal Hlavinka 2012-08-23 06:29:17 EDT
chdircheck.c:
>  int r = chdir("/home/nas/afsuser"), en=errno;
should be /home/auto/afsuser

I can see I made more of these mistakes in bug description, because I used /home/nas prefix originally and did not convert everything to /home/auto, when writing comments
Comment 3 Lennart Poettering 2012-09-11 23:07:28 EDT
This patch is in F18 already.
Comment 4 Fedora Update System 2012-09-20 15:54:35 EDT
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Comment 5 Fedora Update System 2012-09-22 02:35:48 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 6 Fedora Update System 2012-09-27 20:16:15 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 7 Fedora Update System 2012-10-01 16:08:04 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 8 David Strauss 2012-12-13 17:34:52 EST
This would be good to backport to the F17 package.
Comment 9 David Strauss 2012-12-13 17:56:46 EST
We added it into our own package:
https://github.com/pantheon-systems/systemd/commit/2b160655abb3f45328030f08178959e7c7a9571b

We skipped the patch to TODO and anything for the changelog, as this is for Pantheon's internal use. Still, you're welcome to re-appropriate the patch, which applies properly at the top of the F17 package's patch set.
Comment 10 Joe Miller 2012-12-17 14:42:04 EST
Would it be possible to get this backported to F17?
Comment 11 Michal Schmidt 2013-01-08 03:30:09 EST
For F17 the patch has been applied in systemd-44-23.fc17.

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