Question What does ##!PSA!## mean ?

[moswak]

Hi,

Plesk 12.5 latest Updates / Centos 6.8

Crons from a user stopped working.
I see in the file /var/spool/cron/userfile

MAILTO=""
##!PSA!## */1 * * * * /opt/plesk/php/5.6/bin/php -f 'path/to/skript'

what is ##!PSA!## ??

other files looks like
MAILTO=""
*/1 * * * * /opt/plesk/php/5.6/bin/php -f 'path/to/skript'

 

[IgorG]

Looks like some kind of inconsistence in ScheduledTasks table. Check records with

mysql> select * from ScheduledTasks\G

 

[moswak]

I have edited the file /var/spool/cron/userfile manually and then reread the crons from plesk. it seems to be ok now.
mysql> select * from ScheduledTasks\G gives error.
mysql> select * from ScheduledTasks lokks like is ok.

 

[Napsty]

Sorry for jumping on the old train (topic) here. Fortunately it's not that old (Oct 2016).
I experienced the same problem on a Plesk 12.5 server (12.5.30 Update #57). The tasks scheduled in Plesk appear commented-out in the actual crontab files on the system:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontabmX0tZC installed on Thu Jan 19 15:21:07 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
##
##MAILTO=""
##!PSA!##    0    22    *    *    *    php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
##MAILTO=""
##!PSA!##    0    0    1    *    *    php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php

The SQL query @IgorG requested:

MariaDB [(none)]> select * from psa.ScheduledTasks\G
*************************** 1. row ***************************
           id: 1
         hash: 0x5654066670a5044b8672a64dcf31826d
serviceNodeId: 1
    sysUserId: NULL
 sysUserLogin: root
     isActive: 1
         type: exec
 phpHandlerId: NULL
      command: /opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/letsencrypt/scripts/renew-certificates.php'
    arguments:
  description: Extension letsencrypt
       notify: ignore
    emailType: owner
        email:
       minute: 0
         hour: 0
   dayOfMonth: 28
        month: *
    dayOfWeek: *
       period: 2592000
*************************** 2. row ***************************
           id: 47
         hash: 0x0a6bac12f19b3950e65d4232547a65f1
serviceNodeId: 1
    sysUserId: NULL
 sysUserLogin: root
     isActive: 1
         type: exec
 phpHandlerId: NULL
      command: /root/scripts/backup-mysql.sh
    arguments:
  description: NULL
       notify: ignore
    emailType: owner
        email:
       minute: 0
         hour: 1
   dayOfMonth: *
        month: *
    dayOfWeek: *
       period: 86400
*************************** 3. row ***************************
           id: 48
         hash: 0xfb941657ec11e53b11b5c8c714eaf41d
serviceNodeId: 1
    sysUserId: NULL
 sysUserLogin: root
     isActive: 1
         type: exec
 phpHandlerId: NULL
      command: /opt/psa/admin/bin/php -dauto_prepend_file=sdk.php '/opt/psa/admin/plib/modules/plesk-mobile/scripts/push_worker.php'
    arguments:
  description: Extension plesk-mobile
       notify: ignore
    emailType: owner
        email:
       minute: 0,10,20,30,40,50
         hour: *
   dayOfMonth: *
        month: *
    dayOfWeek: *
       period: 0
*************************** 4. row ***************************
           id: 64
         hash: 0x325e82e918044466b019c6cd04923d3a
serviceNodeId: 1
    sysUserId: 91
 sysUserLogin: NULL
     isActive: 1
         type: exec
 phpHandlerId: NULL
      command: php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
    arguments:
  description:
       notify: always
    emailType: default
        email:
       minute: 00
         hour: 22
   dayOfMonth: *
        month: *
    dayOfWeek: *
       period: 86400
*************************** 5. row ***************************
           id: 65
         hash: 0x3c61bd3bd5f9e703dbe06f35379a5528
serviceNodeId: 1
    sysUserId: 91
 sysUserLogin: NULL
     isActive: 1
         type: exec
 phpHandlerId: NULL
      command: php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php
    arguments:
  description:
       notify: always
    emailType: default
        email:
       minute: 00
         hour: 00
   dayOfMonth: 1
        month: *
    dayOfWeek: *
       period: 2592000
5 rows in set (0.00 sec)

The tasks are all active (isActive: 1) so I see no reason why to comment-out the tasks.

To me it looks like there's a problem in the script writing the tasks into the crontab files. Instead of writing "##!PSA!##\n" (newline!), the "##!PSA!##" is written on the same line prior to the minute field.

 

[Bitpalast]

To me it looks like there's a problem in the script writing the tasks into the crontab files. Instead of writing "##!PSA!##\n" (newline!), the "##!PSA!##" is written on the same line prior to the minute field.

No, there is no error in that function. Inactive crontab jobs in 12.5.30 and Onyx are preceded by ##, not ##!PSA!## in their corresponding /var/spool/cron/* files.

The ##!PSA!## is caused by a deny command when crontabmng is run, for instance:

/usr/local/psa/admin/sbin/crontabmng deny USERNAME

The deny parameter stops execution of crontab commands of a specific user account. This is needed for the case that a subscription is suspended by the administrator. In that case sw-engine runs crontabmng with the deny USERNAME command to suspend crontab execution of that user. It is not a bug, it is a feature.

So if your crontab user file has the ##!PSA!## preceding the cron entries, it only means that a subscription was suspended/deactivated. You can simply either reactivate the subscription or manually run

/usr/local/psa/admin/sbin/crontabmng allow USERNAME

to activate the cronjobs of that subscription (even if the subscription remains suspended).

 

[Napsty]

Hi Peter

Thanks for your suggestion. The account in question is neither suspended or disabled. So I don't know why Plesk added the ##!PSA!## comment in front of the cron job.

According to your advise, I ran the command anyway to tell Plesk that the cron jobs are allowed for this user:

# /usr/local/psa/admin/sbin/crontabmng allow web98

Then I created a new scheduled task in Plesk. It again appeared as commented in the crontab file!

# cat /var/spool/cron/crontabs/web98
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontabLsgIwW installed on Sat Jan 21 09:13:41 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
##
MAILTO=""
##!PSA!##   0   0   *   *   *   whoami
##MAILTO=""
0   22   *   *   *   php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
##MAILTO=""
0   0   1   *   *   php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php

At least the older two cron entries didn't get commented-out, but there's a problem when adding new scheduled tasks through Plesk!

Please advise.

 

[Bitpalast]

You can try to repair the inconsistencies that seem to exist in your database.

1) Backup your server content and configuration.

On console with root privileges:
2) # plesk repair db -y

Then in GUI:
3) Suspend affected user account.
4) Activate user account.
5) Suspend affected subscription.
6) Activate subscription.
7) Suspend affected domain.
8) Activate domain.

 

[Napsty]

Sorry but before I do anything on a production server and suspend a paying customer (even for just a couple of seconds) please tell me where do you see inconsistencies?
As you can see in the mysql output, there are no inconsistencies. Where would I check for these before blindly launching the plesk repair db command?

 

[Bitpalast]

I understand that you feel uncomfortable, but how can anyone know why some awkward setting on your system is causing the comment before the crontab entry? After all, you are the one who has full access to your system and Plesk database.

You have only been looking at the ScheduledTasks table. However, there are many more tables like clients, subscriptions, domains and related tables. An inactive scheduled task leads to a "##" comment. An suspended subscription or user leads to a "##!PSA!##" comment. I think so far you did not check for inconsistencies on other tables, therefor I did suggest to do that. If you feel uncomfortable with using plesk repair utitiliy or toggling accounts, you have more options:

a) Create an additional user and subscription, reproduce the error with it and do the tests on that user, not on your productive user account.
b) Go through all processes on your system manually and check whether everything is fine, then go through all the data tables in Plesk database and check for issuses manually. If you identify inconsistencies, resolve them manually.
c) Open a support ticket with Plesk support and let them do it for you.

 

[Napsty]

Hello Peter,

Appreciate you taking the time.

I saw that there is a "dry run" of plesk repair where I was able to see some details.
There was one warning which the command seemed to solve:

#  plesk repair db -y

Checking the Plesk database using the native database server tools .. [OK]

Checking the structure of the Plesk database ........................ [OK]

Checking the consistency of the Plesk database

  Inconsistency in the table 'smb_users' for the column               
  subscriptionDomainId: No rows in the table 'domains' with id = -1   
  (170 broken references) ........................................... [WARNING]
  To see more details, run the command in the verbose mode: plesk repair db -verbose
    Creating a database dump ........................................ [OK]
    A dump of the database was created before an attempt to repair the database: /var/lib/psa/dumps/mysql.preresolve.20170121-163627.dump.gz
    Fixing broken references ........................................ [FIXED]

Error messages: 0; Warnings: 1; Errors resolved: 1

I then created a new scheduled task but the comment was still added:

# cat /var/spool/cron/crontabs/web98
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontabqYyNZ2 installed on Sat Jan 21 16:39:55 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
##
MAILTO=""
##!PSA!##   0   2   *   *   *   whoami
##MAILTO=""
0   22   *   *   *   php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
##MAILTO=""
0   0   1   *   *   php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php

Then I did the steps you mention with the suspend and reactivate the user, subscription and domain.
The previous cronjob (whoami) was now enabled:

# cat /var/spool/cron/crontabs/web98
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Sat Jan 21 16:41:17 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
##
MAILTO=""
   0   2   *   *   *   whoami
##MAILTO=""
0   22   *   *   *   php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
##MAILTO=""
0   0   1   *   *   php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php

Then I added another new cron job and it was again disabled with the ##!PSA!## comment:

# cat /var/spool/cron/crontabs/web98
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (crontabFu7bwT installed on Sat Jan 21 16:43:01 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
##
MAILTO=""
##!PSA!##   0   2   *   *   *   id
##MAILTO=""
0   0   1   *   *   php -q -d safe_mode=Off //var/www/vhosts/web98.area-1.ch/files/update.php
##MAILTO=""
0   22   *   *   *   php -q -d safe_mode=Off /var/www/vhosts/web98.area-1.ch/files/store_file.php
MAILTO=""
0   2   *   *   *   whoami

I tested this on another account as well but there the added scheduled task seemed fine (no ##!PSA!## added).

 

[Bitpalast]

As we got that far, I think the remaining bit is a job for Plesk support. Assuming that the settings of web98 account are all "active" (or similar) and seeing that all other things seem to work, it remains unclear why new cronjobs in exactly one account are commented out while others are not. Not possible for me to guess why that can still be the case. This needs an in-depth investigation on the server.

 

[Napsty]

Thank you Peter. I opened a support ticket.

 

[Napsty]

I just want to follow-up after the Plesk support found the solution. The affected customer has several domains. One of these domains were suspended/disabled. It seems that this domain was somehow the primary domain - therefore the scheduled tasks were added with the ##!PSA!## comment.

Peter, your description and troubleshooting steps were correct, I simply overlooked the other domain (which is not in use by the customer). Thank you.