Our local school is running Rocky Linux 8 on all servers and desktop clients. A few weeks ago we purchased a new Canon printer, which I setup on four of the desktop clients. The printer works perfectly, but I just stumbled upon a nasty side effect.
One of the teachers phoned me and told me that her disk was full. I connected remotely to the machine and saw indeed that
/var/tmp was full with mysterious files belonging to the
lp user and corresponding system group, each one with a size of 94 MB:
-rw-------. 1 lp lp 94M Dec 6 16:03 cnijrawtmp4LpW4s
-rw-------. 1 lp lp 94M Dec 6 14:00 cnijrawtmpDDpqwO
-rw-------. 1 lp lp 94M Dec 6 13:59 cnijrawtmpGdnN0g
-rw-------. 1 lp lp 94M Dec 6 12:12 cnijrawtmpNjUsSJ
-rw-------. 1 lp lp 94M Dec 6 14:00 cnijrawtmpP0XyRw
-rw-------. 1 lp lp 94M Dec 6 12:09 cnijrawtmpUyA4uC
-rw-------. 1 lp lp 94M Nov 29 11:41 cnijrawtmpVNRf8x
I manually wiped that stuff (
rm -f /var/tmp/cnij*), which solved the problem. And now I wonder if one of you guys has already encountered this kind of weird behavior. What would be a sane approach to solve this? Setup a cron job to wipe that stuff on reboot? Wipe the whole of
A quick search reveals that this is a quite old and known bug with Canon drivers, see Bug #1589015 “Printer bug adds cnij* into /var/tmp endlessly” : Bugs : cjet package : Ubuntu and Maxify MB2320 and driver - Canon Community
This seems to be a long standing bug as we find several people reporting the same issue with various canon printers over the years.
After more than 7 years, it seems safe to assume canon does not care and will not fix this bug any time soon. So better to not count on it and set up a fix by yourself.
It is recommended that /var is given its own partition to prevent this kind of issue from affecting the whole system by making / run out of space.
I would recommend to NOT wipe the whole /var/tmp directory as its purpose is to hold temporary files that should be preserved between reboots. So wiping is may cause some unexpected issues with other process or software, is a bit overkill as is not necessary.
Only deleting the cnijrawtmp* files is enough to fix this issue.
Using the reboot as a trigger for deletion could work but might be suboptimal depending on the frequency of reboots and how fast the cnijrawtmp* files fill the partition. Choose at your own discretion the appropriate trigger, but imho a fixed period of time is probably better than at boot.
I found a simple and clean fix for it and wrote a little blog article:
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.