• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

/etc/cron.daily/60sa-update unexpected operator

Knarf

Basic Pleskian
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE
Parallels Plesk Panel v10.1.1, Ubuntu 10.04 x86_64

PROBLEM DESCRIPTION AND STEPS TO REPRODUCE
This command line:
/etc/cron.daily/60sa-update

generates this error:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator

Also in the daily e-mail I receive this message:
/etc/cron.daily/60sa-update:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator
run-parts: /etc/cron.daily/60sa-update exited with return code 1

ACTUAL RESULT
/etc/cron.daily/60sa-update returning:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator

EXPECTED RESULT
/etc/cron.daily/60sa-update returning no errors

ANY ADDITIONAL INFORMATION
Line 9 and 14 refer to the closing "fi" of the "if" statement, but I could not find anything wrong with "fi".
After searching for possible solutions, I changed #!/bin/sh on line 1 to #!/bin/bash and this seems to work: no errors anymore!
I just don't know why #!/bin/sh isn't working as other scripts have #!/bin/sh as well but they don't produce errors.
 
Last edited:
It is already known problem and should be fixed soon.
 
The error is in the "fi" line because the "if" statement is a single statement which ends on the "fi" line.

The problem is the test condition. "==" is not defined with the "test" or "[" command which is used when shell is /bin/sh.

bash implements its own test/[ command internally which accepts "==" as string comparsion. That's why using bash does not result in a syntax error.

However, this is not really the correct fix. The test should be an arithemetic comparison and not a string comparison. The test is supposed to compare the error code of the command with a number. This the correct way to fix this would be to replace "==" with "-eq" which is the numeric comparison in test/[ and bash.
 
2009 problem started... 05/2011 still active...

Hi,

I have 2 servers, one on Plesk 8.3, and another on Plesk 10, Plesk 10 sends me every single day I receive :

/etc/cron.daily/60sa-update:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator
run-parts: /etc/cron.daily/60sa-update exited with return code 1

From : Cron <root@xxxxxxxxx> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

PLESK 10 on DEBIAN (Linux 2.6.32-22-server)

The problem is not solved yet it seems since january...
 
Last edited:
Hey,

I changed the file /etc/cron.daily/60sa-update so the error is gone, and i added a little comment for extra information.

This is what i have now:



#!/bin/sh

/usr/bin/sa-update
ERR=$?

case $ERR in
0)
echo "Installing updates for SpamAssassin"
/etc/init.d/psa-spamassassin restart | tee -a /var/log/sa-update.log;
echo "Updates successfully installed"
;;
1)
echo "No updates found for SpamAssassin"
exit 0;
;;
esac

exit $ERR
 
I take it this is the best solution until as such time as Parallels offer a permanent fix. My thanks to you Elisy!
 
There is no need to edit that much. All you have to do is to replace the "==" with "-eq". That will make it a numeric comparison.
 
At the time of me writing this, it is February 4, 2012. This thread was started about a year ago, several Plesk updates were issued in this time frame. Yes, fixing this error was extremely simple. But, apparently, it was too challenging for Parallels to just fix this by simply issuing an update. Seriously, this is a shame. Now, of course, this was a small problem that caused some errors but was easy to deal with. But what if, for example, there are any serious security wholes that show up in Plesk? Do they take over a year to be fixed as well? I'm honestly not sure if I should use Plesk in a production environment, where stability and security are more than essential...
 
Back
Top