12

On CentOS 5.8+ and Red Hat Enterprise 6+, when installing/updating packages, I notice a flag file /var/run/reboot-required is created when appropriate. On Ubuntu (and Debian too, I'm guessing), if package "update-notifier-common" is installed, a package postinst script triggers creation of this flag file. On RHEL/CentOS I can't figure out how this is happening.

For instance, on RHEL and CentOS I recently installed several updates and /var/run/reboot-required was created. One of them was an "openssl" package upgrade. I assume this was what created the flag file, since on Ubuntu it also works this way. However I looked at all "rpm -q --scripts" for each updated package, and didn't see anything that was likely to have created that flag file. Mostly I saw "postinstall program: /sbin/ldconfig".

So my questions are:

  • What creates this flag file on RHEL/CentOS?
  • Does it require a special package to be installed, analogous to the "update-notifier-common" package on Ubuntu?
4
  • I am now suspicious that it was something that I put in place in the past to detect updates that would require a reboot. I need to do some testing to know for sure. Is there a serverfault-approved way of marking this question as possibly "PEBKAC", pending further testing? I don't want to mislead people who end up here, looking for an answer. Jun 8 '12 at 22:29
  • Your comment is helpful enough. Do you need help for searching your lost trigger? If it is no cron-job it might be a rpm-trigger from a package that you built and installed yourselv.
    – Nils
    Jun 29 '12 at 20:38
  • I confirmed that is was definitely something I created on my own. I had a script that was tracking versions of packages (eg linux kernel), and when those changed it would create "/var/run/reboot-required". It was created as a chef recipe, so it's probably not relevant to others, nor easy to reproduce unless you are using chef. Jun 29 '12 at 21:44
  • Interesting enough that you got 11 upvotes and 3 favorites for your question... I vote to close that question. Perhaps you can answer it yourselv and accept your own answer to it. Can you put a link for that chef thingy in your aswer, too?
    – Nils
    Jun 30 '12 at 20:16
2

This file isn't referred to in any package script, nor any rpm macro (see /usr/lib/rpm/**/macros.*).

I suspect this came from a non-official package, based on a common practice in the Debian and Ubuntu communities.

There, it can be created by http://packages.debian.org/squeeze/update-notifier.

1
  • Ha; yes, that's where I got the idea from. But no there was no unofficial porting of a .deb. See my last comment on the main question. I'll also add my answer so I can accept it and close this question. Jul 3 '12 at 19:49
1

This was something I created on my own. I had a script that was tracking versions of packages (eg linux kernel), and when those changed it would create "/var/run/reboot-required". It was created as a chef recipe, so it's probably not relevant to others, nor easy to reproduce unless you are using chef.

0

For instance, on RHEL and CentOS I recently installed several updates and /var/run/reboot-required was created. One of them was an "openssl" package upgrade.

I've tried to update OpenSSL on CentOS 5.8 and 6.0, both doesn't creates that file. Anyone else get this?

What is its file type? Please show us the content?

If the "requires" really mean "requires", AFAIK, there is only kernel update that requires you reboot (if you want to boot into the new kernel, unless you use Ksplice). All the other updates (including: glibc, tzdata, SysVinit, ...), you "only" need to restart all the programs that uses it or depends on it.

3
  • I've since rebooted, so this is from memory only. It was a zero-size file, eg no contents. Jun 8 '12 at 12:02
  • Do you have any other server to test? Do you suspect any other packages that will create that file when updating?
    – quanta
    Jun 8 '12 at 14:55
  • I think maybe it's something I did; I commented on the main question so people can see it's possibly an uninteresting question. Jun 8 '12 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.