inotifywait.pid not readable

[sanjaynarayan]

maldet wont start after installation in CentOS7

● maldet.service - Linux Malware Detect monitoring - maldet
Loaded: loaded (/usr/lib/systemd/system/maldet.service; enabled; vendor preset: disabled)
Active: failed (Result: resources) since Mon 2018-10-01 09:08:02 IST; 44min ago

Oct 01 09:08:00 [fqdn] systemd[1]: Starting Linux Malware Detect monitoring - maldet...
Oct 01 09:08:02 [fqdn] maldet[1733]: Linux Malware Detect v1.6.3
Oct 01 09:08:02 [fqdn] maldet[1733]: (C) 2002-2018, R-fx Networks [email protected]
Oct 01 09:08:02 [fqdn] maldet[1733]: (C) 2018, Ryan MacDonald [email protected]
Oct 01 09:08:02 [fqdn] maldet[1733]: This program may be freely redistributed under the terms of the GNU GPL v2
Oct 01 09:08:02 [fqdn] maldet[1733]: maldet(1733): invalid usage of -m|--monitor, aborting.
Oct 01 09:08:02 [fqdn] systemd[1]: PID file /usr/local/maldetect/tmp/inotifywait.pid not readable (yet?) after start.
Oct 01 09:08:02 [fqdn] systemd[1]: Failed to start Linux Malware Detect monitoring - maldet.
Oct 01 09:08:02 [fqdn] systemd[1]: Unit maldet.service entered failed state.
Oct 01 09:08:02 [fqdn] systemd[1]: maldet.service failed.

[sanjaynarayan]

Can someone let me know how to resolve this issue??

[sanjaynarayan]

Just an update. Maldet can be started manually after executing "maldet -m users"
But everytime the server is restarted or after sometime I have to execute the command again. It gives the same error "inotifywait.pid not readable (yet?) after start"

How can this be fixed?

[rfxn]

Appreciate the feedback. Will look into this issue as soon as possible.

Thanks

[joelkrueger]

I am seeing this issue as well. I also confirm that maldet can be started manually after boot with "maldet -m users". This is on CentOS Linux release 7.5.1804 (Core), Linux Malware Detect v1.6.3, inotify-tools.x86_64 3.14-8.el7.

[YipYup]

Using v1.6.3 here. I think the output from the PID file is actually a symptom, and not the cause. Looking into it more, it seems that at least for me, there is a bug in the systemctl script that was installed on my CentOS 7 (x86-64) cPanel / WHM (latest: current).

@rfxn The systemd service file is passing a variable that has not been defined, $default_monitor_mode, and appears to be causing the crash. So instead of the program launching with the correct switch, it is using the variable placeholder literally instead.

Process: 4641 ExecStart=/usr/local/maldetect/maldet --monitor $default_monitor_mode

Bad: $default_monitor_mode

# systemctl status maldet.service
● maldet.service - Linux Malware Detect monitoring - maldet
   Loaded: loaded (/usr/lib/systemd/system/maldet.service; enabled; vendor preset: disabled)
   Active: failed (Result: resources) since Sun 2018-12-02 10:18:45 MST; 4s ago
  Process: 4641 ExecStart=/usr/local/maldetect/maldet --monitor $default_monitor_mode (code=exited, status=0/SUCCESS)

To resolve it, I did the following:

Stop the service from running and trying to restart.

systemctl stop maldet

I then edited /usr/lib/systemd/system/maldet.service and replaced the line

ExecStart=/usr/local/maldetect/maldet --monitor $default_monitor_mode

with

ExecStart=/usr/local/maldetect/maldet --monitor USERS

And let systemd know of the updated config file with

systemctl daemon-reload

Now I started the service (which took a few seconds):

systemctl start maldet.service

And then checked it was still running and not crashing...

systemctl status maldet.service

[root@host ~]# systemctl status maldet.service
● maldet.service - Linux Malware Detect monitoring - maldet
   Loaded: loaded (/usr/lib/systemd/system/maldet.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2018-12-02 10:28:20 MST; 5min ago
  Process: 5779 ExecStart=/usr/local/maldetect/maldet --monitor USERS (code=exited, status=0/SUCCESS)

We see the service is running...
Active: active (running) -- so we are good!

[rfxn]

@YipYup Thank you for the very thorough assessment. I've committed a change to always set a default value for default_monitor_mode in conf.maldet which should take care of the issue. On upgrades, conf.maldet values from the installer package are inherited if a local variable is unset. When 1.6.4 rolls out, this should take care of this issue.

Thanks

[CybernetiX-S3C]

I have tried this method on my Kali Linux. Yet, no difference.

╰─○ systemctl status maldet
● maldet.service - Linux Malware Detect monitoring - maldet
Loaded: loaded (/usr/lib/systemd/system/maldet.service; disabled; vendor preset: disabled)
Active: failed (Result: protocol) since Sun 2020-11-01 14:49:20 EST; 1min 25s ago
Process: 54333 ExecStart=/usr/local/maldetect/maldet --monitor USERS (code=exited, status=0/SUCCESS)

Nov 01 14:49:20 CybernetiX-S3C systemd[1]: Starting Linux Malware Detect monitoring - maldet...
Nov 01 14:49:20 CybernetiX-S3C maldet[54387]: /usr/bin/dig: parse of /etc/resolv.conf failed
Nov 01 14:49:20 CybernetiX-S3C maldet[54333]: Linux Malware Detect v1.6.4
Nov 01 14:49:20 CybernetiX-S3C maldet[54333]: (C) 2002-2019, R-fx Networks [email protected]
Nov 01 14:49:20 CybernetiX-S3C maldet[54333]: (C) 2019, Ryan MacDonald [email protected]
Nov 01 14:49:20 CybernetiX-S3C maldet[54333]: This program may be freely redistributed under the terms of the GNU GPL v2
Nov 01 14:49:20 CybernetiX-S3C maldet[54333]: maldet(54333): {mon} kernel does not support inotify(), aborting.
Nov 01 14:49:20 CybernetiX-S3C systemd[1]: maldet.service: Can't open PID file /usr/local/maldetect/tmp/inotifywait.pid (yet?) after start: Operation not permitted
Nov 01 14:49:20 CybernetiX-S3C systemd[1]: maldet.service: Failed with result 'protocol'.
Nov 01 14:49:20 CybernetiX-S3C systemd[1]: Failed to start Linux Malware Detect monitoring - maldet.
/0.2s

╰─○ uname -a
Linux CybernetiX-S3C 5.8.0-kali3-amd64 #1 SMP Debian 5.8.14-1kali1 (2020-10-13) x86_64 GNU/Linux