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 Sat, Sep 17, 2022 at 10:53:53AM -0400, Jonathan Billings wrote:
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.
Wish there was a better term than "BROKEN" for symlinks whose target does not currently exist. There certainly are use cases for symlinks that point to files "when they are available".
My backup software uses virtual tapes (vtapes) and a virtual tape changer. My changer has 240 symlink "slots". The vtapes are on removable disks. If a disk is in offsite storage, or is otherwise not mounted, an entire group of "slots" are broken symlinks. But that is not an error, those slots are just "empty".
I'd hate for some nimwit* admin to remove those broken symlinks.
Jon
* It would be like the time a nimwit admin of a multi-user computer (300 users) came home from a security class learning that "setuid programs were bad". Over the weekend they used chmod to remove the setuid bit of every program on the system. Resulted in a few problems Monday morning.
On 20 Sep 2022 at 1:35, Jon LaBadie wrote:
Date sent: Tue, 20 Sep 2022 01:35:02 -0400 From: Jon LaBadie jonfu@jgcomp.com To: users@lists.fedoraproject.org Subject: Re: Question on bad links? Send reply to: Community support for Fedora users users@lists.fedoraproject.org
On Sat, Sep 17, 2022 at 10:53:53AM -0400, Jonathan Billings wrote:
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.
Wish there was a better term than "BROKEN" for symlinks whose target does not currently exist. There certainly are use cases for symlinks that point to files "when they are available".
symlinks actually refers to them ad dangling... man symlinks gives more info
Each link is output with a classification of relative, absolute, dangling, messy, lengthy, or other_fs.
saw one thing that showd using it on /usr symlinks -r /usr That just displays what it finds. symlinks -rcsd /usr Seems to be the extreme to delete dangling and change message and lengthy ones.
Don't want to mess with the ones in /proc or /run
symlink -r / reports others that might exist, but would be careful on updating them, and work do individual directories.
On this system I get. symlinks -r / | cut -f1 -d: | sort | uniq -c 490 absolute 23 dangling 1 messy 56 other_fs
Was getting like 321 badlinks listed but elimanating from listing ones with /run /proc or docker I get these.
./root/.mozilla/firefox/u3x6t962.default-release/lock ./home/msetzerii/.mozilla/firefox/bkk7du3z.default-1642065035746/lock ./etc/extlinux.conf
The .mozilla ones were mentioned in a message as being similar to what is done in the /run /proc and docker ones. The /etc/extlinux.conf just seems to be a broken one???
Don't know if fixing the messy or lengthy ones makes a real difference, but seems cleaner if nothing else.
My backup software uses virtual tapes (vtapes) and a virtual tape changer. My changer has 240 symlink "slots". The vtapes are on removable disks. If a disk is in offsite storage, or is otherwise not mounted, an entire group of "slots" are broken symlinks. But that is not an error, those slots are just "empty".
I'd hate for some nimwit* admin to remove those broken symlinks.
Jon
- It would be like the time a nimwit admin of a multi-user
computer (300 users) came home from a security class learning that "setuid programs were bad". Over the weekend they used chmod to remove the setuid bit of every program on the system. Resulted in a few problems Monday morning.
-- Jon H. LaBadie jonfu@jgcomp.com _______________________________________________ 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 Tue, 2022-09-20 at 01:35 -0400, Jon LaBadie wrote:
like the time a nimwit admin of a multi-user computer (300 users) came home from a security class learning that "setuid programs were bad". Over the weekend they used chmod to remove the setuid bit of every program on the system. Resulted in a few problems Monday morning.
That reminds me of the day I discovered my website completely broken. The hosting service had removed the X bit off every file, destroying how Apache makes use of the X bit for knowing it has to parse a HTML file instead of server it as-is.
They claimed to have done nothing, but it didn't do it by itself. My guess would be that they changed drives on a system and migrated the files without applying due thought.
On a website with many thousands of files it was a major pain to restore, especially as not all HTML files needed the X bit set.
Every now and then they break something new. They swapped Apache for LightSpeed, and despite its claims as a drop-in replacement, it is not. There are things it does differently, or cannot do. First I discovered it messed up mod rewrite, later on the auto-index feature.
These days I have low regard for people with "qualifications," or even longevity in a job. Neither really mean that they know what they're doing, or are any good at it. They may do, but those things, alone, are not proof.
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
On 9/18/22 16:44, Stephen Morris wrote:
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?
As Jonathan mentioned in a previous reply, systemd is using symlinks for temporary data storage, like a dictionary or map depending on which programming language you're using.
On Sun, 2022-09-18 at 18:01 -0700, Samuel Sieb wrote:
As Jonathan mentioned in a previous reply, systemd is using symlinks for temporary data storage, like a dictionary or map depending on which programming language you're using.
Kinda wierd. I wonder what the advantage is over creating symlinks versus creating files? At least with files you can put data in them.
On 9/18/22 9:23 PM, Tim via users wrote:
On Sun, 2022-09-18 at 18:01 -0700, Samuel Sieb wrote:
As Jonathan mentioned in a previous reply, systemd is using symlinks for temporary data storage, like a dictionary or map depending on which programming language you're using.
Kinda wierd. I wonder what the advantage is over creating symlinks versus creating files? At least with files you can put data in them.
With a symlink, that "data" is the string that shows as the symlink target. The advantage over a tiny file is that if the string is short enough to fit within the inode structure, no data block on the disk needs to be allocated. That's faster and more efficient than creating a file since the inode needs to be set up and written in any case. systemd is far from the first program to take advantage of this.
On Sun, 2022-09-18 at 21:44 -0500, Robert Nichols wrote:
With a symlink, that "data" is the string that shows as the symlink target. The advantage over a tiny file is that if the string is short enough to fit within the inode structure, no data block on the disk needs to be allocated. That's faster and more efficient than creating a file since the inode needs to be set up and written in any case. systemd is far from the first program to take advantage of this.
Interesting. What about the old running out of inodes on a disc problem? How did they handle that?
On 9/19/22 12:29 AM, Tim via users wrote:
On Sun, 2022-09-18 at 21:44 -0500, Robert Nichols wrote:
With a symlink, that "data" is the string that shows as the symlink target. The advantage over a tiny file is that if the string is short enough to fit within the inode structure, no data block on the disk needs to be allocated. That's faster and more efficient than creating a file since the inode needs to be set up and written in any case. systemd is far from the first program to take advantage of this.
Interesting. What about the old running out of inodes on a disc problem? How did they handle that?
The symlink is using _one_ inode, which is also the number that would be needed for that tiny file. Creating lots of tiny files will also cause the filesystem to run out of inodes long before it runs out of data blocks.
On 19 Sep 2022, at 06:30, Tim via users users@lists.fedoraproject.org wrote:
On Sun, 2022-09-18 at 21:44 -0500, Robert Nichols wrote:
With a symlink, that "data" is the string that shows as the symlink target. The advantage over a tiny file is that if the string is short enough to fit within the inode structure, no data block on the disk needs to be allocated. That's faster and more efficient than creating a file since the inode needs to be set up and written in any case. systemd is far from the first program to take advantage of this.
Interesting. What about the old running out of inodes on a disc problem? How did they handle that?
I would assume that the file system is created with lots of inodes so it is never a problem in practice.
Barry
--
uname -rsvp Linux 3.10.0-1160.76.1.el7.x86_64 #1 SMP Wed Aug 10 16:21:17 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
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
On 9/19/22 3:53 PM, Barry wrote:
On 19 Sep 2022, at 06:30, Tim via users users@lists.fedoraproject.org wrote:
On Sun, 2022-09-18 at 21:44 -0500, Robert Nichols wrote:
With a symlink, that "data" is the string that shows as the symlink target. The advantage over a tiny file is that if the string is short enough to fit within the inode structure, no data block on the disk needs to be allocated. That's faster and more efficient than creating a file since the inode needs to be set up and written in any case. systemd is far from the first program to take advantage of this.
Interesting. What about the old running out of inodes on a disc problem? How did they handle that?
I would assume that the file system is created with lots of inodes so it is never a problem in practice.
It's a problem that crops up occasionally, and makes people wonder why they get a "No space on filesystem" error when the df command shows that plenty of space is available. That's why the df command has a "-i" option to report inode usage. A filesystem that's being used for things like a news spool, which holds lots of small files, needs to be created with more than the default allocation of inodes.
Once upon a time, Robert Nichols rnicholsNOSPAM@comcast.net said:
It's a problem that crops up occasionally, and makes people wonder why they get a "No space on filesystem" error when the df command shows that plenty of space is available. That's why the df command has a "-i" option to report inode usage. A filesystem that's being used for things like a news spool, which holds lots of small files, needs to be created with more than the default allocation of inodes.
Heh, I haven't run a Usenet server in just over 23 years, but even then, server software was moving away from the file-per-article storage to avoid this issue (and others).
Mail servers, on the other hand, were jumping to the file-per-message method just as fast as Usenet servers discarded it, and are still using it.
On Mon, 2022-09-19 at 21:59 -0500, Chris Adams wrote:
Mail servers, on the other hand, were jumping to the file-per-message method just as fast as Usenet servers discarded it, and are still using it.
I certainly noticed a massive improvement when I went from mail spool files to maildir on Dovecot.
I can see the thinking behind using links as flags as opposed to files with just a few bytes of data in them. Though I think it wouldn't work well with large configuration files being done that way, and I couldn't see them being very human-friendly.
On Tue, 2022-09-20 at 20:16 +0930, Tim via users wrote:
On Mon, 2022-09-19 at 21:59 -0500, Chris Adams wrote:
Mail servers, on the other hand, were jumping to the file-per- message method just as fast as Usenet servers discarded it, and are still using it.
I certainly noticed a massive improvement when I went from mail spool files to maildir on Dovecot.
Indeed. The old mbox format has a number of disadvantages. Expunging deleted messages can mean copying a large file, which is a) slow and b) may not succeed if the user doesn't have enough space. This would tend to happen precisely when the user noticed his quota running out and wanted to expunge deleted files to recover space. Oh, the irony :-)
They also require a locking mechanism, which could be problematic with NFS-mounted mailboxes. Maildir largely eliminates these issues.
poc
On Tue, Sep 20, 2022 at 7:55 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2022-09-20 at 20:16 +0930, Tim via users wrote:
On Mon, 2022-09-19 at 21:59 -0500, Chris Adams wrote:
Mail servers, on the other hand, were jumping to the file-per- message method just as fast as Usenet servers discarded it, and are still using it.
I certainly noticed a massive improvement when I went from mail spool files to maildir on Dovecot.
Indeed. The old mbox format has a number of disadvantages. Expunging deleted messages can mean copying a large file, which is a) slow and b) may not succeed if the user doesn't have enough space. This would tend to happen precisely when the user noticed his quota running out and wanted to expunge deleted files to recover space. Oh, the irony :-)
They also require a locking mechanism, which could be problematic with NFS-mounted mailboxes. Maildir largely eliminates these issues.
Back when pine was popular I had to migrate a bunch of mbox files from an external service to users' Windows PCs with pine. There were lots if AV hits, each requiring splitting up the mbox files in order to remove offending messages (mostly attached Word documents).
On 19/9/22 11:01, Samuel Sieb wrote:
On 9/18/22 16:44, Stephen Morris wrote:
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?
As Jonathan mentioned in a previous reply, systemd is using symlinks for temporary data storage, like a dictionary or map depending on which programming language you're using.
I can understand systemd using symlinks for temporary data, but when the data is removed why isn't the symlink, or is it the situation that the data is not really gone, it is just being flagged as gone because it is not a directory or file?
regards, Steve
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
On 2022-09-19 16:40, Stephen Morris wrote:
On 19/9/22 11:01, Samuel Sieb wrote:
On 9/18/22 16:44, Stephen Morris wrote:
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?
As Jonathan mentioned in a previous reply, systemd is using symlinks for temporary data storage, like a dictionary or map depending on which programming language you're using.
I can understand systemd using symlinks for temporary data, but when the data is removed why isn't the symlink, or is it the situation that the data is not really gone, it is just being flagged as gone because it is not a directory or file?
The data isn't removed, the symlink *is* the data.
-
Barry -
Chris Adams -
dwoodyard＠rdwoodyard.com -
George N. White III -
Jon LaBadie -
Jonathan Billings -
Michael D. Setzer II -
Patrick O'Callaghan -
Robert Nichols -
Samuel Sieb -
stan -
Stephen Morris -
Tim