Unraveling the Mysterious “find” Command Running as Nobody on Debian Stretch at Boot

At revWhiteShadow, we understand the importance of a clean and predictable system startup. It’s disconcerting to observe unexpected processes, especially when they involve elevated privileges and run under the “nobody” user. In this article, we, revWhiteShadow and kts, will methodically investigate the persistent find command, uncover its origin, and provide definitive solutions to control or disable it, all within the context of Debian Stretch. This guide goes beyond simple fixes, offering a deep dive into the system’s configuration to ensure a comprehensive understanding and long-term solution.

Identifying the Culprit: Deep Dive into Process Analysis

Your initial observation points strongly toward updatedb as the likely cause. Let’s solidify this assumption with targeted analysis. The ps aux | grep find output provides valuable clues, but we need more context.

Examining the Parent Processes

The initial output shows that /usr/bin/updatedb.findutils is the parent process. To pinpoint the exact source, we need to trace back further. Let’s use pstree to visualize the process tree. Run the following command:

pstree -p <PID_OF_UPDATEDB.FINDUILS>

Replace <PID_OF_UPDATEDB.FINDUILS> with the process ID of /usr/bin/updatedb.findutils from your ps aux output (e.g., 4492). This will reveal the parent process that initiated updatedb. Common scenarios include:

  • Cron Jobs: If pstree shows cron as the parent, then a cron job is triggering the updatedb execution.
  • Systemd Timers: If pstree shows systemd, then a systemd timer unit is responsible.
  • User Session: In rare cases, a user’s session startup scripts might be the cause.

Analyzing updatedb.findutils Script

The script /usr/bin/updatedb.findutils is a crucial piece of the puzzle. Examine its contents using cat /usr/bin/updatedb.findutils or a text editor like nano or vim. Look for:

  • Invocation of find: Verify that the script contains the exact find command that you observed in the ps aux output.
  • Conditions for Execution: Identify any conditional statements within the script that might explain why the find command is being executed only on boot. Check for date-based or system-state-based conditions.
  • User Switching: Confirm the su nobody command and understand why the script is designed to run find under the “nobody” user. This is a security measure to limit the potential damage if the find command were to be exploited.

Verifying updatedb Configuration

The behavior of updatedb is governed by its configuration file, /etc/updatedb.conf. Inspect this file using cat /etc/updatedb.conf. Pay close attention to the following parameters:

  • PRUNEPATHS: This variable lists directories that updatedb should exclude from its search. Ensure that the directories listed in your find command’s -prune options are included in PRUNEPATHS. If not, updatedb might be configured to scan directories you want excluded which can cause I/O load.
  • PRUNEFS: This variable lists filesystem types that updatedb should ignore. Verify that any network filesystem types (NFS, cifs, etc.) that are mounted on your system are present in PRUNEFS.
  • FIND_OPTIONS: Look closely at options used. If this command has changed it could lead to the reported problem.

Disabling or Modifying updatedb Execution

Once you’ve confirmed that updatedb is indeed the source of the find command, you have several options to control its behavior:

Disabling updatedb via Systemd

If updatedb is triggered by a systemd timer, this is the cleanest and recommended method.

  1. Identify the Timer Unit: Use systemctl list-timers to find the systemd timer unit associated with updatedb. It’s likely named something like updatedb.timer.

  2. Disable the Timer: Use the following command to disable the timer unit:

    sudo systemctl disable updatedb.timer

  3. Stop the Timer (Optional): If the timer is currently running, you can stop it with:

    sudo systemctl stop updatedb.timer

  4. Mask the Service (Optional, but Recommended): Masking prevents the service from being started by any other means.

    sudo systemctl mask updatedb.service

Disabling updatedb via Cron

If updatedb is triggered by a cron job, follow these steps:

  1. Identify the Cron File: The cron job might be located in one of the following files:

    • /etc/crontab
    • /etc/cron.d/*
    • /var/spool/cron/crontabs/* (user-specific cron jobs)

    Use grep -r updatedb /etc/cron* /var/spool/cron/* to search for the relevant cron entry.

  2. Comment Out the Cron Entry: Open the cron file with a text editor (e.g., sudo nano /etc/crontab) and comment out the line that executes updatedb by adding a # at the beginning of the line.

Modifying updatedb.conf to Reduce Impact

If you need updatedb to run but want to minimize its impact on system performance, consider these modifications to /etc/updatedb.conf:

  1. Extensive PRUNEPATHS: Add any directories that are frequently accessed or cause performance bottlenecks to the PRUNEPATHS variable. This will prevent updatedb from scanning those directories. Add these ones from your research: /alex /amd

  2. Refine PRUNEFS: Ensure that all relevant network filesystem types (NFS, cifs, sshfs, etc.) are included in the PRUNEFS variable.

  3. Adjust FIND_OPTIONS (Advanced): Carefully modify the FIND_OPTIONS variable to further optimize the find command. For example, you could add the -maxdepth option to limit the depth of the search. However, exercise caution when modifying FIND_OPTIONS, as incorrect changes can break updatedb.

    FIND_OPTIONS="-depth -print0"

Preventing Execution as “nobody”

While generally not recommended, if you need to prevent updatedb from running the find command as the “nobody” user, you can modify the /usr/bin/updatedb.findutils script.

Caution: Modifying this script can have security implications. Ensure you understand the risks before proceeding.

  1. Edit the Script: Open /usr/bin/updatedb.findutils with a text editor (e.g., sudo nano /usr/bin/updatedb.findutils).

  2. Remove the su nobody Command: Locate the line that contains su nobody -s /bin/sh -c. Remove the su nobody -s /bin/sh -c part, so that the find command is executed directly by the root user.

  3. Save the Changes: Save the modified script.

Security Considerations: Running find as root increases the potential impact of any vulnerabilities in the find command or the updatedb script. Only perform this modification if you have a strong understanding of the risks and have implemented appropriate security measures.

Addressing Unnecessary Directory Scans: /alex and /amd

You mentioned that you don’t have the /alex and /amd directories on your system, yet the find command is still attempting to scan them. This indicates a potential misconfiguration in the updatedb.conf file or the updatedb.findutils script.

Removing Non-Existent Directories from -prune

  1. Edit /usr/bin/updatedb.findutils: Open the script in a text editor.

  2. Locate the find Command: Find the line containing the find command.

  3. Remove Unnecessary Directories: Remove (^/alex$\)\|\(^/amd$\) from the -regex option. The relevant portion of the command should now look like this:

    -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)'

  4. Save the Changes: Save the modified script.

By removing the non-existent directories from the -prune option, you prevent find from wasting time attempting to scan them.

Analyzing System Logs for Clues

System logs can provide valuable insights into the execution of updatedb and the find command.

Examining Systemd Journal

If updatedb is managed by systemd, use the journalctl command to view its logs:

journalctl -u updatedb.service

This will show you the start and end times of updatedb executions, as well as any error messages or warnings.

Checking Syslog

Examine the syslog file (/var/log/syslog or /var/log/messages) for entries related to updatedb or find. Look for any anomalies or error messages.

grep updatedb /var/log/syslog
grep find /var/log/syslog

Enabling Debugging (Advanced)

If you need more detailed logging, you can enable debugging for updatedb. This typically involves modifying the updatedb.findutils script to add -debug or -v flags to the find command. However, be aware that debugging can generate a large amount of log data.

Alternative Indexing Solutions

If the performance impact of updatedb is unacceptable, consider alternative file indexing solutions that might be more efficient or customizable:

locate Alternatives

While locate relies on the updatedb database, several alternatives offer real-time indexing or more granular control:

  • mlocate: A more secure and efficient implementation of locate. It is often installed by default on Debian.

Specialized Indexing Tools

For more advanced indexing needs, consider tools like:

  • Recoll: A full-text search tool that indexes documents and emails.
  • Tracker: A metadata database, search tool and advanced search library for your desktop.

Conclusion: Regaining Control Over Your System

By systematically investigating the process tree, analyzing configuration files, and examining system logs, we’ve provided a comprehensive approach to understanding and controlling the find command running as “nobody” on your Debian Stretch system. Whether you choose to disable updatedb entirely, modify its configuration, or explore alternative indexing solutions, you now have the knowledge and tools to regain control over your system’s startup behavior and optimize its performance. At revWhiteShadow, we believe in empowering users with in-depth knowledge to troubleshoot and customize their systems effectively. Always remember to back up your configuration files before making any changes, and proceed with caution when modifying system scripts. This ensures you can always revert to a stable state if needed.