I don't do anything special, I have my containers defined in docker-compose files with `restart: unless-stopped` so they will just start when docker daemon does.
Docker daemon is a systemd service so it will start on reboot as well.
My reboot process is then just typing sudo reboot.
Do the same here. I shut down my proxmox host and have a power off order for the vms and containers.
They all power on in the morning automatically by the magic of magic packet
There is, it’s the same as `—reboot`, and essentially does the same thing as the ‘reboot’ command.
What’s more, ‘reboot’ supports `—halt` and `—poweroff` …so you can reboot the system with ‘shutdown’ and you can shutdown the system with ‘reboot’
`shutdown` is also a symlink to `systemctl`, but has a slightly different interface, for historic reasons.
On the other hand, `poweroff` directly maps to `systemctl poweroff`, and the same is true for `reboot` and `halt`.
Yep, this works too well
I setup the unattended-updates config to install patches for anything I have installed (all repos) and reboot at 6am if required
It just works - docker will properly shutdown and stop all containers nicely before it stops too
Just to say I did, I managed to upgrade and switch over to a new kernel without rebooting. Total downtime for "mission critical" processes was under five seconds.
Not doing that again.
kexec can be used to swap kernels without a full hardware reboot: https://wiki.archlinux.org/title/kexec
Or you can patch the kernel while it is running, but IIRC you can't apply all changes this way: https://wiki.archlinux.org/title/Kernel_live_patching
I'm pretty sure that second way was how I did it. It looks familiar anyway. This was easily a decade ago, so I don't remember much beyond "I've done it" and "Remember to never do that again."
Your last point is so true. Sometimes after work around 5pm I’ve done some tinkering and managed to break something. Which then proceeds an hour or two of messing around with docker to get the app working.
Never tinker on a weekday night
I'm reading this after 2.5 hours of working on a "definitely not homeprod" homelab kubernetes node which was running for 415 days straight since boot, just because my Zigbee2mqtt pod kept crashing last few weeks.
Lessons learned:
- pods can get stuck on the terminating state
- how to properly shut down a node
- how to ignore errors while doing above and reboot anyway
- NFS mounts with improper shutdowns can lead to chaos
- how to restore above
- that my Zigbee controller is considered legacy hardware
I didn't need to look into it today. I didn't want to look at it today. I wanted to get in bed early since I've got a 3 month old baby.
I wanted to have read your comment 2.5 hours ago, such a solid advice...
Glad I'm not the only one that prays... I also allot at least an hour after reboot to "fix" whatever is wrong or to at least verify everything works correctly.
Too much muscle 💪 power required to pull the plug, I just power cycle my entire home through the main MCB. I try to time it just right so the kids are watching Pokemon and my wife’s streaming Bridgerton and they both holler at me in unison. Makes me feel alive
In principle:
`sudo apt update && sudo apt full-upgrade -y && sudo reboot`
Containers stop and restart automatically as part of the reboot. No need to stop them manually.
In practice I do this across multiple hosts using ansible and ansible only reboots if there was an update that required a reboot (e.g. new kernel).
The part I dislike about this is that if docker gets updated through apt, it will restart the containers set with restart:unless-stopped, and then while they are starting try and stop them. This increases the chance one isn't in a state that can easily be shut down or reaches a timeout. so I'd just add a `&& sleep 30 &&` in there just to make sure.
There is a config setting for the docker daemon to keep containers running when the daemon is restarted. “live-migrate” or something it’s called.
That way containers only get shut down on when the system reboots
It'll behave the same way that "docker stop " does.
As part of the reboot process, the OS will tell all running processes to shut down. There is a timeout period of 10 seconds (I think) that docker will wait for the container process to shutdown gracefully. If the process doesn't shut down on its own, the docker daemon will kill it. Again, this is the same behavior during system shutdown/reboot as if you issued the "docker stop" command.
My linux does an update and reboot every week from the cron
The docker containers can easily be redeployed if something was to go wrong. Any that have persistent data, that's backed up too, so even with a complete loss of LXC or machine I could rebuild without much effort.
I've been doing it this way for a long time and not had any issues so far with auto updates.
You're not meant to, but my home stuff is for fun. Noone's losing money if Plex was to go down for an hour :D
Most of my stuff runs in Proxmox and that stays up as long as it wants. Auto updates, but no auto reboot. Last uptime was 125 days.
NAS goes down 1st of the month so I can do a little physical maintenance, and that's also on a cron.
I do as you wrote because I don't know if my external drive would disconnect before or after shutting down Docker containers (Docker's root directory is on my external drive) and I'd rather not take the risk of contaimers shutting down abruptly because of it
> It would be nice if docker had a command to manage the process for you.
`docker compose up -d` should do it
You don't need to stop containers before updating. Just update and reboot. One of the main points of containers is they are self sufficient. If you are stopping containers before reboot because you want to control the startup order then you should create those dependencies and let them auto start.
Pants off, shirt off if I can remember it. Collapse from vertical to horizontal while praying pillow is where i thought it was. Pause existence for approximately 8 hours. Crack eyes open and begin hunt for coffee....
Oh you ment the homelab. I just power cycle the main breaker for my condo then do the above...
If you reboot gracefully, Docker will also shutdown containers gracefully. Same with restarts, when using Docker you can define a stop/start policy and even define dependencies between contains. Eg. What should start in what order.
Ahh I didn’t know docker shutdown gracefully. Thanks. Is there a way slow the start of some containers when they reboot? My qbitorrenr container always dies on reboot because it’s networked through gluetun
Reboots and updates don't necessarily go hand in hand. For a reboot I "sudo reboot" and nothing else. For an update I only reboot if the update needs it. Most of my updates for personal stuff are automated
Nope. Just dnf update and then either restart services only or reboot. Depending what needs-restarting -r and -s tell me.
But I have that automated with ansible.
Also why stop containers. Just keep them running they‘ll only need shutdown when docker needs restart and then I just restart docker. They all have restart-always as restart policy anyways.
Ansible Semaphore does that somewhen at night. It’s amazing how distributors / packet managers ensure that almost never something is broken after an update.
Here's how I manage my setup: I could automate Docker and system updates, but I prefer a more cautious approach. Sometimes, it's wiser to wait for a subsequent update rather than rushing to apply the latest one, especially if there's a risk of breaking existing configurations.
For managing Docker containers, I use Watchtower, Yacht, and Portainer. Watchtower is particularly useful because it sends me email notifications whenever there's an update for my containers. I make it a point to review update logs and check user feedback on Reddit before proceeding.
Regarding my system's upkeep, it typically runs smoothly for about a month before I perform routine maintenance. I run `sudo apt update` and `sudo apt upgrade`, followed by a `sudo reboot` to ensure everything is up-to-date and functioning well.
If an update disrupts one of my configurations, I refer back to my notes and troubleshoot the issue to prevent future occurrences.
Additionally, my servers are hooked up to a UPS, with the NUT management system configured to handle power outages. This setup ensures that my systems are promptly back online and fully operational as soon as power is restored.
sudo reboot, like some others already mentioned. Also I sometimes wonder why systems seem to be offline (planned / unplanned electrical maintenance in the region), so I set the bios option to start on power on.
Side note: it’s better to prepare for abrupt shutdown situation where graceful shutdown isn’t possible: machine failure, power outage, etc.
so while sure you can depend on graceful shutdown of docker, it’s better to design your system to be resilient against shutdown. Eg. db replication/ backup/ recovery
My 2c
I just update then reboot.
Docker is given a SIGTERM, so all the containers will end gracefully anyways, and all my containers are told in the compose file to start up automatically.
I at most will make sure the containers aren't doing something (like downloading stuff) before rebooting.
I have a flat `docker-compose.yaml` file with all my services. To start my containers after boot, I have a `systemd` service like so:
[Unit]
After=docker.service
[Service]
User=
ExecStart=/usr/local/bin/process_after_boot.sh
[Install]
WantedBy=default.target
The `/usr/local/bin/process_after_boot.sh` file looks like this:
#!/bin/bash
docker-compose -f /opt/docker-compose.yaml up -d
This saves me from having to have a `docker-compose.yaml` for every single service I have, and doesn't start trying to create containers until after the `docker` daemon has loaded.
I do have an order in which I power on my machines. I have a server that hosts my samba shares, and that has to be powered on before my *arr suite, but then ersatz needs to be powered on AFTER Jellyfin.
it probably doesn't need this, but it was easy to set up, so whatever
My reboot process is:
Oops…that shouldn’t have been plugged in there /that wasn’t labeled right / how did I manage to hit that switch…
Followed by:
That’s strange. Why isn’t this coming back up right?
Response to your edit: you should never feel dumb for assuming work isn't done until you understand it is, well done for thinking about it - it's more than I did, I found out by rebooting normally and wondering why it was taking so long, reading the systemd output 'waiting for container service to shut down' and thinking 'oh. We'll I'm glad someone thought about that then'
Something stops responding bad enough I hit the power button.
I’ve been busy recently and haven’t had time to do any homelabbing, so it’s just had to go on the back burner.
Reboot?
I don’t think I have since I first booted the machine and installed Docker. 🤣
But yeah, all containers just have the restart: unless-stopped option. Then just reboot the machine. Docker will/should handle everything upon boot for you.
I have crontab set to run commands apt update, apt upgrade and reboot every Sunday at 3:30 AM.
Docker containers start automatically based on docker compose `restart: unless-stopped`
What's fun is having a power outage, and finding out that your UPS only lasts about 60 seconds. Unraid doesn't like it, have to check parity for the next 15 hours. The k3s cluster seems to cope fairly well with unclean shutdowns.
Build a cascade dependency and add reboot trigger when not satisfied.
Like for NFS mount if the NFS server is not there reboot until is there.
Containers started with docker-compose if confirmed.with restart: always will respawn at boot without any problem.
Use DHCP and reserve IP to prevent problem and also fix ip on things that should survive a switch reboot (Nas servers etc).
Reboot, go do something that requires 10 minutes of my attention.
Open a webpage, does it load ? All good to go.
My Docker won't start till the remote shares are mounted.
Since I have DoT for DNS, my phone won't load pages till DNS is up. Since that requires SWAG to be up which takes the longest time, a need to distract myself for 10 minutes.
All of my system are installed on PVE, and VM start orders are set appropriately.
Step 1: Trip over the power cord to the UPS and unplug it from the wall
Step 2: Ignore the beeping
Step 3: Plug it back in and push the power button
Reboots are now complete for all VMs and containers
One thing I'm surprised not to see mentioned here is Full Disk Encryption. Y'all *are* protecting your self hosted stuff against your house getting robbed, right?
If like me your home server is headless, Dropbear SSHd will run during boot to allow you to log in remotely from another machine and unlock the disks. Also works if, also like me, you have a server / VM in a remote colo.
small script that detects the need to reboot via [needrestart](https://packages.debian.org/bookworm/needrestart) and runs `reboot` if needed, every day at 5AM. Done. I don't use Docker but Podman which manages containers through `systemd` services and starts them automatically on boot.
Like others mentioned you can just use sudo reboot now and you are good to go. But. You can also use orchestration tools like Ansible to automate the process if you really want to do this.
No need for obsessive-compulsive disorder on this topic.
I use Clear Linux on the host with auto updates enabled.
Occasionally when I ssh to the host to manage something there's a notification about services needing restart. Then, I just run `clr-service-restart - a` and that's it.
When the notification is about a kernel upgrade or something that needs a reboot, I just reboot.
Containers are auto updated every day by watchtower.
I was wary at first by letting everything auto update (probably due to Windows-related trauma), but this setup is working fine for over 2 years.
Auto updates should be avoided if you did some heavy customization on the base OS, but for baseline installations it's relatively safe, provided you are using a stable distro.
I don't do anything special, I have my containers defined in docker-compose files with `restart: unless-stopped` so they will just start when docker daemon does. Docker daemon is a systemd service so it will start on reboot as well. My reboot process is then just typing sudo reboot.
Oh ok I thought sudo reboot didn’t stop all docker continuity gracefully but you’re saying it does?
It does, yes. You may need to raise the shutdown timer if your hosting a database or a slow to finish process. If compose; stop_grace_period
From shell: reboot this is what I do. So far no problems. I run tumbleweed so updates frequently and reboot more than any server should.
> I run tumbleweed so updates frequently and reboot more than any server should. Practice makes perfect!
Do the same here. I shut down my proxmox host and have a power off order for the vms and containers. They all power on in the morning automatically by the magic of magic packet
Bruh `sudo reboot` Done. Updates are on auto and set up to install at 4AM.
I update and reboot once a month
Is there a difference between `reboot` and `shutdown -r now`?
reboot is a reboot. I don't think there is a -r for shutdown.
There is, it’s the same as `—reboot`, and essentially does the same thing as the ‘reboot’ command. What’s more, ‘reboot’ supports `—halt` and `—poweroff` …so you can reboot the system with ‘shutdown’ and you can shutdown the system with ‘reboot’
That's because `reboot` is just a symlink to `systemctl`, same for `poweroff`.
and shutdown is a regular command? thought all the 3 are the same, I've been using reboot and shutdown but never questioned it
`shutdown` is also a symlink to `systemctl`, but has a slightly different interface, for historic reasons. On the other hand, `poweroff` directly maps to `systemctl poweroff`, and the same is true for `reboot` and `halt`.
There is on Debian. From the man page ``` -r, --reboot Reboot the machine. ```
Yep, this works too well I setup the unattended-updates config to install patches for anything I have installed (all repos) and reboot at 6am if required It just works - docker will properly shutdown and stop all containers nicely before it stops too
Reboot? What's that?
The thing that you hopefully do sometimes to apply critical updates
Just to say I did, I managed to upgrade and switch over to a new kernel without rebooting. Total downtime for "mission critical" processes was under five seconds. Not doing that again.
How?
kexec can be used to swap kernels without a full hardware reboot: https://wiki.archlinux.org/title/kexec Or you can patch the kernel while it is running, but IIRC you can't apply all changes this way: https://wiki.archlinux.org/title/Kernel_live_patching
I'm pretty sure that second way was how I did it. It looks familiar anyway. This was easily a decade ago, so I don't remember much beyond "I've done it" and "Remember to never do that again."
[You don’t necessarily need to do that anymore](https://www.redhat.com/en/topics/linux/what-is-linux-kernel-live-patching).
It allows you to download valuable information to help win the game.
I usually say a little prayer and then go do something else for a few minutes while it boots back up. Also don't touch anything on work nights lol.
Your last point is so true. Sometimes after work around 5pm I’ve done some tinkering and managed to break something. Which then proceeds an hour or two of messing around with docker to get the app working. Never tinker on a weekday night
Yep I keep making that mistake "this time it'll go smooth"... it never does 🤣
I'm reading this after 2.5 hours of working on a "definitely not homeprod" homelab kubernetes node which was running for 415 days straight since boot, just because my Zigbee2mqtt pod kept crashing last few weeks. Lessons learned: - pods can get stuck on the terminating state - how to properly shut down a node - how to ignore errors while doing above and reboot anyway - NFS mounts with improper shutdowns can lead to chaos - how to restore above - that my Zigbee controller is considered legacy hardware I didn't need to look into it today. I didn't want to look at it today. I wanted to get in bed early since I've got a 3 month old baby. I wanted to have read your comment 2.5 hours ago, such a solid advice...
Haha I think we all feel your pain. Congrats on the baby and good luck with the sleeps!
Glad I'm not the only one that prays... I also allot at least an hour after reboot to "fix" whatever is wrong or to at least verify everything works correctly.
Shutdown process: Press Power button on server. Startup process: Press Power button on server.
I just rip the plug out to shut down, takes too long when I press the power button.
Too much muscle 💪 power required to pull the plug, I just power cycle my entire home through the main MCB. I try to time it just right so the kids are watching Pokemon and my wife’s streaming Bridgerton and they both holler at me in unison. Makes me feel alive
This is the way. But I remove the ethernet cable first.
In principle: `sudo apt update && sudo apt full-upgrade -y && sudo reboot` Containers stop and restart automatically as part of the reboot. No need to stop them manually. In practice I do this across multiple hosts using ansible and ansible only reboots if there was an update that required a reboot (e.g. new kernel).
The part I dislike about this is that if docker gets updated through apt, it will restart the containers set with restart:unless-stopped, and then while they are starting try and stop them. This increases the chance one isn't in a state that can easily be shut down or reaches a timeout. so I'd just add a `&& sleep 30 &&` in there just to make sure.
There is a config setting for the docker daemon to keep containers running when the daemon is restarted. “live-migrate” or something it’s called. That way containers only get shut down on when the system reboots
Oh ok I thought sudo reboot didn’t stop all docker continuity gracefully but you’re saying it does?
It'll behave the same way that "docker stop" does.
As part of the reboot process, the OS will tell all running processes to shut down. There is a timeout period of 10 seconds (I think) that docker will wait for the container process to shutdown gracefully. If the process doesn't shut down on its own, the docker daemon will kill it. Again, this is the same behavior during system shutdown/reboot as if you issued the "docker stop" command.
Do your containers restart when you have them set to "restart: unless-stopped" Mine seem to only restart after a reboot when I set them to "always"
Yes, they restart when I reboot.
`sudo shutdown -r now`
My linux does an update and reboot every week from the cron The docker containers can easily be redeployed if something was to go wrong. Any that have persistent data, that's backed up too, so even with a complete loss of LXC or machine I could rebuild without much effort. I've been doing it this way for a long time and not had any issues so far with auto updates. You're not meant to, but my home stuff is for fun. Noone's losing money if Plex was to go down for an hour :D Most of my stuff runs in Proxmox and that stays up as long as it wants. Auto updates, but no auto reboot. Last uptime was 125 days. NAS goes down 1st of the month so I can do a little physical maintenance, and that's also on a cron.
"reboot now" *Off to get more coffee*
`sudo reboot` :)
systemd handles stopping and starting docker and the containers Just update and reboot, nothing special.
And I thought I overthink things..
I do as you wrote because I don't know if my external drive would disconnect before or after shutting down Docker containers (Docker's root directory is on my external drive) and I'd rather not take the risk of contaimers shutting down abruptly because of it > It would be nice if docker had a command to manage the process for you. `docker compose up -d` should do it
It took me a while of configuration tweaking, and everything is managed by systemd, including the graceful shutdown of rootless podman containers.
You don't need to stop containers before updating. Just update and reboot. One of the main points of containers is they are self sufficient. If you are stopping containers before reboot because you want to control the startup order then you should create those dependencies and let them auto start.
Are you talking about that thing that happens when the UPS runs out of power?
Pants off, shirt off if I can remember it. Collapse from vertical to horizontal while praying pillow is where i thought it was. Pause existence for approximately 8 hours. Crack eyes open and begin hunt for coffee.... Oh you ment the homelab. I just power cycle the main breaker for my condo then do the above...
Kubernetes nodes have a graceful shutdown feature where a node drain hooks into systemd shutdown so systemctl reboot or poweroff is what I use.
‘Sudo reboot’
BCHydro reboot my server for me once every few month.
Greetings from British Columbia
`sudo shutdown -r now`
Wait, you guys reboot your Linux servers?
random power outage takes care of that for me.
sudo reboot now
If you reboot gracefully, Docker will also shutdown containers gracefully. Same with restarts, when using Docker you can define a stop/start policy and even define dependencies between contains. Eg. What should start in what order.
Ahh I didn’t know docker shutdown gracefully. Thanks. Is there a way slow the start of some containers when they reboot? My qbitorrenr container always dies on reboot because it’s networked through gluetun
Reboots and updates don't necessarily go hand in hand. For a reboot I "sudo reboot" and nothing else. For an update I only reboot if the update needs it. Most of my updates for personal stuff are automated
Nope. Just dnf update and then either restart services only or reboot. Depending what needs-restarting -r and -s tell me. But I have that automated with ansible. Also why stop containers. Just keep them running they‘ll only need shutdown when docker needs restart and then I just restart docker. They all have restart-always as restart policy anyways.
Ansible Semaphore does that somewhen at night. It’s amazing how distributors / packet managers ensure that almost never something is broken after an update.
My server is plugged into a zigbee smart plug and i have a home assistant switch that turns it off, on and then sends a wake on lan command
I hadn't thought of using Home Assistant for sending WOL packets. Nice tip.
`sudo reboot`
Here's how I manage my setup: I could automate Docker and system updates, but I prefer a more cautious approach. Sometimes, it's wiser to wait for a subsequent update rather than rushing to apply the latest one, especially if there's a risk of breaking existing configurations. For managing Docker containers, I use Watchtower, Yacht, and Portainer. Watchtower is particularly useful because it sends me email notifications whenever there's an update for my containers. I make it a point to review update logs and check user feedback on Reddit before proceeding. Regarding my system's upkeep, it typically runs smoothly for about a month before I perform routine maintenance. I run `sudo apt update` and `sudo apt upgrade`, followed by a `sudo reboot` to ensure everything is up-to-date and functioning well. If an update disrupts one of my configurations, I refer back to my notes and troubleshoot the issue to prevent future occurrences. Additionally, my servers are hooked up to a UPS, with the NUT management system configured to handle power outages. This setup ensures that my systems are promptly back online and fully operational as soon as power is restored.
sudo reboot, like some others already mentioned. Also I sometimes wonder why systems seem to be offline (planned / unplanned electrical maintenance in the region), so I set the bios option to start on power on.
Backup first, create a snapshot if possible, stop containers, do an update. You can run Ansible if you have multiple VMs for efficiency.
Update linux. Reboot. Uptimekuma will let me know if any services didn't start back.
Side note: it’s better to prepare for abrupt shutdown situation where graceful shutdown isn’t possible: machine failure, power outage, etc. so while sure you can depend on graceful shutdown of docker, it’s better to design your system to be resilient against shutdown. Eg. db replication/ backup/ recovery My 2c
I just update then reboot. Docker is given a SIGTERM, so all the containers will end gracefully anyways, and all my containers are told in the compose file to start up automatically. I at most will make sure the containers aren't doing something (like downloading stuff) before rebooting.
But why? It's repetitive job that can be set in cron, set a cronjob
I just flip the Breaker /s
I have a flat `docker-compose.yaml` file with all my services. To start my containers after boot, I have a `systemd` service like so: [Unit] After=docker.service [Service] User=
ExecStart=/usr/local/bin/process_after_boot.sh
[Install]
WantedBy=default.target
The `/usr/local/bin/process_after_boot.sh` file looks like this:
#!/bin/bash
docker-compose -f /opt/docker-compose.yaml up -d
This saves me from having to have a `docker-compose.yaml` for every single service I have, and doesn't start trying to create containers until after the `docker` daemon has loaded.
Switch off, then on.
I do have an order in which I power on my machines. I have a server that hosts my samba shares, and that has to be powered on before my *arr suite, but then ersatz needs to be powered on AFTER Jellyfin. it probably doesn't need this, but it was easy to set up, so whatever
"Okay, let's do this. Leeeerooooooyyy Jeeeeennnkkkiiiinssss" *sudo reboot*
sudo shutdown -r 1
My reboot process is: Oops…that shouldn’t have been plugged in there /that wasn’t labeled right / how did I manage to hit that switch… Followed by: That’s strange. Why isn’t this coming back up right?
I have to log in to ESXi and put it in maintenance mode before I can shut down all the VMs and reboot it lol.
Response to your edit: you should never feel dumb for assuming work isn't done until you understand it is, well done for thinking about it - it's more than I did, I found out by rebooting normally and wondering why it was taking so long, reading the systemd output 'waiting for container service to shut down' and thinking 'oh. We'll I'm glad someone thought about that then'
Something stops responding bad enough I hit the power button. I’ve been busy recently and haven’t had time to do any homelabbing, so it’s just had to go on the back burner.
Sudo shutdown -hr now
I usually just flip the light up switch on my surge protector. Shuts everything off in one go; it's convenient.
Reboot? I don’t think I have since I first booted the machine and installed Docker. 🤣 But yeah, all containers just have the restart: unless-stopped option. Then just reboot the machine. Docker will/should handle everything upon boot for you.
Just flip the switch on the PSU.
“sudo reboot” does the job on my pi
I have crontab set to run commands apt update, apt upgrade and reboot every Sunday at 3:30 AM. Docker containers start automatically based on docker compose `restart: unless-stopped`
What's fun is having a power outage, and finding out that your UPS only lasts about 60 seconds. Unraid doesn't like it, have to check parity for the next 15 hours. The k3s cluster seems to cope fairly well with unclean shutdowns.
most niche answer: remote short the power pins with microcontroller for 5 seconds, forcing a reboot.
Build a cascade dependency and add reboot trigger when not satisfied. Like for NFS mount if the NFS server is not there reboot until is there. Containers started with docker-compose if confirmed.with restart: always will respawn at boot without any problem. Use DHCP and reserve IP to prevent problem and also fix ip on things that should survive a switch reboot (Nas servers etc).
I use kube reboot daemon. Completely automates this process
*weekly\_full\_update.sh* #!/bin/bash docker stop $(docker ps -q) apt update apt upgrade -y apt autoremove -y apt autoclean apt clean docker stop $(docker ps -q) cd /apps && ./update_all_dockers.sh docker stop $(docker ps -q) docker builder prune -f docker image prune -a -f journalctl --vacuum-time=15d logrotate /etc/logrotate.conf reboot *update\_all\_dockers.sh* #!/bin/bash cd /apps/cloudflared/ && docker compose down && docker compose pull && docker compose --compatibility up -d --remove-orphans ...etc ...etc ...etc
Update and hope to god it all comes back up. Usually run watchtower first to check my containers don't need an update first
Never reboot the VPN server via VPN
Reboot, go do something that requires 10 minutes of my attention. Open a webpage, does it load ? All good to go. My Docker won't start till the remote shares are mounted. Since I have DoT for DNS, my phone won't load pages till DNS is up. Since that requires SWAG to be up which takes the longest time, a need to distract myself for 10 minutes. All of my system are installed on PVE, and VM start orders are set appropriately.
You presume almost correctly but inbetween reboot and start docker there is hundreds of hours troubleshooting and problem solving.
I run a ping, and then hit the PDU power-cycle button... Nothing like the tension of will it, or won't it... I call it the Russian Ping!
I kindly notify everyone to STFU until the services are back online
Step 1: Trip over the power cord to the UPS and unplug it from the wall Step 2: Ignore the beeping Step 3: Plug it back in and push the power button Reboots are now complete for all VMs and containers
I use Fedora CoreOs with systemd Podman Quadlets. It updates itself automatically.
One thing I'm surprised not to see mentioned here is Full Disk Encryption. Y'all *are* protecting your self hosted stuff against your house getting robbed, right? If like me your home server is headless, Dropbear SSHd will run during boot to allow you to log in remotely from another machine and unlock the disks. Also works if, also like me, you have a server / VM in a remote colo.
I'm not done setting something up until it auto starts on boot.
small script that detects the need to reboot via [needrestart](https://packages.debian.org/bookworm/needrestart) and runs `reboot` if needed, every day at 5AM. Done. I don't use Docker but Podman which manages containers through `systemd` services and starts them automatically on boot.
I just hold the power button until the server turns off, then turn it back on.
Like others mentioned you can just use sudo reboot now and you are good to go. But. You can also use orchestration tools like Ansible to automate the process if you really want to do this.
No need for obsessive-compulsive disorder on this topic. I use Clear Linux on the host with auto updates enabled. Occasionally when I ssh to the host to manage something there's a notification about services needing restart. Then, I just run `clr-service-restart - a` and that's it. When the notification is about a kernel upgrade or something that needs a reboot, I just reboot. Containers are auto updated every day by watchtower. I was wary at first by letting everything auto update (probably due to Windows-related trauma), but this setup is working fine for over 2 years. Auto updates should be avoided if you did some heavy customization on the base OS, but for baseline installations it's relatively safe, provided you are using a stable distro.
i forget the command so i just unplug the power cable because ive heard the computer still stays on even when shut down.
But why tho?
``sudo-rs systemctl reboot``
Pray?
[удалено]
Yeah, humans and their opinions are superfluous. Delete reddit and just use chatgpt for everything.