Bug 710663 - [PATCH] yum-cron gets disabled at reboot
Summary: [PATCH] yum-cron gets disabled at reboot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 3
Hardware: noarch
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-03 23:49 UTC by Richard Hitt
Modified: 2014-01-21 23:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-17 09:12:43 UTC
Type: ---


Attachments (Terms of Use)
Patch to fix package yum-cron (823 bytes, application/octet-stream)
2011-06-03 23:49 UTC, Richard Hitt
no flags Details

Description Richard Hitt 2011-06-03 23:49:01 UTC
Created attachment 502928 [details]
Patch to fix package yum-cron

Description of problem:
yum-cron gets disabled at reboot, because it depends on a tmpfs file's existence for its enablement state, viz., /var/lock/subsys/yum-cron

Version-Release number of selected component (if applicable):
yum-cron-3.2.29-6.fc15.noarch

How reproducible:
Always

Steps to Reproduce:
1.  yum install yum-cron
2.  chkconfig yum-cron on
3.  service yum-cron start
4.  service yum-cron status (and observe "... enabled")
5.  reboot
6.  service yum-cron status (and observe "... disabled")
  
Actual results:
See "observe" steps above

Expected results:
6.  service yum-cron status (and observe "... enabled")

Additional info:
In /etc/rc.d/init.d/yum-cron there's the line:
lockfile=/var/lock/subsys/yum-cron
which provides a file against which the script tests to determine whether
it's enabled or disbled.
In /etc/cron.daily/0yum.cron these statements test whether the file exists:
if [ ! -f /var/lock/subsys/yum-cron ]; then
  exit 0
fi

So obviously this is gonna fail, since in F15 /var/lock is a symlink to /run/lock and /run is a tmpfs, lost at reboot:
# mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755)

The fix is to change /etc/rc.d/init.d/yum-cron and /etc/cron.daily/-yum.cron to use /var/lib/yum-cron rather than /var/lock/subsys/yum-cron, because /var/lib/yum-cron will persist across a reboot.

See the attached patch.

Comment 1 Habig, Alec 2011-06-04 20:58:26 UTC
Will take a poke at it (don't have a F15 box up at this instant) - something's changed since the F-14 version.  In fact, a heck of a lot has changed, the "--changelog" for the rpm is entirely different than it used to be when I loked at that the other day.  Looks like the structure of the whole rpm changed out from under me here.

What is supposed to happen is that there is an "enabled" file in /var/run, which is created by the init script "starting" at reboot and removed during shutdown anyway (as runlevel 3 is entered and left), so it shouldn't matter if the filesystem is persistent or not.

The thing in /var/lock/subsys is not an "enable" flag file - it's an actual lockfile to prevent two instances of the job from trying to run at the same time.  In which case it's actually good that the filesystem clears on reboot, it should help to prevent stale lockfiles from piling up.

Comment 2 Richard Hitt 2011-06-04 21:41:27 UTC
Alec, you're right that lots has changed.  In particular, in F15 /var/run is wiped out across reboot.  In fact there is a new directory, /run, in F15 that was absent from F14, and it's mounted as a tmpfs filesystem (hence everything under /run is wiped out across reboot), and /var/run is a symlink to /run.

The file that yum-cron uses is /var/lock/subsys/yum-cron.  In F15, /var/lock is a symlink to /run/lock, and so it is wiped out at reboot.  After reboot, the file named /var/lock/subsys/yum-cron is *always* absent !!!

My fix changes the lockfile to be /var/lib/yum-cron; that works much better.

Here's some console output from the two Fedoras ---

From Fedora 14 ---
[rbh00@msi ~]$ cat /etc/fed*e
Fedora release 14 (Laughlin)
[rbh00@msi ~]$ ls -ld /run / /var /var/lock
ls: cannot access /run: No such file or directory
dr-xr-xr-x. 25 root root 4096 Jun  4 03:10 /
drwxr-xr-x. 23 root root 4096 Dec 18 14:49 /var
drwxr-xr-x.  8 root root 4096 Jun  4 04:22 /var/lock
[rbh00@msi ~]$ 

From Fedora 15 ---
[rbh00@F15F3b ~]$ cat /etc/fed*e
Fedora release 15 (Lovelock)
[rbh00@F15F3b ~]$ ls -ld /run / /var /var/lock
dr-xr-xr-x. 23 root root 4096 May 18 04:33 /
drwxr-xr-x. 28 root root 1060 Jun  4 14:18 /run
drwxr-xr-x. 19 root root 4096 May 25 03:09 /var
lrwxrwxrwx.  1 root root   11 May 20 08:01 /var/lock -> ../run/lock
[rbh00@F15F3b ~]$ mount | grep run
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755)
[rbh00@F15F3b ~]$ 

--- And yeah, it does look like yum-cron was merged into the yum package, by Seth Vidal at redhat ---
* Thu Jan 13 2011 Seth Vidal <skvidal at fedoraproject.org> - 3.2.29-1
- 3.2.29
- add yum-cron subpkg

And maybe it's he who should be fixing this bug, because imnsho he broke it.  He should have been aware of the change I described above.  On the other hand he probably had lots of work, I dunno.  Still, his name is on it so he should fix it, what do you think?  ... Then again, was that change for /run made later than Jan 13?  I've been following the systemd mailing list, and maybe it was.  ... Yes, I see that only around March was that change being discussed.  Email me if you are interested in more detail about this, or ask here.

The bottom line is, change to using /var/lib/yum-cron, in /etc/rc.d/init.d/yum-cron and in in /etc/cron.daily/0yum.cron, and it'll work.

Comment 3 Richard Hitt 2011-06-04 22:18:10 UTC
Alec, it turns out that yum-cron IS OKAY, it was MY ERROR, grrrrr, and daniel_hozac on #fedora-devel patiently explained it to me.  It is quite all right for the tempfile to be /var/lock/subsys/yum-cron.

Sorry I ever opened this bug.  Sigh.

Comment 4 Habig, Alec 2011-06-05 17:38:01 UTC
No problem!  But what was going on to confuse the issue?

Comment 5 Till Maas 2011-09-17 09:12:43 UTC
According to comment 3 this issue is resolved. Please re-open it in case this is not the case.


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