Forwarded to devs Broken systemd symlinks left behind after PHP version removal/deactivation

[Azurel]

Username:

TITLE

Broken systemd symlinks left behind after PHP version removal/deactivation

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

18.0.80#1, AlmaLinux 8.10

PROBLEM DESCRIPTION

After uninstalling PHP 8.3 and deactivating PHP 8.4 through Plesk, orphaned symlinks remain in /etc/systemd/system/multi-user.target.wants/, pointing to unit files that no longer exist under /usr/lib/systemd/system/:

• restart-plesk-php83-fpm.path
• restart-plesk-php84-fpm.path
• restart-plesk-php84-fpm_.path

This was discovered via leapp preupgrade while preparing for the AlmaLinux8to9 which reported:

Risk Factor: low
Title: Detected broken systemd symlinks for non-existing services
Summary: Leapp detected broken systemd symlinks on the system that do not correspond to any installed systemd unit. This typically happens when the original systemd unit file has been removed (e.g. an rpm removal) or renamed and the system configration has not been properly modified. These symlinks will not be handled during the in-place upgrade as they are already broken. The list of detected broken systemd symlinks:
- /etc/systemd/system/multi-user.target.wants/restart-plesk-php83-fpm.path
- /etc/systemd/system/multi-user.target.wants/restart-plesk-php84-fpm.path
- /etc/systemd/system/multi-user.target.wants/restart-plesk-php84-fpm_.path
Remediation: [hint] Remove the invalid symlinks before the upgrade.
[command] /usr/bin/rm /etc/systemd/system/multi-user.target.wants/restart-plesk-php84-fpm_.path /etc/systemd/system/multi-user.target.wants/restart-plesk-php83-fpm.path /etc/systemd/system/multi-user.target.wants/restart-plesk-php84-fpm.path

STEPS TO REPRODUCE

See description

ACTUAL RESULT

See description

EXPECTED RESULT

No broken symlinks

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Sebahat.hadzhi]

Hi, @Azurel . Thank you for the report. I was able to replicate the behavior, but not with quite the same STR. On my test server the issue appeared if a domain was configured with Dedicated PHP FPM and the PHP version was either changed or the subscription was removed. Nevertheless, I opened an internal report for our team to take a further look.

 

[Sebahat.hadzhi]

The behavior was recognized as a bug identified with ID PPPM-15455 and it will be fixed in one of the upcoming releases. At this point, I cannot provide an ETA for the fix. The suggested workaround in the meantime is to manually remove the leftovers manually, if needed. Thank you for bringing our attention to the issue.