On 16 Sep 2022 at 8:48, stan wrote:
Date sent: Fri, 16 Sep 2022 08:48:29 -0700
From: stan <upaitag@xxxxxxxx>
To: users@xxxxxxxxxxxxxxxxxxxxxxx
Copies to: mikes@xxxxxxxx
Subject: Re: Question on bad links?
Organization: zohofree
> On Fri, 16 Sep 2022 14:55:11 +1000
> "Michael D. Setzer II via users" <users@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx
mailto:msetzerii@xxxxxxxxx
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
