1

I have some cron tasks unique to root. One of these has a reboot command in the end.

Say I SSH with my work user and while doing some task with it, the reboot-requiring root task will run in the background:

Will the root reboot log my other work user of the SSH?

If I would have to bet, I would bet that it won't take my work user out, as it is another session, but as I'm new to Unix cron, it is important for me to ask it here and that more people could find this easily.

Why would I even want to reboot:

The task is apt-get update && apt-get upgrade, and as I know, it might require reboot.

  • 1
    Reboot is reboot for the entire system... You cannot reboot one session and have the system stay up in another system. – AlexP Dec 14 '16 at 15:10
  • A reboot is never actually required. It's only required to take advantage of all the bug fixes provided by the upgrade (strictly speaking, it's only really needed for a kernel upgrade), but if you don't care about that in the short term, you can keep your system running. – Gilles 'SO- stop being evil' Dec 14 '16 at 23:46
3

If you have a cron job that has a reboot command in it, the whole system will get rebooted (as @AlexP said), no user sessions (local or remote) or processes will stay active.

As an aside, you might want to consider why you have a reboot task in your cron job; is there a service or process you could restart rather than rebooting the whole machine that would accomplish the same goal? It has been my experience with Linux based systems that it is rare that you need to fully reboot the system. I can think of a couple of cases, but they are few and far between.

  • The task is apt-get update && apt-get upgrade – JohnDoea Dec 14 '16 at 16:09
  • @Benia As of Linux Kernel 4.0, you no longer need to reboot for kernel upgrades. Most anything else that needs to get upgraded can just have it's service restarted. Additionally, be careful about blindly upgrading your system; this might be ok for workstations, but any server environment you run the risk of having a package upgrade crash and burn and at minimum services stop responding, or worse, the system not coming back up after reboot. – Deff Dec 14 '16 at 16:37
  • Thank you for this clarification. I will remove the "reboot" command from the root cron tasks. BTW, I've been thought by my Unix teacher to always reboot after installing a new Linux Os on a VPS because the version the hosting platform install might be a bit outdated... What do you think of this? – JohnDoea Dec 14 '16 at 16:50
  • If he's completely re-laying down the OS from scratch (a fresh install), typically you'll need to reboot out of the installer environment (anaconda/debootstrap) and into the actual OS anyways. If he's just upgrading the packages on a new VPS but leaving the base installation intact, the reboot isn't (shouldn't be) necessary. That being said, it can kick some services in the pants that don't restart after upgrade like they are supposed to. Once running in "production", you really want to be aware of what you are upgrading and what steps need to be done to successfully complete that upgrade. – Deff Dec 14 '16 at 17:03
  • 1
    If you're updating a shared library that requires an updated version of another shared library, any program that uses both libraries can get an error if it's started up after one library has been updated but before the other has been updated. If you have any critical services running, it's best to stop them (migrating them to another redundant server if necessary) before applying patches. – Mark Plotnick Dec 14 '16 at 21:28

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.