Problems with cron/discovery after compose down/up or pull

[Scott8586]

I need some help understanding how periodic discovery is managed under a docker installation.

At some point in the distant past, discovery stopped working for me (stopped running, even when triggered from the UI). manual discovery within the container works: e.g. ./discovery.php -h <id>. After some reading, I tried the following:

Entered the running container with docker exec -it librenms bash, and tried adding the following to my librenms user crontab, via crontab -e

33   */6  * * *       /opt/librenms/cronic /opt/librenms/discovery-wrapper.py 1
*/5  *    * * *       /opt/librenms/discovery.php -h new >> /dev/null 2>&1

That would work for a while, but if I ever down/up’d the container, or did a pull, my changes would get stomped on, and I’d end up with just the basic:

15 0 * * * cd /opt/librenms/ && bash daily.sh
* * * * * php /opt/librenms/artisan schedule:run --no-ansi --no-interaction > /dev/null 2>&1

In addition, after each docker pull, I am presented with:

/opt/librenms $ crontab -l
crontab: must be suid to work properly

so, as root, I:

chmod +s /usr/bin/crontab

but since that’s a link to busybox, I’m not sure if that’s the best thing to do…

My questions are:

1. How is discovery supposed to be run - through cron? or as a service?, or?..

2. Where is cron supposed to be edited/run, as crontab -e (which use /var/spool/cron/, or by hand in /etc/crontabs or somewhere else - so that it survives a pull, and a down/up?

/opt/librenms $ ./validate.php 
===========================================
Component | Version
--------- | -------
LibreNMS  | 25.7.0 (2025-07-24T08:04:52-07:00)
DB Schema | 2025_07_29_025425_hr_device_table_add_type_default (351)
PHP       | 8.3.23
Python    | 3.12.11
Database  | MariaDB 10.4.34-MariaDB-1:10.4.34+maria~ubu2004
RRDTool   | 1.9.0
SNMP      | 5.9.4
===========================================

[OK]    Installed from the official Docker image; no Composer required
[OK]    Database Connected
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQL and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    No python wrapper pollers found
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok
[WARN]  Updates are managed through the official Docker image

Additional info:

/etc/crontabs/root:

# do daily/weekly/monthly maintenance
# min	hour	day	month	weekday	command
*/15	*	*	*	*	run-parts /etc/periodic/15min
0	*	*	*	*	run-parts /etc/periodic/hourly
0	2	*	*	*	run-parts /etc/periodic/daily
0	3	*	*	6	run-parts /etc/periodic/weekly
0	5	1	*	*	run-parts /etc/periodic/monthly

As root, crontab -l returns empty, /etc/cron.d does not exist.

[slashdoom]

Assuming that you’re using the Docker compose that you get from following the docs (Docker - LibreNMS Docs), it shouldn’t be using cron.

With the compose file, you should have an container called librenms that mainly acts as the WebUI. You should then have a separate container called dispatcher. This does the polling and discovery; the docker scripts basically set it up with the Dispatcher Service.

If the dispatcher container is running properly, it should show up in the WebUI under pollers as dispatcher1. I would check docker compose logs for that dispatcher container to see if it’s actually trying to poll/discover your devices.

[Scott8586]

Thanks - I found it. For some reason discovery was turned off? Now that it’s on in the WebUI settings, it seems to be working correctly.