[SOLVED] Suspending every 30 seconds

Forum Forums New users New Users and General Questions [SOLVED] Suspending every 30 seconds

Tagged: ,

  • This topic has 6 replies, 2 voices, and was last updated Aug 12-8:54 pm by Xecure.
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #64194

      I am an antiX beginner comfortable on command line but not having deep experience with Linux.

      I created a zero-persistence thumb drive using latest Rufus on Windows 10.

      Ancient unit:

      Toshiba Satellite A75 – (year 2004)
      Mobile Pentium 4 – 3.2 GHz
      RAM: 1536 MiB

      I cannot get near to attempting an install, because when I boot fully into antiX from the USB thumb, this laptop *SUSPENDS* every 30 seconds — and I have to hit the Power button to wake it again.

      Linux Lite 3.6 (September 2017; last 32-bit version) has been installed and operating without problem on this dinosaur for three or four years now. I recall that my USB boot thumb for it worked without problem.

      Does anyone have advice to this newbie as to how to surmount this repeated-suspend problem?

      I couldn’t find a solution anywhere online.

      PS — Probably not relevant, but when antiX thumb boots up, the “Boot Options” field says:

      quiet splasht disable=1xF

      I don’t think it sleeps/suspends if I stay on the pre-boot screen, but only after I boot fully into antiX.

      [The one or 2 BIOS updates that came after mine (v. 1.30) had no critical relevance or significance.]


        See if this helps:

        you could disable […] in /etc/elogind/logind.conf
        should look like
        to disable the button event.
        Suspension will still work if manually called for from the menu (like suspend, reboot, poweroff), but the button event will not trigger them.

        You need administrator privileges, so you can edit the file as root running in terminal
        sudo geany /etc/elogind/logind.conf
        or use a one liner to disable it without opening the file
        sudo sed -i 's/#HandleLidSwitch=suspend/HandleLidSwitch=ignore/' /etc/elogind/logind.conf

        Let us know if this works.

        antiX Live system enthusiast.
        General Live Boot Parameters for antiX.


          I will try as you indicate (by tomorrow latest), thanks!

          Question: This issue — as I am experiencing it — is not related in the least to any “closed/opened” display/lid or “wake/non-wake” issue.

          Do you mind indicating (for my education) how the ‘HandleLidSwitch’ attribute might be related to the repeated, unrequested suspend/sleeps?

          Thank you!


            My theory (speculation) is that the elogind program incorrectly recognizes some acpi events as the Lid switch triggering. Or that the kernel is the one that incorrectly recognizes an event and elogind catches the incorrect kernel signal as a lid-switch event.

            I base it on a few threads that popped up in the forum, this one being the most recent one. It has been an issue on some systems, and this workaround seems to have helped.

            antiX Live system enthusiast.
            General Live Boot Parameters for antiX.


              @Xecure, tonight this was a SUCCESS thanks to your assistance!

              It took me 10 days to get back to attempting your solution. It worked.

              Tonight, with the laptop suspending every 30 seconds — and with the functional complexities and options of live-persistence boot devices (a simple 4GB USB thumb in my case) being new to me — it took some frustrating hours to make it work.

              I followed the antiX recommendation to not apply persistence when creating the USB boot thumb drive two weeks ago, but instead to generate this when booting antiX the first time.

              I made the mistake of applying persist_HOME the first time when I should have selected persist_ROOT — so as to be able to make permanent the modification to the logind.conf file.

              So on the next boot, I told it to configure the thumb as persist_root

              Is the act of applying TWO different persist configurations (‘home’ and ‘root’) to the same USB thumb something that is OK?

              In applying the SECOND persist option (‘root’), I worried that it would mess up (i.e., confuse) the thumb drive.

              But now I am surmising that it was probably harmless to do so — and that the boot thumb simply has two different persistence options available for selection at booting of the live thumb drive.

              PS — I am glad I chose BASE antiX. This ancient (17-year-old) laptop machine with its slow-spinning HD (probably 4800 RPM) cannot deal with “Firefox 2021” — the minimal (but UP-TO-DATE!!) SeaMonkey browser does the job!

              As long as the SeaMonkey browser that comes in the BASE version allows me to disable JavaScript, and it does…I am happy!

              I do own actual 21st Century computers (Acer laptop and new M1 Mac Mini)…this old Toshiba dinosaur is just kept around for sentimental reasons. I am very GRATEFUL for antiX and its offering of 32-bit versions!

              Thanks so much for your thoughtful and kind assistance!


                Dear Admins, kindly mark as [SOLVED]…thanks!


                  tonight this was a SUCCESS

                  That is very good news. Thanks for letting me know that it worked.

                  About persistence, even if files are already created, the live system will only use what you tell it to in the live boot parameters/options, so if there is no home persistence options enabled in the boot menus (even if you have used them before) and you want to get back some free space on your USB device, you can delete the homefs file (no longer needed).

                  Going back to this elogind problem, and after testing things with a suggestion by the antiX main dev, I am thinking, when the next antiX version is released, of creating a 32bit re-spin of antiX using consolekit instead of elogind. I think most of these auto-suspension issues that have been taking place on the old 32bit computers could be avoided if elogind is not in charge as a login/session (and power events) of the user. It is a requirement if not using systemd for big desktop environments like Gnome and KDE, but I think it is not required for most other antiX programs (if at all).

                  Thanks again for reporting back and marking the thread as solved.


                  antiX Live system enthusiast.
                  General Live Boot Parameters for antiX.

                Viewing 7 posts - 1 through 7 (of 7 total)
                • You must be logged in to reply to this topic.