I have a couple of servers running netdata that are built with cPanel applied on top. These have netdata version 1.43.0-124-nightly on them. Neither is displayed the “Web Server Logs” nor the systemd-journal logs. I have checked the config files for the web logs are pointing to the right log. Does the netdata user need any specific access? Given the logs are there, I’m wondering if there is a simple access issue based upon how the server was built.
The linux version is: Ubuntu 20.04.5 LTS
Hi @Reece_James ,
For the Web Server Logs have you tried the troubleshooting instructions?
systemd journal logs please check our plugin availability details, at a first glance you seem to meet the criteria but please check. If you also think so then please open a bug adding more details for your case.
Many thanks for the reply Hugo.
Yes, I’ve tried the debug on the Web Server Logs. It stops stating the file can not be found though I can tail it and see it, hence wondering if there is any access the netdata user needs. Do I need to update the ACL?
[ DEBUG ] job[manager] manager.go:262 creating web_log[apache] job, config: map[provider:file reader source:/etc/netdata/go.d/web_log.conf autodetection_retry:0 module:web_log name:apache path:/var/log/apache2/access.log priority:70000 update_every:1]
[ DEBUG ] web_log[apache] init.go:33 skipping URL patterns creating, no patterns provided
[ DEBUG ] web_log[apache] init.go:51 skipping custom fields creating, no custom fields provided
[ DEBUG ] web_log[apache] init.go:76 skipping custom time fields creating, no custom time fields provided
[ DEBUG ] web_log[apache] init.go:95 no custom time fields provided
[ DEBUG ] web_log[apache] init.go:140 starting log reader creating
[ DEBUG ] web_log[apache] reader.go:70 couldn’t find log file, used path: ‘/var/log/apache2/access.log’, exclude_path: ‘*.gz’
[ WARN ] web_log[apache] weblog.go:124 check failed: creating log reader: no matched files
[ ERROR ] web_log[apache] job.go:204 check failed
REPORT_JOB_STATUS ‘web_log’ ‘apache_17048603331267002639’ ‘error’ 0 ‘job detection failed, stopping it’
Further update. If I tail the file I get:
tail: cannot open ‘/var/log/apache2/access.log’ for reading: No such file or directory
However, if I enter the directory I can see the file and tail it.
/var/log/apache2# tail access_log
127.0.0.1 - - [08/Nov/2023:07:34:07 +0000] “GET /server-status?auto HTTP/1.1” 200 752 “-” “Go-http-client/1.1”
All of this is under root access. Hence my question is whether this is an access issue.
Yes, it seems a permission access.
Was able to find this bug report [Bug]: web_log plugin should be able to read a file with global read access · Issue #13246 · netdata/netdata · GitHub on it.
The solution was:
It needed the following as well
sudo chmod +rx /var/log/apache2
Thanks Hugo, that’s great, I’m not going mad and yes the symptoms are exactly the same. One snag. When I get to the chmod, I need the netdata password:
netdata@raphael:/root$ sudo chmod +rx /var/log/apache2
[sudo] password for netdata:
Naturally, I don’t have that so a little further forward. netdata account was naturally setup as part of the original install. Any further ideas?
Unfortunately no further ideas, let’s see if @Manolis_Vasilakis or @ilyam8 can help here
I think most of the logs in /var/log/ are readable by
adm group members. Our installer should add
adm, you can if check it using
$ id netdata
uid=997(netdata) gid=996(netdata) groups=996(netdata),4(adm),13(proxy),33(www-data),64045(ceph),997(docker)
If you need to add manually
sudo gpasswd -a netdata adm
Thank you for the update.
When I enter “id netdata” I receive a different response
uid=981(netdata) gid=979(netdata) groups=4(adm),13(proxy),99(nobody),979(netdata)
I have added to the admin group
sudo gpasswd -a netdata adm
Adding user netdata to group adm
Restarted, just in case netdata health monitor, just in case.
Still have an access issue.
netdata@xxxxxxxxx:/usr/libexec/netdata/plugins.d$ tail /var/log/apache2/access.log
tail: cannot open ‘/var/log/apache2/access.log’ for reading: Permission denied
Any further ideas?
Check the directory and log files ownership and permissions.