Score:0

crontab returns usage error: only one operation permitted

ru flag

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?

hr flag
Do you have `crontab` aliased? what does `type crontab` say?
S. Nixon avatar
ru flag
That was it. Thx steeldriver. I never even thought of looking for that.
Score:1
ru flag

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:

alias crontab='crontab -l'

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.

$ crontab -l -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)

Thanks for the advice as to a place to look for the weird behavior.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.