How can I detach a process from a bash script?












13















I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.



I have used the disown command in terminal directly, however in bash, disown does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.



In terminal it would look something like this:



$ openocd &    # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB


when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.



Any help would be greatly appreciated.



ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.










share|improve this question

























  • nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

    – Bruce Ediger
    Mar 15 '16 at 0:38






  • 1





    Are you open to using a tool like screen?

    – Eric Renouf
    Mar 15 '16 at 2:52
















13















I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.



I have used the disown command in terminal directly, however in bash, disown does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.



In terminal it would look something like this:



$ openocd &    # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB


when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.



Any help would be greatly appreciated.



ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.










share|improve this question

























  • nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

    – Bruce Ediger
    Mar 15 '16 at 0:38






  • 1





    Are you open to using a tool like screen?

    – Eric Renouf
    Mar 15 '16 at 2:52














13












13








13


4






I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.



I have used the disown command in terminal directly, however in bash, disown does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.



In terminal it would look something like this:



$ openocd &    # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB


when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.



Any help would be greatly appreciated.



ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.










share|improve this question
















I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.



I have used the disown command in terminal directly, however in bash, disown does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.



In terminal it would look something like this:



$ openocd &    # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB


when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.



Any help would be greatly appreciated.



ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.







bash disown






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 15 '16 at 2:10







user2328113

















asked Mar 14 '16 at 23:39









user2328113user2328113

84115




84115













  • nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

    – Bruce Ediger
    Mar 15 '16 at 0:38






  • 1





    Are you open to using a tool like screen?

    – Eric Renouf
    Mar 15 '16 at 2:52



















  • nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

    – Bruce Ediger
    Mar 15 '16 at 0:38






  • 1





    Are you open to using a tool like screen?

    – Eric Renouf
    Mar 15 '16 at 2:52

















nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

– Bruce Ediger
Mar 15 '16 at 0:38





nohup isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.

– Bruce Ediger
Mar 15 '16 at 0:38




1




1





Are you open to using a tool like screen?

– Eric Renouf
Mar 15 '16 at 2:52





Are you open to using a tool like screen?

– Eric Renouf
Mar 15 '16 at 2:52










4 Answers
4






active

oldest

votes


















14














To detach a process from a bash script:



nohup ./process &


If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.



If you wish to execute a detached command while being able to see the output in the terminal, then use tail:



TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &





share|improve this answer


























  • Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

    – James Wierzba
    4 hours ago











  • @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

    – marc
    1 hour ago





















5














For me this works perfectly fine with disown



command & disown





share|improve this answer































    1














    a simple and portable solution :



    echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
    pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
    echo "openocd is running with pid: $pid"
    gdb


    Some portability caveats: ps options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1. at could not be available (weird, but this happens...). $(...) needs a not reallllly old shell, otherwise use backticks.






    share|improve this answer


























    • This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

      – orion
      Mar 15 '16 at 8:06








    • 1





      @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

      – Olivier Dulac
      Mar 15 '16 at 9:21













    • of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

      – Olivier Dulac
      Mar 15 '16 at 10:42





















    1














    The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website



    Once compiled, it can be used in a script as follows:



    $ ./detach -p debug.pid openocd <args> # detach openocd
    $ gdb <args> # run gdb
    $ kill -9 $(cat debug.pid) # end openocd process
    $ rm debug.pid # remove file containing process id


    This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f269805%2fhow-can-i-detach-a-process-from-a-bash-script%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      14














      To detach a process from a bash script:



      nohup ./process &


      If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.



      If you wish to execute a detached command while being able to see the output in the terminal, then use tail:



      TEMP_LOG_FILE=tmp.log
      > "$TEMP_LOG_FILE"
      nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &





      share|improve this answer


























      • Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

        – James Wierzba
        4 hours ago











      • @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

        – marc
        1 hour ago


















      14














      To detach a process from a bash script:



      nohup ./process &


      If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.



      If you wish to execute a detached command while being able to see the output in the terminal, then use tail:



      TEMP_LOG_FILE=tmp.log
      > "$TEMP_LOG_FILE"
      nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &





      share|improve this answer


























      • Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

        – James Wierzba
        4 hours ago











      • @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

        – marc
        1 hour ago
















      14












      14








      14







      To detach a process from a bash script:



      nohup ./process &


      If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.



      If you wish to execute a detached command while being able to see the output in the terminal, then use tail:



      TEMP_LOG_FILE=tmp.log
      > "$TEMP_LOG_FILE"
      nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &





      share|improve this answer















      To detach a process from a bash script:



      nohup ./process &


      If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out.



      If you wish to execute a detached command while being able to see the output in the terminal, then use tail:



      TEMP_LOG_FILE=tmp.log
      > "$TEMP_LOG_FILE"
      nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited 1 hour ago

























      answered Mar 15 '16 at 10:50









      marcmarc

      1,5881520




      1,5881520













      • Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

        – James Wierzba
        4 hours ago











      • @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

        – marc
        1 hour ago





















      • Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

        – James Wierzba
        4 hours ago











      • @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

        – marc
        1 hour ago



















      Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

      – James Wierzba
      4 hours ago





      Why is nohup necassary? What is the difference between nohup COMMAND & and COMMAND & if your goal is only to run command in background and free the terminal?

      – James Wierzba
      4 hours ago













      @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

      – marc
      1 hour ago







      @JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…

      – marc
      1 hour ago















      5














      For me this works perfectly fine with disown



      command & disown





      share|improve this answer




























        5














        For me this works perfectly fine with disown



        command & disown





        share|improve this answer


























          5












          5








          5







          For me this works perfectly fine with disown



          command & disown





          share|improve this answer













          For me this works perfectly fine with disown



          command & disown






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered May 5 '17 at 12:05









          ManuelSchneid3rManuelSchneid3r

          1,74372246




          1,74372246























              1














              a simple and portable solution :



              echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
              pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
              echo "openocd is running with pid: $pid"
              gdb


              Some portability caveats: ps options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1. at could not be available (weird, but this happens...). $(...) needs a not reallllly old shell, otherwise use backticks.






              share|improve this answer


























              • This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

                – orion
                Mar 15 '16 at 8:06








              • 1





                @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

                – Olivier Dulac
                Mar 15 '16 at 9:21













              • of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

                – Olivier Dulac
                Mar 15 '16 at 10:42


















              1














              a simple and portable solution :



              echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
              pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
              echo "openocd is running with pid: $pid"
              gdb


              Some portability caveats: ps options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1. at could not be available (weird, but this happens...). $(...) needs a not reallllly old shell, otherwise use backticks.






              share|improve this answer


























              • This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

                – orion
                Mar 15 '16 at 8:06








              • 1





                @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

                – Olivier Dulac
                Mar 15 '16 at 9:21













              • of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

                – Olivier Dulac
                Mar 15 '16 at 10:42
















              1












              1








              1







              a simple and portable solution :



              echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
              pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
              echo "openocd is running with pid: $pid"
              gdb


              Some portability caveats: ps options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1. at could not be available (weird, but this happens...). $(...) needs a not reallllly old shell, otherwise use backticks.






              share|improve this answer















              a simple and portable solution :



              echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
              pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
              echo "openocd is running with pid: $pid"
              gdb


              Some portability caveats: ps options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1. at could not be available (weird, but this happens...). $(...) needs a not reallllly old shell, otherwise use backticks.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Mar 15 '16 at 5:15

























              answered Mar 15 '16 at 5:03









              Olivier DulacOlivier Dulac

              3,8331325




              3,8331325













              • This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

                – orion
                Mar 15 '16 at 8:06








              • 1





                @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

                – Olivier Dulac
                Mar 15 '16 at 9:21













              • of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

                – Olivier Dulac
                Mar 15 '16 at 10:42





















              • This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

                – orion
                Mar 15 '16 at 8:06








              • 1





                @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

                – Olivier Dulac
                Mar 15 '16 at 9:21













              • of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

                – Olivier Dulac
                Mar 15 '16 at 10:42



















              This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

              – orion
              Mar 15 '16 at 8:06







              This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.

              – orion
              Mar 15 '16 at 8:06






              1




              1





              @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

              – Olivier Dulac
              Mar 15 '16 at 9:21







              @orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have at start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.

              – Olivier Dulac
              Mar 15 '16 at 9:21















              of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

              – Olivier Dulac
              Mar 15 '16 at 10:42







              of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)

              – Olivier Dulac
              Mar 15 '16 at 10:42













              1














              The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website



              Once compiled, it can be used in a script as follows:



              $ ./detach -p debug.pid openocd <args> # detach openocd
              $ gdb <args> # run gdb
              $ kill -9 $(cat debug.pid) # end openocd process
              $ rm debug.pid # remove file containing process id


              This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.






              share|improve this answer




























                1














                The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website



                Once compiled, it can be used in a script as follows:



                $ ./detach -p debug.pid openocd <args> # detach openocd
                $ gdb <args> # run gdb
                $ kill -9 $(cat debug.pid) # end openocd process
                $ rm debug.pid # remove file containing process id


                This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.






                share|improve this answer


























                  1












                  1








                  1







                  The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website



                  Once compiled, it can be used in a script as follows:



                  $ ./detach -p debug.pid openocd <args> # detach openocd
                  $ gdb <args> # run gdb
                  $ kill -9 $(cat debug.pid) # end openocd process
                  $ rm debug.pid # remove file containing process id


                  This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.






                  share|improve this answer













                  The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website



                  Once compiled, it can be used in a script as follows:



                  $ ./detach -p debug.pid openocd <args> # detach openocd
                  $ gdb <args> # run gdb
                  $ kill -9 $(cat debug.pid) # end openocd process
                  $ rm debug.pid # remove file containing process id


                  This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered May 4 '17 at 18:11









                  user2328113user2328113

                  84115




                  84115






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f269805%2fhow-can-i-detach-a-process-from-a-bash-script%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      CARDNET

                      Boot-repair Failure: Unable to locate package grub-common:i386

                      濃尾地震