We have our librenms environment in a network that needs to go via a proxy to get to internet. ($http_proxy and $https_proxy are set)
Running daily.sh from terminal or through cron works fine. But it doesn’t look like it works with the update through the service.
When logging on I’m welcomed with a notification saying Error: Daily update failed.
Heading into the terminal and running daily.sh as the librenms user makes the notification disappear.
I could of course just add back daily.sh in cron but figured I’d ask 
daily.log shows
…
Updating to latest codebase
fatal: unable to access ‘x://github.com/librenms/librenms.git/’: Could not resolve host: github.com
Returned: 1
Updating Composer packages
[Composer\Downloader\TransportException]
The “x://getcomposer.org/versions” file could not be downloaded: php_network_getaddresses: getaddrinfo failed: Name or service not known
failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known
Enabling updates and running daily.sh manually as librenms user works fine.
The user environment for login isn’t the same as it is for cron.
You need to set the proxy settings in the cron environment.
Tried adding the http_proxy and https_proxy variables in the librenms cron file which I read was possible. Didn’t help though, same issue.
An update here, I noticed the cron update is actually just fine. It’s the “maintenance tasks” that the poller service is attempting which apparently doesn’t work.
Oct 4 02:00:14 localhost librenms-service.py[1330]: maintenance(INFO):Maintenance tasks complete
Oct 4 02:00:14 localhost librenms-service.py[1330]: Updating to latest codebase #033[0;31mFAIL#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: fatal: unable to access ‘https://github.com/librenms/librenms.git/’: Could not resolve host: github.com
Oct 4 02:00:14 localhost librenms-service.py[1330]: Updating Composer packages #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: Updating SQL-Schema #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: Updating submodules #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: Cleaning up DB #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: Fetching notifications #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: Caching PeeringDB data #033[0;32mOK#033[0m
Oct 4 02:00:14 localhost librenms-service.py[1330]: maintenance(INFO):Restarting service…
FYI, it just runs ./daily.sh. So you can run that by hand to see.
I’m guessing your environment isn’t what you are expecting for the service…
That might be the case, but then I don’t understand how manually running daily.sh as the librenms user works.
The service is running as that user:
librenms 1330 1.5 0.0 2580148 23200 ? Ssl Sep13 578:45 /usr/bin/python3 /opt/librenms/librenms-service.py -v
And the cron jobs are obviously working too.
Can I disable the maintenance tasks the service does, as cron apparently does the same things but manages to use the proxy?
@adammmmm were you able to determine if disabling the service updates and enabling cron updates resolved your issue?
I am facing a somewhat similar issue with updates not occurring within our designated maintenance window, so I am hoping to disable the service maintenance/updates and use the ./daily.sh in a cronjob to run during the correct window.
I never attempted to do anything with the service, but the updates all worked fine through cron.
Seemed to finally have figured out what was the problem… systemd.
Adding Environment statements in the systemd librenms.service made it work.
1 Like