11:55 p.m.
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/
+------------------------------------------------------------+
8:27 a.m.
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
10:48 a.m.
On Fri, 16 Sep 2022 14:55:11 +1000
"Michael D. Setzer II via users" <users(a)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.
11:58 a.m.
On 16 Sep 2022 at 8:48, stan wrote:
Date sent: Fri, 16 Sep 2022 08:48:29 -0700
From: stan <upaitag(a)zoho.com>
To: users(a)lists.fedoraproject.org
Copies to: mikes(a)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(a)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/
+------------------------------------------------------------+
12:50 p.m.
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
3:26 p.m.
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(a)gmail.com>
To: users(a)lists.fedoraproject.org
Date sent: Fri, 16 Sep 2022 18:50:30 +0100
Send reply to: Community support for Fedora
users <users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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/
+------------------------------------------------------------+
3:49 p.m.
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/#Resol...
which is the dnf system upgrade page
David
On Sat, 17 Sep 2022 06:26:54 +1000
users(a)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(a)gmail.com>
To: users(a)lists.fedoraproject.org
Date sent: Fri, 16 Sep 2022 18:50:30 +0100
Send reply to: Community support for Fedora
users <users(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/
+------------------------------------------------------------+
7:43 p.m.
On 16 Sep 2022 at 15:49, dwoodyard(a)rdwoodyard.com
wrote:
Date sent: Fri, 16 Sep 2022 15:49:27 -0500
From: "dwoodyard(a)rdwoodyard.com"
<dwoodyard(a)rdwoodyard.com>
To: mikes(a)guam.net, Community support for
Fedora users
<users(a)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/#Resol...
which is the dnf system upgrade page
David
On Sat, 17 Sep 2022 06:26:54 +1000
users(a)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(a)gmail.com>
> To: users(a)lists.fedoraproject.org
> Date sent: Fri, 16 Sep 2022 18:50:30 +0100
> Send reply to: Community support for Fedora
> users <users(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)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/
+------------------------------------------------------------+
9:31 a.m.
On Sat, 17 Sep 2022 10:43:45 +1000
"Michael D. Setzer II via users" <users(a)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.
9:53 a.m.
On Sep 16, 2022, at 20:44, Michael D. Setzer II via users
<users(a)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
12:35 a.m.
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(a)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.
--
Jon H. LaBadie jonfu(a)jgcomp.com
1:11 a.m.
On 20 Sep 2022 at 1:35, Jon LaBadie wrote:
Date sent: Tue, 20 Sep 2022 01:35:02 -0400
From: Jon LaBadie <jonfu(a)jgcomp.com>
To: users(a)lists.fedoraproject.org
Subject: Re: Question on bad links?
Send reply to: Community support for Fedora
users <users(a)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(a)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(a)jgcomp.com
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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/
+------------------------------------------------------------+
5:39 a.m.
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.
--
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.
6:44 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
8:01 p.m.
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.
9:23 p.m.
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.
--
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.
9:44 p.m.
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.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
12:29 a.m.
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?
--
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.
8:05 a.m.
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.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
3:53 p.m.
On 19 Sep 2022, at 06:30, Tim via users
<users(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
9:20 p.m.
On 9/19/22 3:53 PM, Barry wrote:
> On 19 Sep 2022, at 06:30, Tim via users <users(a)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.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
9:59 p.m.
Once upon a time, Robert Nichols <rnicholsNOSPAM(a)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.
--
Chris Adams <linux(a)cmadams.net>
5:46 a.m.
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.
--
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.
5:55 a.m.
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
6:09 a.m.
On Tue, Sep 20, 2022 at 7:55 AM Patrick O'Callaghan <pocallaghan(a)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).
--
George N. White III
6:40 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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
10:26 p.m.
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.
591
days inactive
595
days old
26 comments
13 participants
participants (13)
-
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