• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Plesk Update Fails

we pay £10 a month for a plesk licence this includes support from your ISP who is suppose to have trained employees to deal with plesk issues.

Igor, i've tried to follow the instructions to raise a ticket to get direct plesk support but i'm struggling. All these issues are making me feel like an idiot.
Hello, please check your PM. We will create a support ticket and check the issue.
 
tried to get a ticket, not possible because license number is bought from a 3rd party, belongs to the server package.

How to apply a direct one?
Have you purchased the support subscription as it is described in the mentioned KB article?
 
Maybe I am to blonde or not awake because of the long working hours this morning in regards of that issue! ! I followed the steps, also registered myself to Plesk support. By filling out the support description there is no "send" or whatelse ever button by filling out the field "license key". I only get the warning because of that the license key is bought at 3rd party. Would be nice for an instruction for a not awake and a too blond human. Thanks! :)

Have you purchased the support subscription as it is described in the mentioned KB article?
 
Andreas, i have a third party license. a team member would need to start the ticket for you.



ok so im all sorted thanks Alexandr, my issue was caused by a reboot in the middle of aptitude running an update.

MySQL database was corrupted, the half of files were missing in /var/lib/mysql/mysql folder.

started MySQL with 'skip-grant-tables' option in /etc/mysql/my.cnf to bypass missing mysql.user table and restored mysql daily dump from April, 2 as the last one was also corrupted.

MySQL was upgraded by aptitude and it was able to start. A bit later it failed after sudden reboot
 
Johnny,

checked that on our side, not the case. All is complete and running well (as far as I see). Also no reboot of the server in that time, maybe a restart of services but I can't see it now. MySQL was always on my radar since it happened.

That with the support ticket "submit a ticket" is an absolute mess! Tried that some hours ago but couldn't find an option to conclude it! I would be pleased to do it, but after filling out the requested fields, there is no "send" or whatever button. That is all strange. One problem additionally to the next problem! ;)

Thanks for the team member option. Send me a PM to get a clue of it. Otherwise I will go out and cut the grass to calm down! ;)


Andreas, i have a third party license. a team member would need to start the ticket for you.



ok so im all sorted thanks Alexandr, my issue was caused by a reboot in the middle of aptitude running an update.

MySQL database was corrupted, the half of files were missing in /var/lib/mysql/mysql folder.

started MySQL with 'skip-grant-tables' option in /etc/mysql/my.cnf to bypass missing mysql.user table and restored mysql daily dump from April, 2 as the last one was also corrupted.

MySQL was upgraded by aptitude and it was able to start. A bit later it failed after sudden reboot
 
Johnny,

checked that on our side, not the case. All is complete and running well (as far as I see). Also no reboot of the server in that time, maybe a restart of services but I can't see it now. MySQL was always on my radar since it happened.

That with the support ticket "submit a ticket" is an absolute mess! Tried that some hours ago but couldn't find an option to conclude it! I would be pleased to do it, but after filling out the requested fields, there is no "send" or whatever button. That is all strange. One problem additionally to the next problem! ;)

Thanks for the team member option. Send me a PM to get a clue of it. Otherwise I will go out and cut the grass to calm down! ;)

Hi Andreas! Please check your PM.
 
I have this same issue (been struggling with it for days) and I'm confused about is being marked as resolved.

Is the resolution to contact Plesk support and have them fix it?

i followed this advice from page 1:
# /etc/init.d/apparmor stop
# /etc/init.d/apparmor teardown
# update-rc.d -f apparmor remove

followed by a dpkg --configure -a which proceeded to put the cpu to 100% and kick me out of the shell.

Before doing these steps I was at least able to restart the server and log back in and have a running webserver and email but now I'm screwed since I can't ssh in without apparmor running.

Please if there is an actual resolution to this can someone post it - even if it doesn't help me maybe it can save the next person from having to restore a backup.
 
It seems that it is a Linux Kernel bug what is described here: Bug #1579135 “AppArmor profile reloading causes an intermittent ...” : Bugs : linux package : Ubuntu

and it has nothing to do with Plesk.

Plesk support was very helpful for to investigate this, THANKS, guys!

It seems that this Linux kernel bug is affecting some server systems. Not all of it. We do have four servers, all the same, software configuration, the hardware isn't the same. On two the problem occurs last week Tuesday in the night by automatic update routine, afterwards the server crashes. By rebooting, the server works nominal but Plesk was showing in the Plesk server config page errors, updates weren't done.

Next day same problem without server crash, then the next day server crash and so on. I started to find out the problem, but it takes me up to this week Monday to find out that I am not the only idiot who has this problem. At the moment I have disabled all automatic updates, Plesk and Ubuntu because it doesn't support any software installation without crashing the server.

I do think that you have the same problem like we do,

The suggestion I got is to update the Kernel version. I did the update on one of our servers, but I am not able to tell at the moment any result because I have to work now in step by step plan to find out if this error isn't there anymore. The update process was done perfectly. I do not have access to the server where I did the update at the moment, but this isn't a result of the upgrade itself, connectivity problems at hosters side. Happens then when it isn't needed.

Here you can read about the error scenario: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1614459

It is precisely reproducing what is happening at the server systems at our side.

So far, the suggestion is to upgrade the Linux kernel. This bug was fixed in the Ubuntu kernel 4.4.0-38.57.

Will be back with results from our side.
 
Update: on one server it works with the Kernel update without any problem. By giving our main server the command for update the kernel like

#apt install linux-image-4.4.0-72-generic

the info that the dpkg process was interrupted and to solve this, it has to be done manually by #dpkg --configure -a, shown up again. Can't do, server will crash again.

Server is not accepting commands for updates or installing of software.

I am only nine days in this reconnaissance mode by now. Still counting ....
 
You are a hero!

I followed the post here Update : Linux Kernel 4.9.2 on Ubuntu 16.04, Ubuntu 16.10 and Linux Mint 18 - Ubuntu Maniac - Linux News to update the kernel to 4.9.2-040902-generic

After that I did:

Code:
sudo reboot
sudo dpkg --configure -a

and it actually worked.

After that I was able to

Code:
sudo apt-get install aptitude 
sudo aptitude upgrade
sudo reboot

The plesk interface is still telling me there are 4 updates that when i try to run them I get a msg saying they are already up to day (and they are) but that's the least of my worries.

Thanks so much for getting to the bottom of this.
 
Nope! I am not a hero. The only thing what I have is "patience without an end" to get a problem solved. For any problem, there is still a solution.

Good that your problem was solved. I do hang in the same problem solution but will risk a view to your given links and workflow. I am also working on a sheet what I found on the web, and first time after giving the command what sent the server in the loop server is not crashing but shows a much high workflow, as a server stress test.


You are a hero!

I followed the post here Update : Linux Kernel 4.9.2 on Ubuntu 16.04, Ubuntu 16.10 and Linux Mint 18 - Ubuntu Maniac - Linux News to update the kernel to 4.9.2-040902-generic

After that I did:

Code:
sudo reboot
sudo dpkg --configure -a

and it actually worked.

After that I was able to

Code:
sudo apt-get install aptitude
sudo aptitude upgrade
sudo reboot

The plesk interface is still telling me there are 4 updates that when i try to run them I get a msg saying they are already up to day (and they are) but that's the least of my worries.

Thanks so much for getting to the bottom of this.
 
Hi all, I just wanted to add the we were suffering from the same problem (update hangs indefinitely at configuring app armor). With the help provided in this thread I was able to resolve the issue: Upgrading manually to kernel 4.9.2-040902-generic and then calling dpgk --configure -a successfully. Thanks for documenting this solution here. It was a nasty bug that in total got us round about 2 hours of downtime.

Curiously, we are also running on Strato root hardware.
 
Hi rewb0rn,

pls. note, that your server hoster is not responsible for kernel updates/upgrades, nor is it Plesk, it's components or extensions. It's "server administration" - task. ;)
 
Well: A server hoster is responsible for running the hardware, approved by them. They do the advertisement with it (running newest server hardware and software). This bug happened on server systems with Ubuntu Kernel below linux-image-4.4.0-72-generic. Exactly on the day as Ubuntu wanted to do the update to a new Kernel, the system failed.
At our side, it was a reason by AppArmor service, what did not let any update or software installation go from this moment on. It takes us ten days for to find a solution. Of course, Strato isn't responsible for this bug, but they know it, and nobody can tell me that they "do not have any problems on test servers", what they did first of all.

The great PLESK team (thanks again) took care of that problem and found a solution finally by trial & error with us. That was the best customer service what I do receive in 20 years of managing IT! Our hoster said: not our problem -> root server. Afterwards, in communication with them, they saw that problem also. Also, root server clients on hosters side need some time more support, and even it is in corporate forums, but in that forums, you will find only regular tasks (besides Heartbleed, etc.).

It was not the first time that such happened over 15 years of experience with our hoster Strato. I will not point the finger onto them, but it wonders me that we did only receive the standard e-mails of support. They point out to use in the future managed servers or to install the server new. That was their solution. PLESK solution was to find out the problem and to solve it so that we didn't have to install the servers fresh.

Since one week now: all is green. Of course, it was a giant learning curve to handle this all. Each day is a learning day.

Hi all, I just wanted to add the we were suffering from the same problem (update hangs indefinitely at configuring app armor). With the help provided in this thread I was able to resolve the issue: Upgrading manually to kernel 4.9.2-040902-generic and then calling dpgk --configure -a successfully. Thanks for documenting this solution here. It was a nasty bug that in total got us round about 2 hours of downtime.

Curiously, we are also running on Strato root hardware.
 
Back
Top