I have two PCs running Ubuntu 18.04 LTS. They were created from the same linux base image. Recently I discovered that on one of the two boxes, I am unable to use crontab to view or edit the individual user cron tables.
ServerB is giving this error as any user, including root:
$ crontab -l
crontab: usage error: only one operation permitted
usage: crontab [-u user] file
crontab [ -u user ] [ -i ] { -e | -l | -r }
(default operation is replace, per 1003.2)
-e (edit user's crontab)
-l (list user's crontab)
-r (delete user's crontab)
-i (prompt before deleting user's crontab)
I thought at first that a running process may have the cron locked, but the problem persisted after a full reboot of the server.
Researching this online only indicates that some admins have chosen to recompile crontab to eliminate the "remove" flag. That was NOT the case here. This crontab command came with the O/S and is identical to the one on the working server.
There are also no messages in the /var/log/syslog
or in /var/log/cron.log
to show why it may be failing. crontab -e
or crontab -l
both return the error above.
This is the /usr/bin/crontab from both the working and problem servers. Identical dates and sizes.
-rwxr-sr-x 1 root crontab 39352 Nov 16 2017 /usr/bin/crontab
-rwxr-sr-x 1 root crontab 39352 Nov 16 2017 /usr/bin/crontab
$ diff -s crontab.serverA crontab.serverB
Files crontab.serverA and crontab.serverB are identical
Finally, permissions and ownerships are identical on both servers for the /var/spool/cron
path and files.
I could just add any entries to the /etc/crontab file for the selected user, but just trying to understand why this error is appearing in the first place. Is there some sort of lock file left behind somewhere that could cause this?
Thanks to @steeldriver for the comment about looking at the alias settings, I was able to discover that someone had added this line to the /etc/profile:
Some of our operators like to make shortcuts (such as alias df='df -h') and this was definitely a new one for me as we have never used that alias before. Sure enough, removing the alias fixed the issue. I also confirmed that if you repeat the same flag twice, that is what triggers the error message and the usage display.
Thanks for the advice as to a place to look for the weird behavior.