OS: Solaris 10 , update 11
HW: M5-32 LDOM, V490, IBM x3650, T5240, VMware virtual machine, etc...
tmp directory=/var/tmp
cron shell=/sbin/sh
My shell=/bin/bash


A very interesting error occurs when attempting to modify the crontab via crontab -e.

If I attempt to search for a non-existent string utilizing crontab -e to verify and check syntax with vi as my editor, and then try and save, it will puke back and tell me an error has occurred even if no changes were made.


admin@server# export EDITOR=vi
admin@server# crontab -e

In command mode, search for a non-existent string like "foobar123". After receiving the "Pattern not found" then attempt to :wq and you'll receive...

The editor indicates that an error occurred while you were
    editing the crontab data - usually a minor typing error.

    Edit again, to ensure crontab information is intact (y/n)?
    ('n' will discard edits.)

If you are cheeky and choose to go right back in and attempt to save it will now save sans error. This is repeatable from on all types of Solaris from VMware to M5-32 LDOM, to a V490 physical. Curious as to why cron would interpret a search for a non-existent string as an error, but not say visudo.

A related note is Solaris 11 will not produce this error, which then begs the question if this is some sort of POSIX specification why it would apply to Solaris 10 and not 11?

  • What happens if you don't do anything in the editor (that is, don't search for any strings) and instead immediately :wq? What happens if you use a different EDITOR besides vi? I'm thinking that vi has a tendency to add a newline to the end of the file if there isn't one already, and this might somehow be the source of your issue. – jayhendren Nov 28 '16 at 18:43
  • Oh, I guess I missed part of your question. It appears that the newline at the end of the crontab file is not an issue. I have a Solaris 10 box handy; I'll see if I can reproduce the issue. – jayhendren Nov 28 '16 at 18:46
  • Sadly we only have vi and ed on our Solaris boxes. There is no vim, emacs, pico, etc... so it's been hard to verify if vi is the real problem child here. If I search for nothing and save, it will save without producing any error. Whether you make edits or don't doesn't affect it saving correctly until you attempt that non-existent search. A search for an existing string and then :wq will also save correctly. EDIT: Just saw that vi is a link to vim on Solaris 11 which would tend to support a vi specific issue. Tried on about 20 systems so far all with the same result. – Sending_Grounds Nov 28 '16 at 18:49
  • I am able to reproduce on Solaris 10. I'm poking into this a little bit here and there but I don't have much free time today. I'll let you know if I find anything. – jayhendren Nov 28 '16 at 19:14
  • Thanks! If nothing else, nice to know it's not just our environment to help limit the factors of searching into. – Sending_Grounds Nov 28 '16 at 19:16

Not having the source to Solaris 10 or Solaris 11, I can't say for sure, but I suspect that Thomas Dickey is on the right track, based on his findings with vim.

I tracked down the IllumOS source where a search for errcnt in the ex/vi directory shows that errcnt is only ever incremented, and errcnt is used as the return code from main().

Thus, any failure that increments errcnt in vi will "bubble up" to the crontab command, where the IllumOS source for crontab indicates that it will be unhappy with anything other than zero.

Notice also the comment in crontab.c!

311             ret = system(buf);
327             if ((ret) && (errno != EINTR)) {
328                 /*
329                  * Some editors (like 'vi') can return
330                  * a non-zero exit status even though
331                  * everything is okay. Need to check.
332                  */
| improve this answer | |
  • That's one of the best comments in code I've seen in a while. Ha! "Hey I'm not sure if this is going to cause issues, even though nothing is wrong... someone should probably check it out. Someone whose not me, that is." Perfect; combined with the above about vi equaling a sym link to vim on Solaris 11, and your explanation on sudoers doing it's own syntax checking... I think this closes the case. – Sending_Grounds Dec 1 '16 at 13:25

OS: Solaris 10 , update 11 HW: LDOM, VMware virtual machine, etc... EDITOR=vi term=vt100

My observations in the behavior of vi and crontab is similar to the above. Crontab -e giving the error "The editor indicates that an error occurred while you were editing the crontab data ....."

and you have no choice but to either edit again and again...or throw away the changes. And using vi editor to make changes to any file and trying to save will only throw the changes away. I think vi is the culprit for crontab's behavior as well. I have now a wrapper script for vi to force it to exit with a zero exit status so vi can save the changes to the edited files. And I redirect crontab contents to a file and edit the changes in the file and redirect it back to crontab. A little painful and annoying but works until we get to solaris 11.NK

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.