cron jobs can fail for a surprising number of reasons, and when tcpdump is involved, the reasons often compound.
The most common failure is that cron doesn’t inherit your interactive shell’s environment, meaning PATH is minimal and variables like SSH_AUTH_SOCK or LD_LIBRARY_PATH are missing.
Cause 1: Missing PATH entries.
Diagnosis: In your crontab, try running which tcpdump. If it returns nothing, cron can’t find the tcpdump executable.
Fix: Prepend the full path to tcpdump in your cron command. If tcpdump is at /usr/sbin/tcpdump, your command should look like /usr/sbin/tcpdump .... This works because it bypasses cron’s restricted PATH.
Cause 2: Permissions issues for the capture file.
Diagnosis: Check if the user running the cron job has write permissions to the directory where tcpdump is configured to save files. ls -ld /path/to/capture/directory should show the correct ownership and permissions.
Fix: Ensure the user has write permissions to the directory. For example, if the cron job runs as user sysadmin and captures to /var/log/captures, run sudo chown sysadmin:sysadmin /var/log/captures and sudo chmod u+w /var/log/captures. This grants the user the ability to create files in that location.
Cause 3: cron user doesn’t have CAP_NET_RAW or CAP_NET_ADMIN capabilities.
Diagnosis: tcpdump requires elevated privileges to capture raw network packets. If the cron user lacks these, the capture will fail silently or with a permission denied error. You can check capabilities with getcap $(which tcpdump).
Fix: Grant the necessary capabilities to the tcpdump executable for the user running the cron job. For example, if cron runs as nobody and tcpdump is at /usr/sbin/tcpdump, run sudo setcap cap_net_raw,cap_net_admin+ep /usr/sbin/tcpdump and ensure your cron job runs as a user that has these capabilities (often root or a user in a specific group that inherits them). This explicitly allows the tcpdump binary to perform network capture operations without needing to run the entire cron job as root.
Cause 4: cron job runs before network interfaces are fully up.
Diagnosis: If your cron job is scheduled to run immediately at system startup (e.g., @reboot), the network interfaces might not be fully initialized. tcpdump will then fail to bind to the interface.
Fix: Add a delay to your @reboot cron job. For instance, sudo crontab -e and use @reboot sleep 60 && /usr/sbin/tcpdump ... to wait 60 seconds after boot before starting the capture. This ensures network interfaces are ready to be captured from.
Cause 5: Output redirection issues or full disk.
Diagnosis: tcpdump writes to a file. If the target filesystem is full, or if there’s an issue with the redirection (>), tcpdump will fail. Check disk space with df -h.
Fix: Ensure adequate free space on the partition where capture files are being written. Also, verify the redirection is correct. A common pattern is tcpdump -w /var/log/captures/capture_$(date +\%Y\%m\%d_\%H\%M\%S).pcap -G 3600 -W 24 -Z root. This rotates files every hour for 24 hours and writes as root, ensuring permissions and space are managed.
Cause 6: tcpdump command-line syntax errors or missing arguments.
Diagnosis: A typo in the tcpdump command within the crontab, or missing critical arguments like the interface (-i) or output file (-w), will cause the job to fail.
Fix: Carefully review the tcpdump command in your crontab. Ensure all necessary options are present and correctly spelled. For example, a robust command for hourly capture rotated daily might be 0 * * * * /usr/sbin/tcpdump -i eth0 -s 0 -w /var/log/captures/capture-$(date +\%Y\%m\%d).pcap -G 3600 -Z root. This captures all traffic on eth0, without truncation, hourly, to a file named with the date, rotating every hour, and changing ownership to root for easier management.
The next error you’ll likely encounter is No such file or directory if you’ve accidentally specified a non-existent directory for your capture files or if the tcpdump binary itself is missing from the PATH in the cron environment.