Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Feature Requests
  3. Option to automatically reboot Ubuntu for security updates

Option to automatically reboot Ubuntu for security updates

Scheduled Pinned Locked Moved Feature Requests
securityupdates
23 Posts 10 Posters 4.4k Views 11 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • mehdiM Offline
    mehdiM Offline
    mehdi
    App Dev
    wrote on last edited by
    #6

    Isn't it simply that the server takes a long time to shut down, but a normal time to boot up ? I guess it would explain all these symptoms. When rebooting from the VPS control panel, it's a hard shutdown, so there's no time lost.

    I guess someone who has a server at home could test this hypothesis.

    LonkleL 1 Reply Last reply
    0
    • nebulonN Away
      nebulonN Away
      nebulon
      Staff
      wrote on last edited by
      #7

      We removed the explicit sync in the reboot script now: https://git.cloudron.io/cloudron/box/-/commit/dd75cdb37ed751b31c35755e5e8c2f96daeec81b

      Lets see if this fixes the slow reboots at least. As mentioned in that commit, running sync on a system which is busy using the disks, it can take a long time. So usually first the processes have to be terminated and then the sync should be issued. This is what happens from now on then. I don't even remember why we put that sync there in the first place.

      imc67I 1 Reply Last reply
      3
      • mehdiM mehdi

        Isn't it simply that the server takes a long time to shut down, but a normal time to boot up ? I guess it would explain all these symptoms. When rebooting from the VPS control panel, it's a hard shutdown, so there's no time lost.

        I guess someone who has a server at home could test this hypothesis.

        LonkleL Offline
        LonkleL Offline
        Lonkle
        wrote on last edited by
        #8

        @mehdi You know what, I probably thought the virtual VPS screen was showing me a boot up animation instead it what it was actually showing me, the shut down animation. TIL I have no idea what the current Ubuntu startup animation looks like.

        Also, I've wanted to ask ya, @nebulon, I know the Docker base image is based on 20.04 (Bionic?), but the Cloudron platform is built on 18.04. Is there a plan to update that one day or do you feel as long as Ubuntu supports it with security updates, there are no benefits to update?

        1 Reply Last reply
        0
        • nebulonN Away
          nebulonN Away
          nebulon
          Staff
          wrote on last edited by
          #9

          The base image is on Bionic Beaver which is actually 18.04 LTS http://releases.ubuntu.com/18.04/
          There is no technical reason to have the base image be the same Ubuntu version or even the same Linux distribution as the host system.

          Ubuntu 20.04 support will come soon for the host system, but the base image will remain on 18.04 for some time, since changing that requires retesting and fixing all app packages for no real reason at the moment.

          The most important aspect is that the versions are still supported for security updates.

          LonkleL 1 Reply Last reply
          1
          • nebulonN nebulon

            The base image is on Bionic Beaver which is actually 18.04 LTS http://releases.ubuntu.com/18.04/
            There is no technical reason to have the base image be the same Ubuntu version or even the same Linux distribution as the host system.

            Ubuntu 20.04 support will come soon for the host system, but the base image will remain on 18.04 for some time, since changing that requires retesting and fixing all app packages for no real reason at the moment.

            The most important aspect is that the versions are still supported for security updates.

            LonkleL Offline
            LonkleL Offline
            Lonkle
            wrote on last edited by Lonkle
            #10

            @nebulon So it was completely the other way around. You're updating the host version (what Cloudron runs on) to 20.04 (Focal), but leaving the DOCKERIMAGE FROM base version at 18.04 (Bionic) until at least security patch support stops coming out for it. Did I get that correct this time? πŸ˜‡

            Sorry, new to the Ubuntu world.

            1 Reply Last reply
            2
            • nebulonN nebulon

              We removed the explicit sync in the reboot script now: https://git.cloudron.io/cloudron/box/-/commit/dd75cdb37ed751b31c35755e5e8c2f96daeec81b

              Lets see if this fixes the slow reboots at least. As mentioned in that commit, running sync on a system which is busy using the disks, it can take a long time. So usually first the processes have to be terminated and then the sync should be issued. This is what happens from now on then. I don't even remember why we put that sync there in the first place.

              imc67I Online
              imc67I Online
              imc67
              translator
              wrote on last edited by
              #11

              @nebulon and @girish somehow this change (or something else) made the reboot of my 3 cloudron servers superfast!

              Before it took at least 4-6 minutes and today everything (all services and apps) are up again within 1 minute!!!!

              Good job!!

              πŸ™‚

              d19dotcaD 1 Reply Last reply
              4
              • imc67I imc67

                @nebulon and @girish somehow this change (or something else) made the reboot of my 3 cloudron servers superfast!

                Before it took at least 4-6 minutes and today everything (all services and apps) are up again within 1 minute!!!!

                Good job!!

                πŸ™‚

                d19dotcaD Offline
                d19dotcaD Offline
                d19dotca
                wrote on last edited by
                #12

                @imc67 Same here. Was really fast tonight for security updates.

                --
                Dustin Dauncey
                www.d19.ca

                1 Reply Last reply
                0
                • DanTheManD Offline
                  DanTheManD Offline
                  DanTheMan
                  wrote on last edited by
                  #13

                  Mine was really noticable faster too. Running Ubuntu 18.04 OS here.
                  Reboot and apps up and running in less than a minute. Like 40 to 45 seconds in total.

                  Keep up the good work Cloudron staff πŸ‘ πŸ‘

                  1 Reply Last reply
                  1
                  • jdaviescoatesJ Offline
                    jdaviescoatesJ Offline
                    jdaviescoates
                    wrote on last edited by jdaviescoates
                    #14

                    Wow. 🀯

                    It's WAY faster now.

                    Like, lightning fast. ⚑

                    I just did a reboot to finish a Ubuntu security update and everything was back up and running in less than 60 seconds.

                    I almost couldn't believe it!

                    Thanks!

                    I use Cloudron with Gandi & Hetzner

                    1 Reply Last reply
                    0
                    • LonkleL Offline
                      LonkleL Offline
                      Lonkle
                      wrote on last edited by
                      #15

                      Same here, less than a minute now. Still looking forward to live patches. But I reboot a lot to change the way apphealthmonitor.js works (making it more accurate) and I need to reboot after every change so this is just a godsend. πŸŽ‰

                      1 Reply Last reply
                      2
                      • d19dotcaD Offline
                        d19dotcaD Offline
                        d19dotca
                        wrote on last edited by
                        #16

                        Guess that β€œsync” was the problem then, though weird if it’s been in there for years already without issues. Maybe something just incompatible after certain updates were applied which caused sync to take so long.

                        --
                        Dustin Dauncey
                        www.d19.ca

                        1 Reply Last reply
                        0
                        • robiR Offline
                          robiR Offline
                          robi
                          wrote on last edited by
                          #17

                          @DanTheMan
                          Likely due to improvements in 18.04.4 and above.

                          @Lonk
                          To avoid having to reboot the box, you can run your tests in a docker container using the sysbox-runc for full OS (machine image) capability in a docker container.

                          Then just reboot the sysbox container.
                          See requirements: https://github.com/nestybox/sysbox-ee/blob/master/docs/distro-compat.md

                          Conscious tech

                          LonkleL 1 Reply Last reply
                          0
                          • robiR robi

                            @DanTheMan
                            Likely due to improvements in 18.04.4 and above.

                            @Lonk
                            To avoid having to reboot the box, you can run your tests in a docker container using the sysbox-runc for full OS (machine image) capability in a docker container.

                            Then just reboot the sysbox container.
                            See requirements: https://github.com/nestybox/sysbox-ee/blob/master/docs/distro-compat.md

                            LonkleL Offline
                            LonkleL Offline
                            Lonkle
                            wrote on last edited by
                            #18

                            @robi Interesting feature. Could save development time. Thanks!

                            1 Reply Last reply
                            0
                            • W Offline
                              W Offline
                              warg
                              wrote on last edited by warg
                              #19

                              Is there any news on this? What shall we do if the only sysadmin is on vacation/sick for 4 weeks? A automatic reboot in case it's needed for security updates would be good.

                              1 Reply Last reply
                              1
                              • nebulonN Away
                                nebulonN Away
                                nebulon
                                Staff
                                wrote on last edited by
                                #20

                                I guess it may make sense to add an optional automatic reboot in such cases, although this may cause downtime in unexpected timeslots if apps are used in multiple timezones, especially if reboot takes longer.

                                1 Reply Last reply
                                2
                                • W Offline
                                  W Offline
                                  warg
                                  wrote on last edited by
                                  #21

                                  Yep. For those cases it shouldn't be too bad: The fixed timeslots/dates can be communicated/planned accordingly and if it's on demand and no admin is available, the users can get told that they should be worried only if downtime is >1h or something like that. That's at least better than no patched server and in worst case coming home and finding a disaster 😬.

                                  1 Reply Last reply
                                  1
                                  • robiR Offline
                                    robiR Offline
                                    robi
                                    wrote on last edited by robi
                                    #22

                                    This can be automated today with ctfreak which can reboot a system if certain conditions are met. Would be good to document such options.

                                    Conscious tech

                                    1 Reply Last reply
                                    5
                                    • W warg referenced this topic on
                                    • nebulonN nebulon

                                      Ideally we soon can enable ubuntu livepatch by default, then this should go away. Until that it looks like we have some blocking process or so during reboot. We have gotten various reports now that reboots are slow and I also saw that on one of our company Cloudrons yesterday. Unfortunately we are not sure what happens yet.

                                      potemkin_aiP Offline
                                      potemkin_aiP Offline
                                      potemkin_ai
                                      wrote on last edited by
                                      #23

                                      @nebulon just for information - livepatch doesn't mean you don't have to reboot - it just lets you postpone that moment as convenient.

                                      For sync - a good practice on old good *nix is to issue sync twice before reboot - to make sure the buffers dumped for sure.

                                      On the reboot automation using third-party apps - it's doable; everything is, but why, if you can just add it inside of the system?

                                      1 Reply Last reply
                                      3
                                      Reply
                                      • Reply as topic
                                      Log in to reply
                                      • Oldest to Newest
                                      • Newest to Oldest
                                      • Most Votes


                                      • Login

                                      • Don't have an account? Register

                                      • Login or register to search.
                                      • First post
                                        Last post
                                      0
                                      • Categories
                                      • Recent
                                      • Tags
                                      • Popular
                                      • Bookmarks
                                      • Search