We help IT Professionals succeed at work.

How to monitor char file permission using monit

Balbir Singh
Balbir Singh asked
I am wondering how can we monitor the permission on char file using monit application

I have below char file


and below monitrc config

check file dev_null with path /dev/null
if failed permission 666 then exec "chmod 666 /dev/null" as uid root and gid wheel

But it doesn't seems to work when file /dev/null has permission 600

I really appreciate any help on that.
Watch Question

Distinguished Expert 2017

/dev/null is in short considered a trash bin.
anything sent here is discarded.

not sure I understand what you are asking /dev/null is a "system device"

It should not be changing permissions.
Balbir SinghSystem Administrator


Hi Arnold,

I have observed that file permission on /dev/null keeps on changing and I guess it is due to some package or process which cause issue to my other application which needs write permission to trash few things. So I want to monitor its permission using monit and if it is not there then correct the permission.

Please let me know if you have any recommendation on how to do it.

Best Regards!
Distinguished Expert 2017

you should double check what cron jobs you have or scripts that run chmod on /dev/null
I do not believe there is any system level task, or mechanism that will be doing that.

not sure monit is in a position to monitor a character device.  usually I think monit can monitor fles or folders.

if you have this issue, setup a cron under root to run every minute to issue the chmod 666 /dev/null
* * * * * chmod 666 /dev/null >/dev/null

also not sure which linux system you have, but ownership of /dev/null should commonly be by root with root or other as the group.
Fractional CTO
Distinguished Expert 2018
Ah the old /dev/null 600 problem.

I prefer using incron, as incron is standard on all Distros + works all the time.

Might be you can use monit + same logic below applies.

Since many /dev/* files are involved when /dev/null resets to 600, you must fix them all. Just fixing /dev/null is insufficient.

https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1846367 covers /dev/* file resetting to 600 problem.

I opened this upstream ticket many months ago.

It's not just /dev/null. If you check carefully, it's many /dev/* files.

The problem has not been identified yet.

There are 2x known fixes.

1) Reboot.

2) Repair the problem in realtime using this sequence.

a) Create a repair scripts. Likely best to do this for all machines anyway...

find /etc /usr /bin /sbin -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > ~/restore-perms-all.sh
find /dev -exec stat --format "chmod %a \"${MPOINT}%n\"" {} \; > ~/restore-perms-dev.sh
chmod +x ~/restore*.sh

Open in new window

b) Create an incron job that checks to ensure /dev/null permission set to 666.

c) Anytime /dev/null permissions sets to any other value, run the ~/restore-perms-dev.sh script to reset all /dev/* files permissions.

Note: Far better to use either incron or a custom inotifywait script, because if you run a CRON job, you'll have some number of minutes where you're machine may crash.

With an incron job, only a few milliseconds will pass while all /dev/* file permissions are wrong.