files created then deleted at every second in tmp directory












1















By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp I managed to catch the created files:



-rw------- 1 root root       0 Apr  2 19:37  YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6


or another example:



-rw------- 1 root root       0 Apr  2 19:44  AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2


It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.



What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD



Thank you!



UPDATE



The guilty software is x2goserver.service.










share|improve this question

























  • "a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

    – Rinzwind
    2 hours ago






  • 1





    /tmp may not necessarily be tmpfs, so it's a valid question

    – Colin Ian King
    2 hours ago











  • Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

    – Peter Cordes
    27 mins ago
















1















By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp I managed to catch the created files:



-rw------- 1 root root       0 Apr  2 19:37  YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6


or another example:



-rw------- 1 root root       0 Apr  2 19:44  AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2


It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.



What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD



Thank you!



UPDATE



The guilty software is x2goserver.service.










share|improve this question

























  • "a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

    – Rinzwind
    2 hours ago






  • 1





    /tmp may not necessarily be tmpfs, so it's a valid question

    – Colin Ian King
    2 hours ago











  • Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

    – Peter Cordes
    27 mins ago














1












1








1








By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp I managed to catch the created files:



-rw------- 1 root root       0 Apr  2 19:37  YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6


or another example:



-rw------- 1 root root       0 Apr  2 19:44  AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2


It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.



What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD



Thank you!



UPDATE



The guilty software is x2goserver.service.










share|improve this question
















By mistake I noticed that in /tmp directory are continuously created some files then immediately deleted. Using a succession of ls -l /tmp I managed to catch the created files:



-rw------- 1 root root       0 Apr  2 19:37  YlOmPA069G
-rw------- 1 root root 0 Apr 2 19:37 l74jZzbcs6


or another example:



-rw------- 1 root root       0 Apr  2 19:44  AwVhWakvQ_
-rw------- 1 root root 0 Apr 2 19:44 RpRGl__cIM
-rw------- 1 root root 0 Apr 2 19:44 S0e72nkpBl
-rw------- 1 root root 0 Apr 2 19:44 emxIQQMSy2


It's about Ubuntu 18.10 with 4.18.0-16-generic. This is an almost fresh install: I added some server software (nginx, mysql, php7.2-fpm) but even with those closed the problem persists.



What are the files created and why?
How would I stop this behaviour? a very undesirable one on a SSD



Thank you!



UPDATE



The guilty software is x2goserver.service.







files tmp tmpfs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 hours ago







adrhc

















asked 2 hours ago









adrhcadrhc

12517




12517













  • "a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

    – Rinzwind
    2 hours ago






  • 1





    /tmp may not necessarily be tmpfs, so it's a valid question

    – Colin Ian King
    2 hours ago











  • Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

    – Peter Cordes
    27 mins ago



















  • "a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

    – Rinzwind
    2 hours ago






  • 1





    /tmp may not necessarily be tmpfs, so it's a valid question

    – Colin Ian King
    2 hours ago











  • Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

    – Peter Cordes
    27 mins ago

















"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

– Rinzwind
2 hours ago





"a very undesirable one on a SSD" explain this please? You don't have /tmp as a tmpfs? why not? why would files in memory damage a ssd?

– Rinzwind
2 hours ago




1




1





/tmp may not necessarily be tmpfs, so it's a valid question

– Colin Ian King
2 hours ago





/tmp may not necessarily be tmpfs, so it's a valid question

– Colin Ian King
2 hours ago













Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

– Peter Cordes
27 mins ago





Yes, it would be undesirable on a SSD, at least if the directory metadata actually got written back to disk instead of just staying hot in cache. This is why /tmp is normally on tmpfs (a ramdisk filesystem that uses the pagecache as its backing store); you tagged your question with the tmpfs, so your comments about SSDs seem out of place.

– Peter Cordes
27 mins ago










2 Answers
2






active

oldest

votes


















4














I suggest installing and running fnotifystat to detect the process that is creating these files:



sudo apt-get install fnotifystat
sudo fnotifystat -i /tmp


You will see process that is doing the open/close/read/write activity something like the following:



Total   Open  Close   Read  Write   PID  Process         Pathname
3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)





share|improve this answer































    3














    Determine which program/process is touching files



    You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:



    $ sudo fnotifystat -i /tmp


    Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).





    Put /tmp into RAM instead of disk



    If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.



    $ sudo vim /etc/fstab

    ...
    # tmpfs in RAM
    tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
    ...


    $ sudo mount /tmp
    $ mount | grep tmp # Check /tmp is in RAM
    tmpfs on /tmp type tmpfs (rw,noatime)


    If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.






    share|improve this answer


























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      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: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      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%2faskubuntu.com%2fquestions%2f1130673%2ffiles-created-then-deleted-at-every-second-in-tmp-directory%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      I suggest installing and running fnotifystat to detect the process that is creating these files:



      sudo apt-get install fnotifystat
      sudo fnotifystat -i /tmp


      You will see process that is doing the open/close/read/write activity something like the following:



      Total   Open  Close   Read  Write   PID  Process         Pathname
      3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
      2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
      1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)





      share|improve this answer




























        4














        I suggest installing and running fnotifystat to detect the process that is creating these files:



        sudo apt-get install fnotifystat
        sudo fnotifystat -i /tmp


        You will see process that is doing the open/close/read/write activity something like the following:



        Total   Open  Close   Read  Write   PID  Process         Pathname
        3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
        2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
        1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)





        share|improve this answer


























          4












          4








          4







          I suggest installing and running fnotifystat to detect the process that is creating these files:



          sudo apt-get install fnotifystat
          sudo fnotifystat -i /tmp


          You will see process that is doing the open/close/read/write activity something like the following:



          Total   Open  Close   Read  Write   PID  Process         Pathname
          3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
          2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
          1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)





          share|improve this answer













          I suggest installing and running fnotifystat to detect the process that is creating these files:



          sudo apt-get install fnotifystat
          sudo fnotifystat -i /tmp


          You will see process that is doing the open/close/read/write activity something like the following:



          Total   Open  Close   Read  Write   PID  Process         Pathname
          3.0 1.0 1.0 0.0 1.0 5748 firefox /tmp/cubeb-shm-5748-input (deleted)
          2.0 0.0 1.0 0.0 1.0 18135 firefox /tmp/cubeb-shm-5748-output (deleted)
          1.0 1.0 0.0 0.0 0.0 5748 firefox /tmp/cubeb-shm-5748-output (deleted)






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 hours ago









          Colin Ian KingColin Ian King

          12.4k13747




          12.4k13747

























              3














              Determine which program/process is touching files



              You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:



              $ sudo fnotifystat -i /tmp


              Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).





              Put /tmp into RAM instead of disk



              If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.



              $ sudo vim /etc/fstab

              ...
              # tmpfs in RAM
              tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
              ...


              $ sudo mount /tmp
              $ mount | grep tmp # Check /tmp is in RAM
              tmpfs on /tmp type tmpfs (rw,noatime)


              If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.






              share|improve this answer






























                3














                Determine which program/process is touching files



                You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:



                $ sudo fnotifystat -i /tmp


                Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).





                Put /tmp into RAM instead of disk



                If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.



                $ sudo vim /etc/fstab

                ...
                # tmpfs in RAM
                tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
                ...


                $ sudo mount /tmp
                $ mount | grep tmp # Check /tmp is in RAM
                tmpfs on /tmp type tmpfs (rw,noatime)


                If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.






                share|improve this answer




























                  3












                  3








                  3







                  Determine which program/process is touching files



                  You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:



                  $ sudo fnotifystat -i /tmp


                  Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).





                  Put /tmp into RAM instead of disk



                  If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.



                  $ sudo vim /etc/fstab

                  ...
                  # tmpfs in RAM
                  tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
                  ...


                  $ sudo mount /tmp
                  $ mount | grep tmp # Check /tmp is in RAM
                  tmpfs on /tmp type tmpfs (rw,noatime)


                  If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.






                  share|improve this answer















                  Determine which program/process is touching files



                  You can use tools such as lsof to determine which processes and binaries are touching/opening which files. This could become troublesome if the files change frequently, so you can instead set up a watch to notify you:



                  $ sudo fnotifystat -i /tmp


                  Sometimes, simply looking at the user or group owner gives you a good hint (ie: ls -lsha).





                  Put /tmp into RAM instead of disk



                  If you desire, you can put your /tmp directory into RAM. You will have to determine if this is a smart move based on available RAM, as well as the size and frequency of read/writes.



                  $ sudo vim /etc/fstab

                  ...
                  # tmpfs in RAM
                  tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
                  ...


                  $ sudo mount /tmp
                  $ mount | grep tmp # Check /tmp is in RAM
                  tmpfs on /tmp type tmpfs (rw,noatime)


                  If you have enough RAM, this can be considered a very good thing to do for both the longevity of your SSD, as well as the speed of your system. You can even accomplish this with smaller amounts of RAM if you tweak tmpreaper (sometimes tmpwatch) to be more aggressive.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 2 hours ago

























                  answered 2 hours ago









                  earthmeLonearthmeLon

                  6,5231951




                  6,5231951






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • 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%2faskubuntu.com%2fquestions%2f1130673%2ffiles-created-then-deleted-at-every-second-in-tmp-directory%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

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                      Eduardo VII do Reino Unido