find command of nobody runs on every fresh boot in the morning - debian stretch

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












Folks,



find executed by nobody runs automatically on every fresh boot (in the morning when I boot the system). I guess it is to do with updatedb. How can I confirm my assumption and stop this from executing automatically. My ps aux | grep find output is as follows:



~~> ps aux | grep find
root 4492 0.0 0.0 4288 748 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
root 4500 0.0 0.0 4288 108 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
root 4526 0.0 0.0 55444 2988 ? SN 08:10 0:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
nobody 4538 0.0 0.0 4288 748 ? SNs 08:10 0:00 sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
nobody 4539 7.9 0.0 16844 2752 ? DN 08:10 0:06 /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex (^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$) ) -prune -o -print0
cathyserver 5223 0.0 0.0 13380 940 pts/1 S+ 08:12 0:00 grep find


First impression is that it some daemon is scouting the /var /tmp /var/spool /alex /amd /afs /var/tmp for something. How can I find which process/daemon executes this? Is this any webserver? By the way I do not have any /alex /amd directories in my system.










share|improve this question

























    up vote
    1
    down vote

    favorite












    Folks,



    find executed by nobody runs automatically on every fresh boot (in the morning when I boot the system). I guess it is to do with updatedb. How can I confirm my assumption and stop this from executing automatically. My ps aux | grep find output is as follows:



    ~~> ps aux | grep find
    root 4492 0.0 0.0 4288 748 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
    root 4500 0.0 0.0 4288 108 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
    root 4526 0.0 0.0 55444 2988 ? SN 08:10 0:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
    nobody 4538 0.0 0.0 4288 748 ? SNs 08:10 0:00 sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
    nobody 4539 7.9 0.0 16844 2752 ? DN 08:10 0:06 /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex (^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$) ) -prune -o -print0
    cathyserver 5223 0.0 0.0 13380 940 pts/1 S+ 08:12 0:00 grep find


    First impression is that it some daemon is scouting the /var /tmp /var/spool /alex /amd /afs /var/tmp for something. How can I find which process/daemon executes this? Is this any webserver? By the way I do not have any /alex /amd directories in my system.










    share|improve this question























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      Folks,



      find executed by nobody runs automatically on every fresh boot (in the morning when I boot the system). I guess it is to do with updatedb. How can I confirm my assumption and stop this from executing automatically. My ps aux | grep find output is as follows:



      ~~> ps aux | grep find
      root 4492 0.0 0.0 4288 748 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
      root 4500 0.0 0.0 4288 108 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
      root 4526 0.0 0.0 55444 2988 ? SN 08:10 0:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
      nobody 4538 0.0 0.0 4288 748 ? SNs 08:10 0:00 sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
      nobody 4539 7.9 0.0 16844 2752 ? DN 08:10 0:06 /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex (^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$) ) -prune -o -print0
      cathyserver 5223 0.0 0.0 13380 940 pts/1 S+ 08:12 0:00 grep find


      First impression is that it some daemon is scouting the /var /tmp /var/spool /alex /amd /afs /var/tmp for something. How can I find which process/daemon executes this? Is this any webserver? By the way I do not have any /alex /amd directories in my system.










      share|improve this question













      Folks,



      find executed by nobody runs automatically on every fresh boot (in the morning when I boot the system). I guess it is to do with updatedb. How can I confirm my assumption and stop this from executing automatically. My ps aux | grep find output is as follows:



      ~~> ps aux | grep find
      root 4492 0.0 0.0 4288 748 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
      root 4500 0.0 0.0 4288 108 ? SN 08:10 0:00 /bin/sh /usr/bin/updatedb.findutils
      root 4526 0.0 0.0 55444 2988 ? SN 08:10 0:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
      nobody 4538 0.0 0.0 4288 748 ? SNs 08:10 0:00 sh -c /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex '(^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$)' ) -prune -o -print0
      nobody 4539 7.9 0.0 16844 2752 ? DN 08:10 0:06 /usr/bin/find / -ignore_readdir_race ( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o -type d -regex (^/tmp$)|(^/usr/tmp$)|(^/var/tmp$)|(^/afs$)|(^/amd$)|(^/alex$)|(^/var/spool$)|(^/sfs$)|(^/media$)|(^/var/lib/schroot/mount$) ) -prune -o -print0
      cathyserver 5223 0.0 0.0 13380 940 pts/1 S+ 08:12 0:00 grep find


      First impression is that it some daemon is scouting the /var /tmp /var/spool /alex /amd /afs /var/tmp for something. How can I find which process/daemon executes this? Is this any webserver? By the way I do not have any /alex /amd directories in my system.







      find background-process webserver daemon






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Sep 22 at 3:13









      RussellB

      18010




      18010




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          4
          down vote



          accepted










          The find is indeed part of updatedb, which runs daily, triggered by the cron daemon.



          You can verify by comparing the find parameters from your process list against the configuration in /etc/updatedb.conf.



          On Debian Stretch you can switch the locate and its corresponding updatedb command between the alternatives mlocate and locate.findutils:



          sudo apt install mlocate locate
          sudo update-alternatives --config locate


          mlocate



          cron daemon uses /etc/cron.daily/mlocate.



          To disable the daily run you can either uninstall the package mlocate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/mlocate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/mlocate


          locate.findutils



          cron daemon uses /etc/cron.daily/locate.



          To disable the daily run you can either uninstall the package locate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/locate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/locate


          Source for disable/enable lines: https://askubuntu.com/questions/268130/can-i-disable-updatedb-mlocate






          share|improve this answer






















          • Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
            – RussellB
            Sep 23 at 8:59










          • Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
            – Marvin
            Sep 23 at 10:11










          • Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
            – RussellB
            Sep 23 at 13:09










          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          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%2f470652%2ffind-command-of-nobody-runs-on-every-fresh-boot-in-the-morning-debian-stretch%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          4
          down vote



          accepted










          The find is indeed part of updatedb, which runs daily, triggered by the cron daemon.



          You can verify by comparing the find parameters from your process list against the configuration in /etc/updatedb.conf.



          On Debian Stretch you can switch the locate and its corresponding updatedb command between the alternatives mlocate and locate.findutils:



          sudo apt install mlocate locate
          sudo update-alternatives --config locate


          mlocate



          cron daemon uses /etc/cron.daily/mlocate.



          To disable the daily run you can either uninstall the package mlocate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/mlocate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/mlocate


          locate.findutils



          cron daemon uses /etc/cron.daily/locate.



          To disable the daily run you can either uninstall the package locate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/locate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/locate


          Source for disable/enable lines: https://askubuntu.com/questions/268130/can-i-disable-updatedb-mlocate






          share|improve this answer






















          • Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
            – RussellB
            Sep 23 at 8:59










          • Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
            – Marvin
            Sep 23 at 10:11










          • Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
            – RussellB
            Sep 23 at 13:09














          up vote
          4
          down vote



          accepted










          The find is indeed part of updatedb, which runs daily, triggered by the cron daemon.



          You can verify by comparing the find parameters from your process list against the configuration in /etc/updatedb.conf.



          On Debian Stretch you can switch the locate and its corresponding updatedb command between the alternatives mlocate and locate.findutils:



          sudo apt install mlocate locate
          sudo update-alternatives --config locate


          mlocate



          cron daemon uses /etc/cron.daily/mlocate.



          To disable the daily run you can either uninstall the package mlocate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/mlocate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/mlocate


          locate.findutils



          cron daemon uses /etc/cron.daily/locate.



          To disable the daily run you can either uninstall the package locate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/locate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/locate


          Source for disable/enable lines: https://askubuntu.com/questions/268130/can-i-disable-updatedb-mlocate






          share|improve this answer






















          • Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
            – RussellB
            Sep 23 at 8:59










          • Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
            – Marvin
            Sep 23 at 10:11










          • Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
            – RussellB
            Sep 23 at 13:09












          up vote
          4
          down vote



          accepted







          up vote
          4
          down vote



          accepted






          The find is indeed part of updatedb, which runs daily, triggered by the cron daemon.



          You can verify by comparing the find parameters from your process list against the configuration in /etc/updatedb.conf.



          On Debian Stretch you can switch the locate and its corresponding updatedb command between the alternatives mlocate and locate.findutils:



          sudo apt install mlocate locate
          sudo update-alternatives --config locate


          mlocate



          cron daemon uses /etc/cron.daily/mlocate.



          To disable the daily run you can either uninstall the package mlocate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/mlocate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/mlocate


          locate.findutils



          cron daemon uses /etc/cron.daily/locate.



          To disable the daily run you can either uninstall the package locate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/locate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/locate


          Source for disable/enable lines: https://askubuntu.com/questions/268130/can-i-disable-updatedb-mlocate






          share|improve this answer














          The find is indeed part of updatedb, which runs daily, triggered by the cron daemon.



          You can verify by comparing the find parameters from your process list against the configuration in /etc/updatedb.conf.



          On Debian Stretch you can switch the locate and its corresponding updatedb command between the alternatives mlocate and locate.findutils:



          sudo apt install mlocate locate
          sudo update-alternatives --config locate


          mlocate



          cron daemon uses /etc/cron.daily/mlocate.



          To disable the daily run you can either uninstall the package mlocate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/mlocate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/mlocate


          locate.findutils



          cron daemon uses /etc/cron.daily/locate.



          To disable the daily run you can either uninstall the package locate or disable its cron job by removing execution right:



          sudo chmod -x /etc/cron.daily/locate


          To re-enable it:



          sudo chmod +x /etc/cron.daily/locate


          Source for disable/enable lines: https://askubuntu.com/questions/268130/can-i-disable-updatedb-mlocate







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Sep 23 at 10:05

























          answered Sep 22 at 7:41









          Marvin

          1464




          1464











          • Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
            – RussellB
            Sep 23 at 8:59










          • Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
            – Marvin
            Sep 23 at 10:11










          • Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
            – RussellB
            Sep 23 at 13:09
















          • Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
            – RussellB
            Sep 23 at 8:59










          • Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
            – Marvin
            Sep 23 at 10:11










          • Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
            – RussellB
            Sep 23 at 13:09















          Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
          – RussellB
          Sep 23 at 8:59




          Thanks @Marvin. It is indeed run by the updatedb. However, a change in your technical elaboration: Instead of mlocate it is locate in my system ( I do not know is that to do with debian stretch). The command that triggers the find operation is updatedb.findutils. One thing which I am yet to understand is the prunepaths. In my output, I have direcotories /alex /amd .... In my configuration I couldn't find any /alex rather only /amd. Any idea?
          – RussellB
          Sep 23 at 8:59












          Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
          – Marvin
          Sep 23 at 10:11




          Sorry @RussellB, though I am using Debian Stretch, I was not aware of the alternative package locate. I have now adjusted my answer to reflect both locate packages. Also I tried to find information about the /alex path, but could not. PRUNEPATHS on my system is configured to "/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph", no /alex nor /amd. Does a sudo grep -r "/alex" /etc give you any hit?
          – Marvin
          Sep 23 at 10:11












          Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
          – RussellB
          Sep 23 at 13:09




          Oh my! I found /alex! It's in the /etc/cron.daily/locate:PRUNEPATHS variable. Thanks Marvin for updating the answer.
          – RussellB
          Sep 23 at 13:09

















           

          draft saved


          draft discarded















































           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470652%2ffind-command-of-nobody-runs-on-every-fresh-boot-in-the-morning-debian-stretch%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay