Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. Qt application unable to catch sudo reboot / sudo poweroff from terminal
Forum Updated to NodeBB v4.3 + New Features

Qt application unable to catch sudo reboot / sudo poweroff from terminal

Scheduled Pinned Locked Moved Unsolved Mobile and Embedded
25 Posts 5 Posters 8.3k Views 3 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.
  • JonBJ JonB

    @kshegunov
    I already asked him this question above:

    Also, how precisely do you judge that "my implementation doesn't work as expected when I execute sudo reboot / sudo poweroff"?

    He replied:

    @JNBarchan
    application is able to catch sudo kill -15 pid, to confirm the reception of signal I am writing to syslog directly as LOG_ALERT and also to a file. ( just writing short phrases in both instances )

    I take him at his word, that he sees these from kill but not from shutdown...!

    kshegunovK Offline
    kshegunovK Offline
    kshegunov
    Moderators
    wrote on last edited by
    #16

    @JNBarchan said in Qt application unable to catch sudo reboot / sudo poweroff from terminal:

    I already asked him this question above

    Missed that, sorry. Your suggestion is good, but as @SGaist pointed out there may be no time to really respond to the sequence of signals, and SIGKILL isn't something you can catch.

    Read and abide by the Qt Code of Conduct

    JonBJ 1 Reply Last reply
    0
    • kshegunovK kshegunov

      @JNBarchan said in Qt application unable to catch sudo reboot / sudo poweroff from terminal:

      I already asked him this question above

      Missed that, sorry. Your suggestion is good, but as @SGaist pointed out there may be no time to really respond to the sequence of signals, and SIGKILL isn't something you can catch.

      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #17

      @kshegunov
      I do not know about this area, but I believed the OP was saying that the system logged in syslog the sent/delivered signals to processes and he was looking through that. I may have misunderstood, and he only means his application does the logging when signal received, and then indeed we could have race conditions or no such signal actually sent.

      This indicates even more that OP needs to read up elsewhere how others handle "graceful shutdown" --- assuming it is designed to allow brief code execution in response to SIGTERM before delievery of something like SIGKILL.... e.g. perhaps start from https://stackoverflow.com/questions/22009705/how-to-detect-linux-shutdown-reboot, which might be indicating the same issue as OP is reporting?

      kshegunovK 1 Reply Last reply
      0
      • JonBJ JonB

        @kshegunov
        I do not know about this area, but I believed the OP was saying that the system logged in syslog the sent/delivered signals to processes and he was looking through that. I may have misunderstood, and he only means his application does the logging when signal received, and then indeed we could have race conditions or no such signal actually sent.

        This indicates even more that OP needs to read up elsewhere how others handle "graceful shutdown" --- assuming it is designed to allow brief code execution in response to SIGTERM before delievery of something like SIGKILL.... e.g. perhaps start from https://stackoverflow.com/questions/22009705/how-to-detect-linux-shutdown-reboot, which might be indicating the same issue as OP is reporting?

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by
        #18

        I think the problem here is there's a very few functions that can be called from a signal handler. It may be that the process is actually segfaulting, or if the exact example from the Qt docs is used then the acceptance of the SIGTERM would mean the continuation of the shutdown sequence (and subsequently killing the process as it hasn't quit). I'd try the following (use only the allowed POSIX functions for the signal handler):

        1. Create a semaphore on startup and acquire it
        2. When you get the SIGTERM write to the socket pair and acquire the semaphore again to prevent returning from the handler
        3. Do the clean up from the Qt handler
        4. Subscribe to the aboutToQuit signal and release the semaphore from the slot
        5. Only then return from the signal handler

        The above you could also accomplish by selecting on the socket you opened and writing back a byte after your Qt handler has been called and the cleanup code has run.

        Read and abide by the Qt Code of Conduct

        JonBJ 1 Reply Last reply
        0
        • kshegunovK kshegunov

          I think the problem here is there's a very few functions that can be called from a signal handler. It may be that the process is actually segfaulting, or if the exact example from the Qt docs is used then the acceptance of the SIGTERM would mean the continuation of the shutdown sequence (and subsequently killing the process as it hasn't quit). I'd try the following (use only the allowed POSIX functions for the signal handler):

          1. Create a semaphore on startup and acquire it
          2. When you get the SIGTERM write to the socket pair and acquire the semaphore again to prevent returning from the handler
          3. Do the clean up from the Qt handler
          4. Subscribe to the aboutToQuit signal and release the semaphore from the slot
          5. Only then return from the signal handler

          The above you could also accomplish by selecting on the socket you opened and writing back a byte after your Qt handler has been called and the cleanup code has run.

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by JonB
          #19

          @kshegunov
          OP says of what happens when signal delivered:

          my implementation doesn't work as expected when I execute sudo reboot / sudo poweroff in a terminal, though internally SIGTERM signal is getting emitted. Have checked this in syslog.

          I'm still unclear whether he means he writes to syslog from his handler, or that the OS automatically logs signal delivery itself. I'm thinking the latter, as he's saying:

          yet my application doesn't hit my signal handler when sudo poweroff / sudo reboot is executed through terminal. But when I execute kill -15 pid ( pid of my application ) signal handler gets executed

          It depends on whether during shutdown he is truly not receiving the initial SIGTERM which would initiate his clean up code, or whether actually he is receiving it but very soon afterwards he's getting a SIGKILL or similar, so that his clean up code doesn't get to do much. Even if he hasn't yet returned from the SIGTERM handler, I thought nothing would block the SIGKILL from immediate delivery and termination, surely it doesn't care that you are presently in a signal handler?

          kshegunovK 1 Reply Last reply
          0
          • JonBJ JonB

            @kshegunov
            OP says of what happens when signal delivered:

            my implementation doesn't work as expected when I execute sudo reboot / sudo poweroff in a terminal, though internally SIGTERM signal is getting emitted. Have checked this in syslog.

            I'm still unclear whether he means he writes to syslog from his handler, or that the OS automatically logs signal delivery itself. I'm thinking the latter, as he's saying:

            yet my application doesn't hit my signal handler when sudo poweroff / sudo reboot is executed through terminal. But when I execute kill -15 pid ( pid of my application ) signal handler gets executed

            It depends on whether during shutdown he is truly not receiving the initial SIGTERM which would initiate his clean up code, or whether actually he is receiving it but very soon afterwards he's getting a SIGKILL or similar, so that his clean up code doesn't get to do much. Even if he hasn't yet returned from the SIGTERM handler, I thought nothing would block the SIGKILL from immediate delivery and termination, surely it doesn't care that you are presently in a signal handler?

            kshegunovK Offline
            kshegunovK Offline
            kshegunov
            Moderators
            wrote on last edited by
            #20

            I'd really like to see some code, though.
            For one not everything can be done from a signal handler (as Qt's docs correctly note), and for two you need to register the handlers in such a way so you don't get interleaved signal handlers called, otherwise it's a big mess. A signal sent to the process is much like an interrupt, so it can get quite complicated if you're not requesting them to be queued.

            Read and abide by the Qt Code of Conduct

            N 1 Reply Last reply
            2
            • kshegunovK kshegunov

              I'd really like to see some code, though.
              For one not everything can be done from a signal handler (as Qt's docs correctly note), and for two you need to register the handlers in such a way so you don't get interleaved signal handlers called, otherwise it's a big mess. A signal sent to the process is much like an interrupt, so it can get quite complicated if you're not requesting them to be queued.

              N Offline
              N Offline
              NarutoKun
              wrote on last edited by kshegunov
              #21

              @kshegunov @JNBarchan

              Sorry was away hence couldn't respond.

              Have written a C code for handling SIGTERM even here I am unable to catch sudo reboot / sudo poweroff, but my handler is able to catch kill -15 pid. I am creating a text file upon arrival of the signal.

              Through this exercise atleast I am sure I am missing some concepts of how to handle Signals.

              #include <stdio.h>
              #include <signal.h>
              #include <unistd.h>
              
              void signal_handler()
              {
              // Open a file on receiving the signal
               FILE *fp = fopen("naruto.txt", "ab+");
              }
              
              void main()
              {
                  pid_t app_pid;
                  struct sigaction a;
              
              // PID of the application
                  app_pid = getpid();
              
                  printf("process pid %d \n",app_pid);
              
              // assigning the signal handler
                  a.sa_handler = signal_handler;
              // Restarting system calls 
                  a.sa_flags = SA_RESTART;
              
                  if (sigaction(SIGTERM,&a, NULL) < 0)
                  {
                      printf("error");
                  }
                  if (sigaction(SIGINT,&a , NULL) < 0)
                  {
                      printf("error");
                  }
              // Waiting for the signal
                  pause();
              
                  printf("end\n");
              }
              

              I am also trying to understand how to use RUN_LVL parameter for graceful shutdown. Thanks for the link.

              [Added code tags ~kshegunov]

              JonBJ 1 Reply Last reply
              0
              • N NarutoKun

                @kshegunov @JNBarchan

                Sorry was away hence couldn't respond.

                Have written a C code for handling SIGTERM even here I am unable to catch sudo reboot / sudo poweroff, but my handler is able to catch kill -15 pid. I am creating a text file upon arrival of the signal.

                Through this exercise atleast I am sure I am missing some concepts of how to handle Signals.

                #include <stdio.h>
                #include <signal.h>
                #include <unistd.h>
                
                void signal_handler()
                {
                // Open a file on receiving the signal
                 FILE *fp = fopen("naruto.txt", "ab+");
                }
                
                void main()
                {
                    pid_t app_pid;
                    struct sigaction a;
                
                // PID of the application
                    app_pid = getpid();
                
                    printf("process pid %d \n",app_pid);
                
                // assigning the signal handler
                    a.sa_handler = signal_handler;
                // Restarting system calls 
                    a.sa_flags = SA_RESTART;
                
                    if (sigaction(SIGTERM,&a, NULL) < 0)
                    {
                        printf("error");
                    }
                    if (sigaction(SIGINT,&a , NULL) < 0)
                    {
                        printf("error");
                    }
                // Waiting for the signal
                    pause();
                
                    printf("end\n");
                }
                

                I am also trying to understand how to use RUN_LVL parameter for graceful shutdown. Thanks for the link.

                [Added code tags ~kshegunov]

                JonBJ Offline
                JonBJ Offline
                JonB
                wrote on last edited by JonB
                #22

                @NarutoKun

                Have written a C code for handling SIGTERM even here I am unable to catch sudo reboot / sudo poweroff, but my handler is able to catch kill -15 pid.

                So what document/example are you working from for handling reboot/poweroff? Because there seems to be no evidence from your findings that it even sends a SIGTERM or whatever, or you aren't getting time to handle them, or other things are happening first! There must be posts on the web giving some suggested code for your situation?

                N 1 Reply Last reply
                0
                • JonBJ JonB

                  @NarutoKun

                  Have written a C code for handling SIGTERM even here I am unable to catch sudo reboot / sudo poweroff, but my handler is able to catch kill -15 pid.

                  So what document/example are you working from for handling reboot/poweroff? Because there seems to be no evidence from your findings that it even sends a SIGTERM or whatever, or you aren't getting time to handle them, or other things are happening first! There must be posts on the web giving some suggested code for your situation?

                  N Offline
                  N Offline
                  NarutoKun
                  wrote on last edited by
                  #23

                  @JNBarchan
                  Didn't get your question
                  So what document/example are you working from for handling reboot/poweroff?

                  For evidence of which Signal I am receiving on sudo reboot / sudo poweroff the following message gets logged in syslog file

                  rosui rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="656" x-info="http://www.rsyslog.com"] exiting on signal 15.

                  JonBJ kshegunovK 2 Replies Last reply
                  0
                  • N NarutoKun

                    @JNBarchan
                    Didn't get your question
                    So what document/example are you working from for handling reboot/poweroff?

                    For evidence of which Signal I am receiving on sudo reboot / sudo poweroff the following message gets logged in syslog file

                    rosui rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="656" x-info="http://www.rsyslog.com"] exiting on signal 15.

                    JonBJ Offline
                    JonBJ Offline
                    JonB
                    wrote on last edited by
                    #24

                    @NarutoKun
                    I mean, IMHO, you need to be looking at some documentation/code which shows how to handle your shutdown in a C-type program. It's clear it's doing a lot more than just a simple kill -15 does, so you need something which explains what's going on and what your code needs to do to handle it.

                    1 Reply Last reply
                    0
                    • N NarutoKun

                      @JNBarchan
                      Didn't get your question
                      So what document/example are you working from for handling reboot/poweroff?

                      For evidence of which Signal I am receiving on sudo reboot / sudo poweroff the following message gets logged in syslog file

                      rosui rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="656" x-info="http://www.rsyslog.com"] exiting on signal 15.

                      kshegunovK Offline
                      kshegunovK Offline
                      kshegunov
                      Moderators
                      wrote on last edited by kshegunov
                      #25

                      Excerpt from old code follows

                      void signal_handler(int sig)
                      {
                          // ... handle signal here, but have in mind a very limited number of functions are allowed
                      }
                      
                      int main()
                      {
                          // set up the signal handler
                          sigaction action;
                          sigset_t blkMask;
                      
                          sigemptyset(&blkMask); 
                          sigaddset(&blkMask, SIGINT);
                          sigaddset(&blkMask, SIGQUIT);
                          sigaddset(&blkMask, SIGTERM);
                          sigaddset(&blkMask, SIGCHLD);
                          sigaddset(&blkMask, SIGALRM);
                      
                          signal(SIGPIPE, SIG_IGN);
                      
                          action.sa_handler = signal_handler;
                          action.sa_mask = blkMask;
                          action.sa_flags = 0;
                      
                          sigaction(SIGINT , &action, NULL);  
                          sigaction(SIGQUIT, &action, NULL);
                          sigaction(SIGTERM, &action, NULL);
                          sigaction(SIGCHLD, &action, NULL); // Terminates and main proc
                      
                          // ... rest of code ...
                      }
                      

                      My advice is to dedicate some time to read the POSIX documentation very carefully, it's paramount in this case.

                      For evidence of which Signal I am receiving on sudo reboot / sudo poweroff the following message gets logged in syslog file
                      rosui rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="656" x-info="http://www.rsyslog.com"] exiting on signal 15.

                      This doesn't prove you handle that signal, only that it was sent to you. Open a file when starting the application and log the signal number when you enter the signal handler to your file. Again, be sure to use only the functions that are allowed in signal handlers.

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply
                      3

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved