Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1511255 - cronie @reboot does not work: should run after ypbind, after autofs
Summary: cronie @reboot does not work: should run after ypbind, after autofs
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cronie
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marcel Plch
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 01:04 UTC by Konstantin Olchanski
Modified: 2019-03-14 14:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-14 14:07:49 UTC


Attachments (Terms of Use)

Description Konstantin Olchanski 2017-11-09 01:04:08 UTC
User @reboot crontab entries do not work because cronie runs them before ypbind and autofs have been started, the autofs-mounted /home/$USER does not exist yet.

At https://github.com/cronie-crond/cronie/blob/master/contrib/cronie.systemd they have added ypbind/service, but maybe autofs.service also should be added.

$ rpm -q cronie
cronie-1.4.11-17.el7.x86_64

K.O.

Comment 2 Konstantin Olchanski 2017-11-09 01:16:16 UTC
Confirmed. After adding ypbind.service and autofs.service, @reboot seems to work correctly. K.O.

# more /usr/lib/systemd/system/crond.service
[Unit]
Description=Command Scheduler
After=auditd.service systemd-user-sessions.service time-sync.target ypbind.service autofs.service

[Service]
EnvironmentFile=/etc/sysconfig/crond
ExecStart=/usr/sbin/crond -n $CRONDARGS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process

[Install]
WantedBy=multi-user.target

# 

K.O.

Comment 3 Marcel Plch 2019-01-22 14:49:22 UTC
I have failed to reproduce this bug. Steps taken in attempt to reproduce this:

1) remove /home from /etc/fstab
2) add "/- /etc/auto.test" to /etc/auto.master
3) add "/home -fstype=auto :/dev/sda3" to /etc/auto.test
4) $ crontab -e
@reboot echo "hello" >> /home/${USER}/hello
5) $ reboot
6) $ cat hello
hello

I have tried multiple reboots in case it was a race condition, but it seems to work all the time.

Comment 4 Marcel Plch 2019-03-04 15:07:06 UTC
Please, provide more data on this bug, otherwise it will be closed WONTFIX in 2 weeks.

Comment 5 Konstantin Olchanski 2019-03-06 18:27:11 UTC
Hi, you tested the wrong bug. The problem I see is caused by wrong starting order between nis, autofs and cron (should start in this order).

In you test, it does not look like you examined the order that these programs started and
you did not confirm that this order is enforced by systemd unit file settings (in el7, it is NOT, I confirm this).

Regardless, you can now close this bug. I have developed by own solution which does not require any
changes to the official packages:

ENABLE CRONTAB @REBOOT FOR MIDAS (CENTOS7)
el7 has a bug - cron @reboot entries for normal users before autofs is ready, so if the home directory is on autofs/NFS, it is usually cannot be accessed yet and the cron job fails. If MIDAS is started by user cron @reboot, it will not be started (there *will* be an error message in /var/log/cron).

mkdir /etc/systemd/system/crond.service.d
echo -e "[Unit]\nAfter=ypbind.service autofs.service\n" > /etc/systemd/system/crond.service.d/local.conf
systemctl daemon-reload
systemctl cat crond.service

See
http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_crontab_.40reboot_for_MIDAS_.28CentOS7.29

K.O.

Comment 6 Marcel Plch 2019-03-14 14:07:49 UTC
Given that another solution not requiring changes has been found, I am closing this as resolved upstream.


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