3 ms·

Can you share more about your setup? Is it cronjobs to just apt-get update && apt-get upgrade -y? How do you handle packages that require reboots?

christophilus 5y ago
I haven’t had a reboot required in over a year, I think. The service is a Go program, and the only OS-managed dependency is ffmpeg. If a reboot interrupts the transcoding jobs, they just retry, so it’s really zero maintenance.
stevekemp 5y ago
If you're running Debian/Ubuntu then you should look at the "unattended-upgrades" package.
- mtlynch 5y ago
  Cool, thanks for the tip! I hadn't seen that package before.
giantrobot 5y ago
In my experience precious few packages on the Ubuntu LTS releases (I'm sure it applies to other distros too) require reboots. It's basically only been kernel upgrades. There's few user space packages I imagine even benefiting from a reboot. Restarting a long running daemon is pretty painless. Also on a warm running system you've got an active page cache so all the unchanged files that service wants to open are likely cached in RAM rather than read from disk. While I appreciate the flexibility low effort VMs provide I think they've negatively affected the views of Linux users. Long uptime is fine and restarting a whole machine is rarely necessary. At the same time modern systems with crazy fast SSDs make a reboot take little longer than just restarting a service.
- chousuke 5y ago
  There's honestly very little reason not to run VMs nowadays. It's like using LVM for disks on Linux; virtually zero overhead and you'll be happy you went with it when you do need the flexibility it provides. I'd pretty much run bare metal only if every server is used for a singular purpose that uses 100% of the available resources. Lots of hardware servers spend several minutes initializing themselves on boot. a RHEL 8 VM on a reasonably powerful host reboots in less than 5 seconds; a service restart causes approximately the same downtime that a reboot does.
ehou 5y ago
Not OP. My servers get this: $ apt install unattended-upgrades # /etc/apt/apt.conf.d/99unattended-upgrades-custom Unattended-Upgrade::Sender "Root at servername.domain.tld <servername.domain.tld@servicesdomain.tld>"; Unattended-Upgrade::Mail "services@servicesdomain.tld"; Unattended-Upgrade::MailReport "on-change"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "05:00"; $ sudo systemctl edit apt-daily.timer # Opens a new file /etc/systemd/system/apt-daily.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 03:00 RandomizedDelaySec=30m $ sudo systemctl edit apt-daily-upgrade.timer # Opens a new file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 04:00 RandomizedDelaySec=30m .. and are auto-updated. When a reboot is needed after an update, it gets rebooted automatically.

christophilus 5y ago

I haven’t had a reboot required in over a year, I think. The service is a Go program, and the only OS-managed dependency is ffmpeg. If a reboot interrupts the transcoding jobs, they just retry, so it’s really zero maintenance.

stevekemp 5y ago

If you're running Debian/Ubuntu then you should look at the "unattended-upgrades" package.

mtlynch 5y ago
Cool, thanks for the tip! I hadn't seen that package before.

giantrobot 5y ago

In my experience precious few packages on the Ubuntu LTS releases (I'm sure it applies to other distros too) require reboots. It's basically only been kernel upgrades. There's few user space packages I imagine even benefiting from a reboot. Restarting a long running daemon is pretty painless. Also on a warm running system you've got an active page cache so all the unchanged files that service wants to open are likely cached in RAM rather than read from disk. While I appreciate the flexibility low effort VMs provide I think they've negatively affected the views of Linux users. Long uptime is fine and restarting a whole machine is rarely necessary. At the same time modern systems with crazy fast SSDs make a reboot take little longer than just restarting a service.

chousuke 5y ago
There's honestly very little reason not to run VMs nowadays. It's like using LVM for disks on Linux; virtually zero overhead and you'll be happy you went with it when you do need the flexibility it provides. I'd pretty much run bare metal only if every server is used for a singular purpose that uses 100% of the available resources. Lots of hardware servers spend several minutes initializing themselves on boot. a RHEL 8 VM on a reasonably powerful host reboots in less than 5 seconds; a service restart causes approximately the same downtime that a reboot does.

ehou 5y ago

Not OP. My servers get this: $ apt install unattended-upgrades # /etc/apt/apt.conf.d/99unattended-upgrades-custom Unattended-Upgrade::Sender "Root at servername.domain.tld <servername.domain.tld@servicesdomain.tld>"; Unattended-Upgrade::Mail "services@servicesdomain.tld"; Unattended-Upgrade::MailReport "on-change"; Unattended-Upgrade::Automatic-Reboot "true"; Unattended-Upgrade::Automatic-Reboot-Time "05:00"; $ sudo systemctl edit apt-daily.timer # Opens a new file /etc/systemd/system/apt-daily.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 03:00 RandomizedDelaySec=30m $ sudo systemctl edit apt-daily-upgrade.timer # Opens a new file /etc/systemd/system/apt-daily-upgrade.timer.d/override.conf, paste this content: [Timer] # Reset the system calendar config first OnCalendar= # Set a new calendar timer with a 60 minute threshold OnCalendar=*-*-* 04:00 RandomizedDelaySec=30m .. and are auto-updated. When a reboot is needed after an update, it gets rebooted automatically.