1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

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

Discussion in 'Plesk 12.x for Linux' started by moswak, Oct 12, 2016.

  1. moswak

    moswak Basic Pleskian

    14
    60%
    Joined:
    Jul 1, 2015
    Messages:
    95
    Likes Received:
    5
    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'

     
  2. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,385
    Likes Received:
    1,213
    Location:
    Novosibirsk, Russia
    Affiliate:
    https://plesk.com/?a_aid=59ae552b0731c
    Looks like some kind of inconsistence in ScheduledTasks table. Check records with

    mysql> select * from ScheduledTasks\G
     
  3. moswak

    moswak Basic Pleskian

    14
    60%
    Joined:
    Jul 1, 2015
    Messages:
    95
    Likes Received:
    5
    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.
     
  4. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    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:

    Code:
    # 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:

    Code:
    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.
     
  5. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    37
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,902
    Likes Received:
    391
    Location:
    Berlin, Germany
    Best Answer
    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:
    Code:
    /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
    Code:
    /usr/local/psa/admin/sbin/crontabmng allow USERNAME
    to activate the cronjobs of that subscription (even if the subscription remains suspended).
     
    Napsty likes this.
  6. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    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:

    Code:
    # /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!

    Code:
    # 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.
     
  7. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    37
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,902
    Likes Received:
    391
    Location:
    Berlin, Germany
    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.
     
  8. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    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?
     
  9. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    37
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,902
    Likes Received:
    391
    Location:
    Berlin, Germany
    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.
     
  10. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    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:

    Code:
    #  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:

    Code:
    # 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:

    Code:
    # 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:

    Code:
    # 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).
     
  11. Peter Debik

    Peter Debik Golden Pleskian Plesk Guru

    37
    80%
    Joined:
    Oct 15, 2015
    Messages:
    1,902
    Likes Received:
    391
    Location:
    Berlin, Germany
    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.
     
  12. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    Thank you Peter. I opened a support ticket.
     
  13. Napsty

    Napsty New Pleskian

    1
    20%
    Joined:
    Jun 29, 2016
    Messages:
    8
    Likes Received:
    1
    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.
     
    Peter Debik likes this.
Loading...