I use crontab’s ability to load it’s configuration from file in my deployment scripts. But today it refused to load the configuration due to inability to find the file, despite all permissions were correct for this file. Using stdin (cat $ABSOLUTE_PATH | crontab -) worked correctly, but I was curious why this happens in the first place. Here’s the example of the error (I obviously changed the paths for security reasons):
$ crontab /opt/my_long_path/file.crontab
/opt/my_long_path/file.cron: No such file or directory
At first I was confused with name change and thought that it’s related to filename parsing, like sudo ignores all files with . (dot) in their names in /etc/sudoers.d/. But afterwards I found out that file imports correctly if I invoked crontab from the directory containing the file (using the short relative path). I tried to rename the file short and it worked correctly. So it seemed to be the problem with the long path, so I counted the characters in it:
$ echo "/opt/my_long_path/file.crontab" | wc -m
…and it was exactly three symbols more then 100, and these three symbols we’ve missed (..tab). Seems like crontab doesn’t accept path more then 100 symbols and truncates one if it’s longer then this. I didn’t find an adequate explanation for this behavior, neither operating, nor file system provides such weird restrictions. So we need to whatsoever change file name or use stdin as it’s shown in the beginning of the note.