/sbin/sysctl points to itself

[rjmathar]

After a zypper up the /sbin/sysctl points to itself:

king:~ # l /sbin/sysctl
lrwxrwxrwx 1 root root 12 Feb 21 15:59 /sbin/sysctl -> /sbin/sysctl
king:/home/ccd # uname -a
Linux king 6.4.0-150600.23.50-default #1 SMP PREEMPT_DYNAMIC Fri May  9 22:09:52 UTC 2025 (dee422c) x86_64 x86_64 x86_64 GNU/Linux

This is also reported by “dracut-install” as an error message. I have two other openSUE 15.6 computers where /sbin/sysctl (of the very same time stamp) is a 27288 byte elf 64-bit binary.

king:/home/ccd # l /bin/ps 
lrwxrwxrwx 1 root root 7 Feb 21 15:59 /bin/ps -> /bin/ps
king:/home/ccd # l /usr/bin/ps
lrwxrwxrwx 1 root root 7 Feb 21 15:59 /usr/bin/ps -> /bin/ps

I now have copied the binaries from the other two computers to /bin/ps and /sbin/sysctl to solve this problem; it remains unknown at which time of system upgrades these symlinks were created.

[hcvv]

I do not see that here:

henk@boven:~> ls -l /bin/ps
-rwxr-xr-x 1 root root 134360 Feb 21 15:59 /bin/ps
henk@boven:~> ls -l /sbin/sysctl
-rwxr-xr-x 1 root root 27288 Feb 21 15:59 /sbin/sysctl
henk@boven:~> uname -a
Linux boven 6.4.0-150600.23.50-default #1 SMP PREEMPT_DYNAMIC Fri May  9 22:09:52 UTC 2025 (dee422c) x86_64 x86_64 x86_64 GNU/Linux
henk@boven:~>

Updated last tuesday.

[myswtest]

for comparison:

user@mach:~> ls -l /bin/ps
-rwxr-xr-x 1 root root 134360 Feb 21 08:59 /bin/ps

user@mach:~> ls -l /sbin/sysctl
-rwxr-xr-x 1 root root 27288 Feb 21 08:59 /sbin/sysctl

user@mach:~> ls -l /usr/bin/ps
lrwxrwxrwx 1 root root 7 Feb 21 08:59 /usr/bin/ps -> /bin/ps

user@mach:~> uname -a
Linux mach 6.4.0-150600.23.50-default #1 SMP PREEMPT_DYNAMIC Fri May  9 22:09:52 UTC 2025 (dee422c) x86_64 x86_64 x86_64 GNU/Linux
user@mach:~> 

[dcurtisfra]

@rjmathar:

Further Leap 15.6 information –

 # file /sbin/sysctl 
/sbin/sysctl: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8647f2a5013a6645a184869bf243ac4806279fd7, for GNU/Linux 3.2.0, stripped
 # 
 # l /sbin/sysctl
-rwxr-xr-x 1 root root 27288 21. Feb 15:59 /sbin/sysctl*
 # 
 # uname -a
Linux eck001 6.4.0-150600.23.50-default #1 SMP PREEMPT_DYNAMIC Fri May  9 22:09:52 UTC 2025 (dee422c) x86_64 x86_64 x86_64 GNU/Linux
 # 
 # rpm --query --whatprovides /sbin/sysctl
procps-3.3.17-150000.7.42.1.x86_64
 # 
 # rpm --query --scripts procps
 # 
 # rpm --query --changelog procps
* Fr Feb 21 2025 werner@suse.de
- Add patch CVE-2023-4016-part2.patch
  * Fix the ps command segfaults when pid argument has a leading space (bsc#1236842)

* Mi Sep 20 2023 werner@suse.de
- Submit latest procps 3.3.17 to SLE-15 tree for jira#PED-3244
  and jira#PED-6369
- The patches now upstream had been dropped meanwhile
  * procps-vmstat-1b9ea611.patch (bsc#1185417)
  - For support up to 2048 CPU as well
  * bsc1209122-a6c0795d.patch (bnc#1209122)
  - allow `-´ as leading character to ignore possible errors
    on systctl entries
  * patch procps-ng-3.3.9-bsc1121753-Cpus.patch (bsc#1121753)
  - was a backport of an upstream fix to get the first CPU
    summary correct
- Enable pidof for SLE-15 as this is provided by sysvinit-tools
- Use a check on syscall __NR_pidfd_open to decide if
  the pwait tool and its manual page will be build
 .
 .
 .
 #

---

1. The last change to the RPM packet containing /sbin/sysctl happen on the 21st of February this year – since then, no more changes …
2. OK – maybe something else dropped a recursive symbolic link on that file but, what???!!!
3. Nothing else provides /sbin/sysctl …

---

If this happens again –

• First: determine which RPM package is providing the file in question.
• Then: forcibly re-install the affected package – “zypper install –force ”

[dcurtisfra]

@rjmathar:

Some more information:

 # LANG=C ln /sbin/sysctl /sbin/sysctl
ln: failed to create hard link '/sbin/sysctl': File exists
 # 
 # LANG=C ln -s /sbin/sysctl /sbin/sysctl
ln: failed to create symbolic link '/sbin/sysctl': File exists
 #

Which means, the definition of such a recursive link requires that,

1. The file doesn’t exist and,
2. Only a symbolic link can be created …

 # LANG=C l /sbin/abc
ls: cannot access '/sbin/abc': No such file or directory
 # 
 # LANG=C ln /sbin/abc /sbin/abc
ln: failed to access '/sbin/abc': No such file or directory
 # 
 # LANG=C ln -s /sbin/abc /sbin/abc
 # 
 # l /sbin/abc
lrwxrwxrwx 1 root root 9 13. Jun 11:55 /sbin/abc -> /sbin/abc
 # 
 # file /sbin/abc
/sbin/abc: broken symbolic link to /sbin/abc
 #

---

Therefore, whatever it was that created the recursive symbolic link the /sbin/sysctl had –

1. First, deleted /sbin/sysctl.
2. And then, created a recursive symbolic link to /sbin/sysctl.
3. And, that recursive symbolic link was broken.