Hello Everyone,
We have received a number of reports regarding service failures with the error "Too many levels of symbolic links". This is an upstream issue involving the latest update to systemd included in CentOS 7.7.
Technical Summary
The recent CentOS 7.7 update includes an update to systemd-219-67, which changed how systemd opens symbolic links. If your kernel doesn’t support the new method which systemd uses to open symbolic links, then you may see “Too many levels of symbolic links” errors as seen in the example below:
Do you know of any additional error messages that should appear above? Reply to this thread to let us know!
Please understand this is an Operating System issue with the kernel and systemd. While the following link is a bug reported against Ubuntu, it is still relevant, and has a response from OpenVZ developers about the issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847/comments/18
Affected Systems
Thus far, we've seen reports of this on systems with the following configurations:
• CentOS 7.7 and OpenVZ/Virtuozzo with kernels older than 2.6.32-042stab134.7
• CentOS 7.7 with kernel older than 2.6.39
Workaround Notices
1) Update the Virtuozzo kernel on the server.
2) Reboot the server.
Create an addon service file for each service that is failing in order to change the location of the PID file. Using "spamd" as an example:
1) Execute the following command via SSH as a user with root access:
2) The command will bring up a text editor, at which point you can add entries like the ones below to modify where the PID file is located:
3) Confirm the custom override file for systemd was automatically populated:
4) After making any changes, reload systemd and the failed service. EX:
Additional Workarounds
Do you know of any additional workarounds that should appear above? Reply to this thread to let us know!
We'll update this thread with more information and additional workarounds as they becomes available.
Thank you.
We have received a number of reports regarding service failures with the error "Too many levels of symbolic links". This is an upstream issue involving the latest update to systemd included in CentOS 7.7.
Technical Summary
The recent CentOS 7.7 update includes an update to systemd-219-67, which changed how systemd opens symbolic links. If your kernel doesn’t support the new method which systemd uses to open symbolic links, then you may see “Too many levels of symbolic links” errors as seen in the example below:
Code:
# systemctl status lfd.service
lfd.service - ConfigServer Firewall & Security - lfd
Loaded: loaded (/usr/lib/systemd/system/lfd.service; enabled; vendor preset: disabled)
Active: failed (Result: timeout) since Wed 2019-09-18 16:10:10 CEST; 1min 40s ago
Process: 24132 ExecStart=/usr/sbin/lfd (code=exited, status=0/SUCCESS)
Sep 18 16:08:40 server systemd[1]: Starting ConfigServer Firewall & Security - lfd...
Sep 18 16:08:41 server systemd[1]: Can’t open PID file /var/run/lfd.pid (yet?) after start: Too many levels of symbolic links
Sep 18 16:10:10 server systemd[1]: lfd.service start operation timed out. Terminating.
Sep 18 16:10:10 server systemd[1]: Failed to start ConfigServer Firewall & Security - lfd.
Sep 18 16:10:10 server systemd[1]: Unit lfd.service entered failed state.
Sep 18 16:10:10 server systemd[1]: lfd.service failed.
Please understand this is an Operating System issue with the kernel and systemd. While the following link is a bug reported against Ubuntu, it is still relevant, and has a response from OpenVZ developers about the issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847/comments/18
Affected Systems
Thus far, we've seen reports of this on systems with the following configurations:
• CentOS 7.7 and OpenVZ/Virtuozzo with kernels older than 2.6.32-042stab134.7
• CentOS 7.7 with kernel older than 2.6.39
Workaround Notices
Workaround 1 (requires access to the VPS hardware node)• We recommend that only experienced system administrators perform the steps in these workarounds.
• If you operate a VPS, but do not have access to the VPS hardware node, report the issue to your VPS hosting provider so they can update the kernel (you can proceed to workaround #2 below in the meantime).
• The workarounds in this thread are intended for OpenVZ/Virtuozzo systems using CentOS 7.7 with kernels older than 2.6.32-042stab134.7 (or in limited cases, CentOS 7.7 systems with kernels older than 2.6.39). Using these instructions on different operating systems or virtual environments is not recommended. The following commands will help you determine the type of server you are using:
# cat /etc/redhat-release
# uname -r
# lscpu|grep Hypervisor
• If you desire to hire a company to perform this system administration task, check out our system administration services page at SafeAdmin Certified SysAdmin Services. If you see SafeAdmin Certified on the listing title, it means the company successfully completed cPanel University's SafeAdmin certification process.
1) Update the Virtuozzo kernel on the server.
2) Reboot the server.
Workaround 2Note: If the server is rebooted prior to updating the kernel, the server's systemd target may default to graphical instead of multi-user, blocking other services from attempting to start. This is because `default.target' is also set via symlink.
Create an addon service file for each service that is failing in order to change the location of the PID file. Using "spamd" as an example:
1) Execute the following command via SSH as a user with root access:
systemctl edit spamd.service
2) The command will bring up a text editor, at which point you can add entries like the ones below to modify where the PID file is located:
Exit the text editor after adding the entries and save the changes you made. Make sure you change this content to match different services as needed.[Service]
PIDFile=/run/spamd.pid
3) Confirm the custom override file for systemd was automatically populated:
Rich (BB code):
# cat /etc/systemd/system/spamd.service.d/override.conf
[Service]
PIDFile=/run/spamd.pid
systemctl daemon-reload
/scripts/restartsrv_spamd
Additional Workarounds
Do you know of any additional workarounds that should appear above? Reply to this thread to let us know!
We'll update this thread with more information and additional workarounds as they becomes available.
Thank you.
Last edited: