• 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 "Internal server error" when trying to change subscription system username

pleskuser67553

Basic Pleskian
Username:

TITLE

"Internal server error" when trying to change subscription system username

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CPU
Intel Xeon Processor (Skylake, IBRS) (2 core(s))
Version
Plesk Obsidian v18.0.57_build1800231218.09 os_RedHat el8
Operating System
AlmaLinux 8.9 (Midnight Oncilla)

PROBLEM DESCRIPTION

"Internal server error" displayed in a red bar when trying to change a subscription's system username.

STEPS TO REPRODUCE

Click on Subscriptions > any subscription > Hosting & DNS of a domain > Hosting

Hosting Settings card slides in from the left.

Scroll down to Webspace settings > System user's credentials > amend the Username > click Save at the bottom

Unhelpfully, nothing appears to happen, but if you scroll to the top of the card a message is displayed "Internal server error" in a red bar.

ACTUAL RESULT

System username is not changed and apparently cannot be changed due to "Internal server error"

EXPECTED RESULT

System username should be changed and the card slides away with a message saying 'success'.

ANY ADDITIONAL INFORMATION

Screenshots to be appended.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
I suspect that the user owns running processes so that the name cannot be changed until the processes stop.
Could you please try to follow these steps?
1) Deactivate the domains that are affected by that system user name.
2) Change the user name.
3) Activate the domains again.
 
Hi Peter,

Thanks for your quick response.

I tried the following:
  • Suspend the domain (there is only one domain in this Subscription)
  • Disable the domain
  • Suspend the Subscription
All produced the same result/error as described above.
 
I tried the same setup on an Alma 8 test server, but was not able to reproduce the error. I can't forward this as a product issue, because in my setup(s) here the issue does not occur. Please contact Plesk support so that staff can check it on your server, because it is probably an issue caused by something on your server.
 
Thanks for your time, Peter.

I checked the Plesk tab in Log Browser. There was indeed another process blocking it. However, when I look for the process ID in SSH Terminal, it appears not to exist. So I guess some process starts up when the renaming request happens..?

Code:
# ps -fp 449653
UID          PID    PPID  C STIME TTY          TIME CMD
# cat /proc/449653/status
cat: /proc/449653/status: No such file or directory

1705400254256.png
 
If there are no processes owned by the user when you start the renaming transactions, it will work. That there was a process in the past does not mean that the same process is still active when you try to check it now.
 
Last edited:
Okay, I tried:

Code:
# ps -u system_username

Where system_username is the username in question.

But it just returns an empty list -- before and after attempting to change the system username.
 
I just cannot reproduce the issue, so probably it will be best if you open a support ticket for it. It's not a general product issue.
 
Thanks. I'll just workaround with a new subscription and move the domains over.

I'll remind myself to check what happens on the next vanilla server / Plesk installation from our supplier.
 
I had this problem. I was logged into the user in a terminal session. After I logged out, I was then able to change the username without any problems.
 
So it appears to only be affecting one server of mine and the error happens for every user I try. The server has since been updated to Plesk Obsidian 18.0.59 Update #2 and I've carried out a Plesk Diagnose & Repair and I've repaired the installation, to no avail.
 
It was possible to change a subscription system username after the server automatically updated to Version 18.0.60 Update #1, so I guess something got restarted..?
 
@Kaspar@Plesk Let's re-open this. I was able to reproduce it, it's a bug. It's not reliably reproducible, but I am almost certain to see the cause anyway: When a number of domains exist in a subscription and the system user name is changed, there seems to be either a race condition between an entry of the new system user name in /etc/passwd and the update of the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf files of the domains in that subscription, or the fact that the user cannot be modified because processes still run that don't allow the modification is ignored by the Plesk script that performs the update.

The username in /etc/passwd is changed, the username in the *.conf files has not yet changed while a function already tests whether the update was permissible and successful. This results in the error as it finds that PHP-FPM for the domains is using a wrong username.

In the panel.log this looks like this:

Code:
usermng: Unable to modify user: <old username>
usermod: user <old username> is currently used by process 927542
...
[06-May-2024 10:41:58] ERROR: [pool <domain name>] cannot get uid for user '<old username>'
[2024-05-06 10:43:04.853] 926314:66389818349f6 ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/phpinimng' '--virtual-host' '<subscription domain name>' '--override' '/var/www/vhosts/system/<subscription domain name>/conf/php.ini' '--type' 'fpm' '--global-config' '/opt/plesk/php/8.2/etc/php.ini' '--cgi-bin' '/opt/plesk/php/8.2/sbin/php-fpm' '--sysuser' '<new username>' '--service-name' 'plesk-php82-fpm' '--poold' '/opt/plesk/php/8.2/etc/php-fpm.d' '--no-reload'] with exit code [1]

I am must not certain whether this behavior is reproducible reliably by first attempting to rename while the old username is still in use or whether it is a true race condition in scripts.

The workaround is to manually change all entries of the old username in all affected .conf files to the new username, because the PHP-FPM .conf files are the only files that are not updated to the new correct username, e.g. do sed -i 's/<old username>/<new username>/g' *.conf in the affected php-fpm.d directory.
 
@Bitpalast, I will file this as a bug. Just to help clarify things on my end, how many domains are there in the subscription?

I would assume that having a larger number of domains in a subscription would make a race condition more likely.
 
Back
Top