cron @reboot rules fail for users wuth autofs homes, due to missing upstart dependancy

Bug #696098 reported by Mike Simons
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cron (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Binary package hint: cron

If a user has a @reboot cron entry like:
===
@reboot date >> date.log
===

And their home directory is mounted by autofs into /home

then, the job will fail during a machine reboot because the
cron service starts before autofs service.

I think this is a missing dependency between in the cron upstart
configuration, to fix this I think that cron should be started after
autofs (only when autofs is enabled).

ProblemType: Bug
Architecture: amd64
Date: Fri Dec 31 12:32:49 2010
Dependencies:
 adduser 3.112ubuntu1
 base-files 5.0.0ubuntu23
 base-passwd 3.5.22
 coreutils 8.5-1ubuntu3
 debconf 1.5.32ubuntu3
 debconf-i18n 1.5.32ubuntu3
 debianutils 3.2.3
 dpkg 1.15.8.4ubuntu3
 findutils 4.4.2-1ubuntu1
 gcc-4.5-base 4.5.1-7ubuntu2
 libacl1 2.2.49-3
 libattr1 1:2.4.44-2
 libbz2-1.0 1.0.5-4ubuntu1
 libc-bin 2.12.1-0ubuntu10
 libc6 2.12.1-0ubuntu10
 libdb4.8 4.8.30-1
 libgcc1 1:4.5.1-7ubuntu2
 liblocale-gettext-perl 1.05-6
 liblzma2 4.999.9beta+20100527-1
 libncurses5 5.7+20100626-0ubuntu1
 libpam-modules 1.1.1-4ubuntu2
 libpam-runtime 1.1.1-4ubuntu2
 libpam0g 1.1.1-4ubuntu2
 libselinux1 2.0.94-1
 libtext-charwidth-perl 0.04-6
 libtext-iconv-perl 1.7-2
 libtext-wrapi18n-perl 0.06-7
 lsb-base 4.0-0ubuntu8
 ncurses-bin 5.7+20100626-0ubuntu1
 passwd 1:4.1.4.2-1ubuntu3
 perl-base 5.10.1-12ubuntu2
 sed 4.2.1-7
 sensible-utils 0.0.4ubuntu1
 tzdata 2010o-0ubuntu0.10.10
 xz-utils 4.999.9beta+20100527-1
 zlib1g 1:1.2.3.4.dfsg-3ubuntu1
DistroRelease: Ubuntu 10.10
NonfreeKernelModules: nvidia
Package: cron 3.0pl1-114ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
SourcePackage: cron
Tags: maverick
Uname: Linux 2.6.35-24-generic x86_64

/etc/init/cron.conf
===
# cron - regular background program processing daemon
#
# cron is a standard UNIX program that runs user-specified programs at
# periodic scheduled times

description "regular background program processing daemon"

start on runlevel [2345]
stop on runlevel [!2345]

expect fork
respawn

exec cron
===

ps aux | grep -E '(automount|cron)'
root 1542 0.0 0.0 21128 628 ? Ss Dec23 0:01 cron
root 1867 0.0 0.0 123208 1044 ? Ssl Dec23 0:02 /usr/sbin/automount

cron has a lower pid so it started first...

Tags: patch
Revision history for this message
Mike Simons (o-launchpad-simons-clan-com) wrote :

For an example of how automount of home is done:

Two parts, to get automount to manage directories in /home:

grep home /etc/auto.master
===
/home /etc/auto.home
===

To tell autofs what directories to attach to /home:

cat /etc/auto.home
===
* :/media/sdd1/home/& :/media/sdc1/home/& /some/other/place/&
===

Directories in those three source places will be mounted in /home automatically.

Since cron is running the @reboot rules for each user before the home
directory is mounted any cron job which relies on the home directory being
mounted will fail.

In the example the date.log should be written into the home directory,
in my real use cases I have daemon like scripts which are supposed to
be running all the time, live in my home directory and should get restarted
by cron after reboots.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Marking as Confirmed as there are at least 2 affected and other users have provided anecdotal evidence. It also makes sense due to cron's start on criteria.

Setting Importance to Medium as this only affects users who have autofs, and only those who are using the reboot functionality which is not the most common use case for cron.

Changed in cron (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Peter Benie (pjb1008) wrote :

I am using systemd rather than upstart, but the bug is the same: cron depends on remote-fs.target, autofs depends on remote-fs.target, so they start together. The result is that the job is run with the working directory set to /var/spool/cron.

What cron should be waiting for is home directories being available, but there doesn't seem to be a suitable systemd target for to achieve this.

The attached patch makes cron detect failure to chdir to the home directory; failure to chdir is treated as a critical error and the job is not started.

In addition, if some reboot jobs don't start due to the home directory not being available, this will try them for up to 5 times before giving up (about 5 minutes).

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "cron-reboot.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.