Articles in this section

See more

Plesk fails to restart services: control script doesn't exist or isn't executable

Avatar
Alexander Tsmokalyuk
Updated
Follow
Plesk for Linux kb: bug ABT: Group A

Applicable to:

  • Plesk for Linux

Symptoms

  • The following error is shown in Plesk UI:

    PLESK_ERROR: New configuration flies for the Apache web server were not created due to the errors in configuration templates: Can not restart web server: INFO: : Service: httpd. Action: stop Trying to stop service httpd... WARNING! Some problems are found during attempt to stop service httpd - control script doesn’t exist or isn't executable(see log file: /var/log/plesk/rc_actions.log) Continue... INFO:: Service: httpd. Action: stop Trying to stop service httpd... WARNING! Some problems are found during attempt to stop service httpd - control script doesn't exist or isn’t executable(see log file:

  • The output of the top utility shows that the systemd process consumes up to 100% CPU.

  • There are a lot of abandoned systemd scope units on the server:

    # systemctl | grep abandoned | wc -l
    293

  • The following entries can be found in /var/log/plesk/panel.log and also in /var/log/httpd/error_log:

    CONFIG_TEXT: INFO: : Service: httpd, Action: start
    Trying to start service httpd...
    WARNING!
    Some problems are found during attempt to start service httpd - control script doesn't exist or isn't executable(see log file: /var/log/plesk/rc_actions.log)
    Continue...
    example.com systemd[1]: Starting The Apache HTTP Server...
    example.com httpd[16900]: [so:warn] [pid 16900:tid 3507090413696] AH01574: module unique_id_module is already loaded, skipping
    example.com systemd[1]: Started The Apache HTTP Server.
    example.com systemd[1]: httpd.service: main process exited, code=killed, status=9/KILL
    example.com kill[17101]: kill: cannot find process ""
    example.com systemd[1]: httpd.service: control process exited, code=exited status=1
    example.com systemd[1]: Unit httpd.service entered failed state.
    example.com systemd[1]: httpd.service failed.
    example.com systemd[1]: Starting The Apache HTTP Server...
    WARNING!
    Some problems are found during start service httpd(see log file: /var/log/plesk/rc_actions.log)

    OR

    CONFIG_TEXT: example.com systemd[1]: Starting The Apache HTTP Server...
    example.com httpd[16900]: [so:warn] [pid 16900:tid 3507090413696] AH01574: module unique_id_module is already
    loaded, skipping
    example.com systemd[1]: Started The Apache HTTP Server.
    WARNING!
    Some problems are found during stop service httpd(see log file: /var/log/plesk/rc_actions.log)
    Continue..
    STOP pleskrc
    START pleskrc
    INFO: : Service: httpd, Action: status
    WARNING!
    Some problems are found during attempt to status service httpd - control script doesn't exist or isn't executable(see log file: /var/log/plesk/rc_actions.log)

Possible consequences

  • Service plan synchronization takes a lot of time or fails with the following error message:

    PLESK_ERROR: Unable to sync subscriptions with the service plan

  • Operations like mailbox creation or changing domain's configuration take more time than expected.

  • Accessing different Plesk pages takes more time than expected, for example, WordPress, Webserver Configuration Troubleshooter, etc.

  • When a domain is created, Apache stops and fails to restart.

  • Let's Encrypt daily cronjob also causes Apache to stop.

  • The server is slow, web-server constantly crashes.

  • Apache hangs on attempt to perform a migration.

  • systemd fails with:

    # time /bin/systemctl list-unit-files
    Failed to list unit files: Connection timed out

  • Service status checker takes more time than it takes after a server reboot:

    # time plesk sbin apache_control_adapter --status
    is running
    real 0m9.803s
    user 0m0.038s
    sys 0m0.036s

Cause

Session files are not deleted due to systemd bug:

Plesk bug with ID #PPPM-7414 has been created in order to track the issue.

Resolution

As a workaround, create a scheduled task which will stop abandoned units:

  1. Connect to the server via SSH

  2. Download the script from the attachment:

    # wget https://plesk.zendesk.com/hc/article_attachments/360044074594/cleanup_systemd_sessions.zip

  3. Run the following command to extract the archive and clean up session files:

    # mv /run/systemd/system/session-*.scope /tmp/ && unzip cleanup_systemd_sessions.zip && /root/cleanup_systemd_sessions.sh

  4. Create a cron task that will execute this script every hour:

    4.1. Open the crontab editor:

    # crontab -e

    4.2. Add the content below at the end of the file, for example:

    CONFIG_TEXT: 0 * * * * /root/cleanup_systemd_sessions.sh

    4.3. Save the changes and close the file.

Comments

18 comments

Sort by Date Votes
  • Avatar
    Abraham Joseph

    Hi, 

    How to find the details of this bug - #PPPM-7414? I  mean, latest updates?

    Thanks!

    0
    Comment actions Permalink
  • Avatar
    Alexandr Tumanov

    @Abraham, bugfixes are listed in Plesk ChangeLog: https://docs.plesk.com/release-notes/onyx/change-log/ 

    This bug is not fixed yet.

    0
    Comment actions Permalink
  • Avatar
    Ansgar Smith

    @Alexandr,  Any updates on this issue? It's causing outages with new Plesk installations, though the temprorary fix works good for us. Would be good if it's fixed permanently

    Thank!

    0
    Comment actions Permalink
  • Avatar
    Anzhelika Khapaknysh (Edited )

    Hi @Ansgar Smith,

    In general, this bug is a systemd one - all OSes with systemd are affected.
    Links on the discussions are in the Cause section.

    The bug PPPM-7414 is created in order to track this issue in general.
    As the root cause is on the systemd side, Plesk cannot offer a permanent solution, but we created this workaround so our customers won't suffer from systemd bug.

    I recommend following this article, as we'll update it as soon as systemd bug is fixed.
    The Cause section has been modified in order not to confuse anymore.

    0
    Comment actions Permalink
  • Avatar
    Websavers Inc

    I like that the updated version of the cleanup_systemd_sessions script actually checks to ensure the session has not been active in the last 30 minutes, but shouldn't it be starting with a list of supposedly abandoned sessions like the previous version of it did? When I run that script, it kills my active SSHd session... clearly that was not abandoned and it also definitely was active in the last 30 minutes. Here's a modified version which merges the old and the new script by ensuring we're only terminating *abandoned* sessions which have not spawned processes in the past 30 minutes (rather than terminating all sessions which have not spawned processes in the past 30 minutes):

    #!/bin/sh
    # Removes leaked session scopes (PPPM-7414) # 

    # Close only sessions which did not spawn processes for 30 minutes
    LASTTASK=30

    systemctl list-units --state=abandoned --no-legend | tr -s ' ' | cut -d' ' -f 6,9 \
    	| while read -r session username; do \
    		user=$(id -u $username)
    		tasklist="/sys/fs/cgroup/systemd/user.slice/user-${user}.slice/session-${session}.scope/tasks"
    			if [ ! -s "$tasklist" ]; then
    				if find "$tasklist" -type f -mmin +${LASTTASK} >/dev/null; then
    				echo "Closing leaked session ${session} of user ${user}"
    				loginctl terminate-session "$session" >&2
    				fi
    			fi
    done
    0
    Comment actions Permalink
  • Avatar
    Maxim Krasikov

    Hello @Websavers Inc !

    Thank you for paying our attention to it and providing the modified script.

    The article has been updated.

    0
    Comment actions Permalink
  • Avatar
    Websavers Inc

    @... This bug is tagged for Onyx, and not Obsidian; should it be tagged as applicable to Obsidian as well? I don't see PPPM-7414 listed in the Obsidian changelog.

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    Hello Websavers Inc

    Thank you for notice, I'll correct the tagging.

    PPPM-7414 is yet to be resolved.

    0
    Comment actions Permalink
  • Avatar
    Websavers Inc

    Another quick update here. The referenced articles here may need updating. Here's why:

    • The systemd github issue indicates that this isn't their problem (it's labled 'not-our-bug' and is closed) as the issue is in the dbus package, not systemd (the problems the bug creates can be managed with systemd, but aren't caused by it).
    • The Redhat bug tracker claims that this was fixed in dbus version dbus 1.10.24 back in Aug 2019 and I can confirm that our fully updated CentOS 7 servers are running this version, with the current system package for dbus being: dbus-1.10.24-13.el7_6.x86_64

    Therefore either this bug is fixed (which I don't believe it is), or there's something *else* other than the referenced bug reports that is still causing this issue. Since I'm not seeing any additional users posting on either of those bug reports indicating they're still having a problem after updating dbus, that would lead me to believe that perhaps it might even be Plesk-specific packages that are still causing this problem.

    I guess the question then is: what's really going on here? If it's not fixed with the CentOS dbus package update, then you guys might need to look further into this.

    0
    Comment actions Permalink
  • Avatar
    Francisco Garcia

    Hi Websavers Inc,

    These 3 articles referenced here aren't created by us, they are what we could find regarding the same issue experienced.

    If after updating dbus and systemd packages you're still experiencing the same issue, it could mean one of those 2 things:

         1- Or the bug is not yet fixed, because there's some other package involved (or maybe the kernel)

         2- Or there's another different bug that has the same symptoms.

    In any of the 2 possibilities, I would encourage you to open a support request so that we can investigate exactly why it still fails.

    0
    Comment actions Permalink
  • Avatar
    Christophe Beaumont

    Hello,

    I have quite the same issue but on the new obsidian.

    Apache is throwing same log stack and I had to reboot the server to have apache up again (but still with same issue, apache is not started completely and fails everytime and then start again, etc).

    Do you know if this workaround should work with new version of plesk?

    Information: CentOS Linux 7.8.2003 (Core) - Plesk Obsidian Version 18.0.29 Update #2, last updated on Aug 23, 2020 03:23 PM

    Thanks in advance,

    Regards

    Christophe

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    Hello Christophe Beaumont

    This workaround doesn't depend on the Plesk version and should work fine.

    -1
    Comment actions Permalink
  • Avatar
    Peter VARGA

    The date of the first comment for this thread is from April 2018 - this is more than 2 years ago. Is there any time frame when this bug will be fixed?

    It's not fine to use some workarounds. This is very tiresome and it bothers. Very fine is when the bug is finally fixed. Thank you for your reply.

    0
    Comment actions Permalink
  • Avatar
    Alisa Kasyanova

    @Peter VARGA

    The issue is caused by systemd bug, and affects servers even without installed Plesk. So this bug cannot be fixed on Plesk side.
    You may check the threads mentioned in the Cause section to see if there are any ETAs there.

    0
    Comment actions Permalink
  • Avatar
    Websavers Inc

    @... Well that's the trouble. In each of the threads in the Cause section, this bug was found to:

    1. Not be systemd, but actually in dbus

    2. dbus packages were patched to fix this (via RHEL) in December 2019 and rolled out to CentOS a month or two later, and also Virtuozzo Linux by March 2020. 

    Despite this issue supposedly being fixed (and people in the threads linked above agreeing that the issue has been resolved), a few have reported this issue still occurring on Plesk servers.

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    Hello Websavers Inc

    Do you have an affected server where all the latest packages are installed?

    If so, could you submit a support request so that we could double-check the issue on our side?

    0
    Comment actions Permalink
  • Avatar
    Myhost

    Hi Ivan,

    We have had two servers show the same issue, both are up to date running Obsidian on CentOS 7.

    We have applied the fix, but if you want access let us know and we can provide.

    Regards

    MH

    0
    Comment actions Permalink
  • Avatar
    Nelson Leiva

    Hi Myhost,

    Please submit a request with our support team in case the issue persists for you so we can investigate this further: How to submit a support ticket directly with Plesk

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request

Related articles