I've run this little script from time to time in /
find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
At present ends up with other 300 lines in the badlinks-clean
Cleaned up a number of bad lines in a jre directory that seemed to be left over stuff from fc27 to fc33? Nothing from fc34?? and the reset were the currect fc35 files I have on system. Seems things that just got left??
Not sure if it is coming to have these on a system?
Wonder if someone with a lot more knowledge than I have might know best option. Just leave them, remove some, remove all? Figured the ones in /proc and /run should be left alone??
Thanks.
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On Fri, 2022-09-16 at 14:55 +1000, Michael D. Setzer II via users wrote:
I've run this little script from time to time in /
find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
Not really relevant to your question, but you could make this a one- liner:
find / -xtype l |& grep -v '^/proc|^run' > /badlinks-clean
poc
On Fri, 16 Sep 2022 14:55:11 +1000 "Michael D. Setzer II via users" users@lists.fedoraproject.org wrote:
I've run this little script from time to time in /
find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
At present ends up with other 300 lines in the badlinks-clean
Cleaned up a number of bad lines in a jre directory that seemed to be left over stuff from fc27 to fc33? Nothing from fc34?? and the reset were the currect fc35 files I have on system. Seems things that just got left??
Not sure if it is coming to have these on a system?
Wonder if someone with a lot more knowledge than I have might know best option. Just leave them, remove some, remove all? Figured the ones in /proc and /run should be left alone??
I don't have a lot more knowledge than you do, but a symbolic link that points to nothing, is broken, is useless. Anything that depends on finding what it expects at the end of the link is going to break. So, my opinion is that removing them is harmless. If your system is working correctly, then leaving them is also harmless, other than the cruft it represents, because they aren't being accessed (or you would be getting errors).
The proc / run links are temporary, in that the proc / run filesystem is created each boot, so deleting them is pointless. It doesn't make sense that there are all those broken links. Could the find be incorrect in some way? By that I mean that it is issuing false positives. When I run the command find /proc -L -type l | less or find /run -L -type l | less I get no broken links.
From the find man page for -type l, l symbolic link; this is never true if the -L option or the -follow option is in effect, unless the symbolic link is broken. If you want to search for symbolic links when -L is in effect, use -xtype.
So, using find /proc -L -type l returns true if a link is broken. Note that the default for find is -P, never follow symbolic links, which your command will use.
On 16 Sep 2022 at 8:48, stan wrote:
Date sent: Fri, 16 Sep 2022 08:48:29 -0700 From: stan upaitag@zoho.com To: users@lists.fedoraproject.org Copies to: mikes@guam.net Subject: Re: Question on bad links? Organization: zohofree
On Fri, 16 Sep 2022 14:55:11 +1000 "Michael D. Setzer II via users" users@lists.fedoraproject.org wrote:
I've run this little script from time to time in /
find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
At present ends up with other 300 lines in the badlinks-clean
Cleaned up a number of bad lines in a jre directory that seemed to be left over stuff from fc27 to fc33? Nothing from fc34?? and the reset were the currect fc35 files I have on system. Seems things that just got left??
Not sure if it is coming to have these on a system?
Wonder if someone with a lot more knowledge than I have might know best option. Just leave them, remove some, remove all? Figured the ones in /proc and /run should be left alone??
I don't have a lot more knowledge than you do, but a symbolic link that points to nothing, is broken, is useless. Anything that depends on finding what it expects at the end of the link is going to break. So, my opinion is that removing them is harmless. If your system is working correctly, then leaving them is also harmless, other than the cruft it represents, because they aren't being accessed (or you would be getting errors).
The proc / run links are temporary, in that the proc / run filesystem is created each boot, so deleting them is pointless. It doesn't make sense that there are all those broken links. Could the find be incorrect in some way? By that I mean that it is issuing false positives. When I run the command find /proc -L -type l | less or find /run -L -type l | less I get no broken links.
From the find man page for -type l, l symbolic link; this is never true if the -L option or the -follow option is in effect, unless the symbolic link is broken. If you want to search for symbolic links when -L is in effect, use -xtype.
So, using find /proc -L -type l returns true if a link is broken. Note that the default for find is -P, never follow symbolic links, which your command will use.
Not clear on differnce be -l and -L? find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
Comparing the badlinks and badlinks-clean. wc -l badlink* 647 badlinks 321 badlinks-clean 968 total
Looking at one of the lines reported.
ls /run/systemd/units/invocation:systemd-fsck-root.service -l lrwxrwxrwx. 1 root root 32 Sep 11 19:46 /run/systemd/units/invocation:systemd-fsck-root.service -> df1352a57bbc4b7ab5327327184ff57d
The /run/systemd/units/invocation:systemd-fsck-root.service displays in a dark red with the df1352a57bbc4b7ab5327327184ff57d displays as white letters on a bright red background.
Seems all files in that directory link to files that are not there?
Example from last of badlinks-clean
ls -l extlinux.conf lrwxrwxrwx. 1 root root 30 Jul 24 2021 extlinux.conf -> ../boot/extlinux/extlinux.conf
Same colors on link and there is no ../boot/extlinux/extlinux.conf file, but many other files do exist in that directory.
In looking at the -L option, it seems that takes info from file it links to, so if the file it links to doesn't exist then woul expect it not to show anything?
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On Sat, 2022-09-17 at 02:58 +1000, Michael D. Setzer II via users wrote:
Not clear on differnce be -l and -L?
They have completely different meanings:
'-xtype l' finds files which are themselves symlinks. That's what your script is doing. Nothing I can see in the script detects that those links are bad, just that they are links, i.e. it will detect good links as well, so you probably don't want to just remove them automatically.
'-L' means "follow symbolic links while descending the tree". The default for find is not to do this, as it can often mean searching outside the tree.
You might want to install the symlinks package:
Name : symlinks Version : 1.7 Release : 6.fc36 Architecture : x86_64 Size : 22 k Source : symlinks-1.7-6.fc36.src.rpm Repository : @System Summary : A utility which maintains a system's symbolic links URL : http://ibiblio.org/pub/Linux/utils/file/ License : Copyright only Description : The symlinks utility performs maintenance on symbolic links. Symlinks : checks for symlink problems, including dangling symlinks which point : to nonexistent files. Symlinks can also automatically convert : absolute symlinks to relative symlinks. : : Install the symlinks package if you need a program for maintaining : symlinks on your system.
poc
Did for a in $(cat badlinks-clean); do ls -l $a; done
and all links show as broken?
Did Test # mkdir testbroke # cd testbroke/ # ln -s /badlinks-clean test1 # ln -s /badlinks-cleanx test2 # ls -l total 0 lrwxrwxrwx. 1 root root 15 Sep 17 06:19 test1 -> /badlinks-clean lrwxrwxrwx. 1 root root 16 Sep 17 06:19 test2 -> /badlinks-cleanx
Both badlinks and badlinks-clean only contain ./test2
So only seems to list links that are broken.
On 16 Sep 2022 at 18:50, Patrick O'Callaghan wrote:
Subject: Re: Question on bad links? From: Patrick O'Callaghan pocallaghan@gmail.com To: users@lists.fedoraproject.org Date sent: Fri, 16 Sep 2022 18:50:30 +0100 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On Sat, 2022-09-17 at 02:58 +1000, Michael D. Setzer II via users wrote:
Not clear on differnce be -l and -L?
They have completely different meanings:
'-xtype l' finds files which are themselves symlinks. That's what your script is doing. Nothing I can see in the script detects that those links are bad, just that they are links, i.e. it will detect good links as well, so you probably don't want to just remove them automatically.
'-L' means "follow symbolic links while descending the tree". The default for find is not to do this, as it can often mean searching outside the tree.
You might want to install the symlinks package:
Name : symlinks Version : 1.7 Release : 6.fc36 Architecture : x86_64 Size : 22 k Source : symlinks-1.7-6.fc36.src.rpm Repository : @System Summary : A utility which maintains a system's symbolic links URL : http://ibiblio.org/pub/Linux/utils/file/ License : Copyright only Description : The symlinks utility performs maintenance on symbolic links. Symlinks : checks for symlink problems, including dangling symlinks which point : to nonexistent files. Symlinks can also automatically convert : absolute symlinks to relative symlinks. : : Install the symlinks package if you need a program for maintaining : symlinks on your system.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
Have you looked at the symlinks program it does the same thing. There is info located at: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#Resolvin...
which is the dnf system upgrade page
David
On Sat, 17 Sep 2022 06:26:54 +1000 users@lists.fedoraproject.org wrote:
Did for a in $(cat badlinks-clean); do ls -l $a; done
and all links show as broken?
Did Test # mkdir testbroke # cd testbroke/ # ln -s /badlinks-clean test1 # ln -s /badlinks-cleanx test2 # ls -l total 0 lrwxrwxrwx. 1 root root 15 Sep 17 06:19 test1 -> /badlinks-clean lrwxrwxrwx. 1 root root 16 Sep 17 06:19 test2 -> /badlinks-cleanx
Both badlinks and badlinks-clean only contain ./test2
So only seems to list links that are broken.
On 16 Sep 2022 at 18:50, Patrick O'Callaghan wrote:
Subject: Re: Question on bad links? From: Patrick O'Callaghan pocallaghan@gmail.com To: users@lists.fedoraproject.org Date sent: Fri, 16 Sep 2022 18:50:30 +0100 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On Sat, 2022-09-17 at 02:58 +1000, Michael D. Setzer II via users wrote:
Not clear on differnce be -l and -L?
They have completely different meanings:
'-xtype l' finds files which are themselves symlinks. That's what your script is doing. Nothing I can see in the script detects that those links are bad, just that they are links, i.e. it will detect good links as well, so you probably don't want to just remove them automatically.
'-L' means "follow symbolic links while descending the tree". The default for find is not to do this, as it can often mean searching outside the tree.
You might want to install the symlinks package:
Name : symlinks Version : 1.7 Release : 6.fc36 Architecture : x86_64 Size : 22 k Source : symlinks-1.7-6.fc36.src.rpm Repository : @System Summary : A utility which maintains a system's symbolic links URL : http://ibiblio.org/pub/Linux/utils/file/ License : Copyright only Description : The symlinks utility performs maintenance on symbolic links. Symlinks : checks for symlink problems, including dangling symlinks which point : to nonexistent files. Symlinks can also automatically convert : absolute symlinks to relative symlinks. : : Install the symlinks package if you need a program for maintaining : symlinks on your system.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On 16 Sep 2022 at 15:49, dwoodyard@rdwoodyard.com wrote:
Date sent: Fri, 16 Sep 2022 15:49:27 -0500 From: "dwoodyard@rdwoodyard.com" dwoodyard@rdwoodyard.com To: mikes@guam.net, Community support for Fedora users users@lists.fedoraproject.org Subject: Re: Question on bad links?
Have you looked at the symlinks program it does the same thing. There is info located at: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#Resolvin...
which is the dnf system upgrade page
David
On Sat, 17 Sep 2022 06:26:54 +1000 users@lists.fedoraproject.org wrote:
Did for a in $(cat badlinks-clean); do ls -l $a; done
and all links show as broken?
Did Test # mkdir testbroke # cd testbroke/ # ln -s /badlinks-clean test1 # ln -s /badlinks-cleanx test2 # ls -l total 0 lrwxrwxrwx. 1 root root 15 Sep 17 06:19 test1 -> /badlinks-clean lrwxrwxrwx. 1 root root 16 Sep 17 06:19 test2 -> /badlinks-cleanx
Both badlinks and badlinks-clean only contain ./test2
So only seems to list links that are broken.
Was not aware of that program? Was already installed on my system. Following instructions from link, it found 279 of the broken links under /usr and after checking, I went ahead are removed them.
Doing the run using / instead of /usr it comes up with the other 29 in various placed. That includes the one I created for test earlier, but is 28 I'll have to look into more. Using the symlink to fix the 279 seems good.
dangling: /root/.mozilla/firefox/u3x6t962.default-release/lock -> 192.168.16.107:+945347 dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/bin/pidof -> /sbin/killall5 dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.32.so dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/usr/sbin/rmt -> /etc/alternatives/rmt dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/usr/bin/nawk -> /etc/alternatives/nawk dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/usr/bin/awk -> /etc/alternatives/awk dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/usr/bin/pager -> /etc/alternatives/pager dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service -> /usr/lib/systemd/system/e2scrub_reap.service dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/systemd/system/timers.target.wants/apt-daily.timer -> /lib/systemd/system/apt-daily.timer dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/systemd/system/timers.target.wants/apt-daily-upgrade.timer -> /lib/systemd/system/apt-daily-upgrade.timer dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/systemd/system/timers.target.wants/e2scrub_all.timer -> /usr/lib/systemd/system/e2scrub_all.timer dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/nawk -> /usr/bin/mawk dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/awk.1.gz -> /usr/share/man/man1/mawk.1.gz dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/rmt -> /usr/sbin/rmt-tar dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/awk -> /usr/bin/mawk dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/nawk.1.gz -> /usr/share/man/man1/mawk.1.gz dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/builtins.7.gz -> /usr/share/man/man7/bash-builtins.7.gz dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e 0/diff/etc/alternatives/rmt.8.gz -> /usr/share/man/man8/rmt-tar.8.gz dangling: /var/lib/docker/overlay2/28ea8bf8cd11eb2ba0083d7880d4fd72ae686e7181836f3f0856935a301c743b /diff/var/lock -> ../run/lock dangling: /var/lib/docker/overlay2/28ea8bf8cd11eb2ba0083d7880d4fd72ae686e7181836f3f0856935a301c743b /diff/usr/lib/.build-id/de/0c45c833ff32567e3b1b47c857b1347791b948 -> ../../../../usr/bin/coreutils.single dangling: /var/lib/docker/overlay2/28ea8bf8cd11eb2ba0083d7880d4fd72ae686e7181836f3f0856935a301c743b /diff/usr/lib/.build-id/7b/dd85bb3ee35ad6bc3f707f7d3cf5b71bb37400 -> ../../../../usr/lib64/libncurses++.so.6.2 dangling: /var/lib/docker/overlay2/28ea8bf8cd11eb2ba0083d7880d4fd72ae686e7181836f3f0856935a301c743b /diff/usr/lib/.build-id/29/057d60c9ccb20db09d96a6d1b3812cd72b27b0 -> ../../../../usr/lib64/libncurses++w.so.6.2 dangling: /testbroke/test2 -> /badlinks-cleanx dangling: /etc/crypto-policies/back-ends/openssh-server.config -> /usr/share/crypto-policies/DEFAULT/openssh-server.txt dangling: /etc/systemd/system/sockets.target.wants/sssd-secrets.socket -> /usr/lib/systemd/system/sssd-secrets.socket dangling: /etc/systemd/system/local-fs.target.wants/fedora-readonly.service -> /usr/lib/systemd/system/fedora-readonly.service dangling: /etc/systemd/system/sysinit.target.wants/fedora-import-state.service -> /usr/lib/systemd/system/fedora-import-state.service dangling: /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket -> /usr/lib/systemd/system/lvm2-lvmetad.socket dangling: /etc/extlinux.conf -> ../boot/extlinux/extlinux.conf
Then there are some listed as messy: and other_fs:??
cut -f1 -d: <symlink-out | sort | uniq -c 35611 absolute 29 dangling 236 messy 56 other_fs
Learn new things all the time. Thanks.
On 16 Sep 2022 at 18:50, Patrick O'Callaghan wrote:
Subject: Re: Question on bad links? From: Patrick O'Callaghan pocallaghan@gmail.com To: users@lists.fedoraproject.org Date sent: Fri, 16 Sep 2022 18:50:30 +0100 Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On Sat, 2022-09-17 at 02:58 +1000, Michael D. Setzer II via users wrote:
Not clear on differnce be -l and -L?
They have completely different meanings:
'-xtype l' finds files which are themselves symlinks. That's what your script is doing. Nothing I can see in the script detects that those links are bad, just that they are links, i.e. it will detect good links as well, so you probably don't want to just remove them automatically.
'-L' means "follow symbolic links while descending the tree". The default for find is not to do this, as it can often mean searching outside the tree.
You might want to install the symlinks package:
Name : symlinks Version : 1.7 Release : 6.fc36 Architecture : x86_64 Size : 22 k Source : symlinks-1.7-6.fc36.src.rpm Repository : @System Summary : A utility which maintains a system's symbolic links URL : http://ibiblio.org/pub/Linux/utils/file/ License : Copyright only Description : The symlinks utility performs maintenance on symbolic links. Symlinks : checks for symlink problems, including dangling symlinks which point : to nonexistent files. Symlinks can also automatically convert : absolute symlinks to relative symlinks. : : Install the symlinks package if you need a program for maintaining : symlinks on your system.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
On Sat, 17 Sep 2022 10:43:45 +1000 "Michael D. Setzer II via users" users@lists.fedoraproject.org wrote:
Then there are some listed as messy: and other_fs:??
cut -f1 -d: <symlink-out | sort | uniq -c 35611 absolute 29 dangling 236 messy 56 other_fs
Learn new things all the time. Thanks.
Ditto. I wasn't aware of the program symlinks, now I am, new tool in the inventory.
On Sep 16, 2022, at 20:44, Michael D. Setzer II via users users@lists.fedoraproject.org wrote:
Was not aware of that program? Was already installed on my system. Following instructions from link, it found 279 of the broken links under /usr and after checking, I went ahead are removed them. Doing the run using / instead of /usr it comes up with the other 29 in various placed. That includes the one I created for test earlier, but is 28 I'll have to look into more. Using the symlink to fix the 279 seems good
Why do you care about broken symlinks again? What harm are they causing? Because looking at the following output makes me think you’re just going to break stuff.
dangling: /root/.mozilla/firefox/u3x6t962.default-release/lock -> 192.168.16.107:+945347
Firefox uses symlinks as a kind of lock file pointing to a running session. It’s not a broken symlink.
Although running Firefox as root is pretty bad. Stop.
dangling: /var/lib/docker/overlay2/e88368956b0fb3f25b2a8709be6b74dbdd936b76976b66dfe4756f1192b384e0/diff/bin/pidof -> /sbin/killall5
If you like destroying your docker containers, feel free to use these tools, but these are expected in a docker space.
dangling: /testbroke/test2 -> /badlinks-cleanx dangling: /etc/crypto-policies/back-ends/openssh-server.config -> /usr/share/crypto-policies/DEFAULT/openssh-server.txt dangling: /etc/systemd/system/sockets.target.wants/sssd-secrets.socket -> /usr/lib/systemd/system/sssd-secrets.socket dangling: /etc/systemd/system/local-fs.target.wants/fedora-readonly.service -> /usr/lib/systemd/system/fedora-readonly.service dangling: /etc/systemd/system/sysinit.target.wants/fedora-import-state.service -> /usr/lib/systemd/system/fedora-import-state.service dangling: /etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket -> /usr/lib/systemd/system/lvm2-lvmetad.socket
Systemd uses symlinks for unit activation dependencies. They should be cleaned up after but leaving them is unlikely to break anything.
dangling: /etc/extlinux.conf -> ../boot/extlinux/extlinux.conf Then there are some listed as messy: and other_fs:?? cut -f1 -d: <symlink-out | sort | uniq -c 35611 absolute 29 dangling 236 messy 56 other_fs Learn new things all the time. Thanks.
I saw earlier you were looking under /run, which is also a bad idea. Systemd uses symlinks in a similar way that Firefox did, to store metadata rather than point to an actual file.
I think it’s probably ok to run in /usr to find broken software but the OS uses symlinks in ways you might not understand, and you can break things. Avoid /run, /proc, /sys and other OS tmpfs volumes. I’d probably not delete any links in /etc either, unless you know exactly what it’s for.
-- Jonathan Billings
On 17/9/22 01:48, stan via users wrote:
On Fri, 16 Sep 2022 14:55:11 +1000 "Michael D. Setzer II via users" users@lists.fedoraproject.org wrote:
I've run this little script from time to time in /
find . -xtype l >/badlinks 2>ERR grep -v '/proc|/run' </badlinks >/badlinks-clean
At present ends up with other 300 lines in the badlinks-clean
Cleaned up a number of bad lines in a jre directory that seemed to be left over stuff from fc27 to fc33? Nothing from fc34?? and the reset were the currect fc35 files I have on system. Seems things that just got left??
Not sure if it is coming to have these on a system?
Wonder if someone with a lot more knowledge than I have might know best option. Just leave them, remove some, remove all? Figured the ones in /proc and /run should be left alone??
I don't have a lot more knowledge than you do, but a symbolic link that points to nothing, is broken, is useless. Anything that depends on finding what it expects at the end of the link is going to break. So, my opinion is that removing them is harmless. If your system is working correctly, then leaving them is also harmless, other than the cruft it represents, because they aren't being accessed (or you would be getting errors).
The proc / run links are temporary, in that the proc / run filesystem is created each boot, so deleting them is pointless. It doesn't make sense that there are all those broken links. Could the find be incorrect in some way? By that I mean that it is issuing false positives. When I run the command find /proc -L -type l | less or find /run -L -type l | less I get no broken links.
Just an FYI, I've issued ll /run/systemd/units and on my system that folder contains nothing but symlinks and everyone of them are pointing at files that don't exist. If these are created every boot, then what is FC36 doing wrong to create invalid symlinks?
regards, Steve
From the find man page for -type l, l symbolic link; this is never true if the -L option or the -follow option is in effect, unless the symbolic link is broken. If you want to search for symbolic links when -L is in effect, use -xtype.
So, using find /proc -L -type l returns true if a link is broken. Note that the default for find is -P, never follow symbolic links, which your command will use. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
users@lists.stg.fedoraproject.org