Thanks. I thought of removing /sbin and /bin from the path but without the links what if something is looking for /sbin/ProgramA or /bin/ProgramB it's not going to find them. And, I would have to do that and how would I do that so that /sbin and /bin are not in the PATH at boot? Done globally that could brick the boot and if I were to how wouId do that for only amavisd and then some update could reverse it. I don't get this, if this is a bug i.e. it's kinda like WoW! -Curt On 6/25/24 17:17, Bob Rogers wrote:
From: Curtis J Blank <curt@curtronics.com> Date: Tue, 25 Jun 2024 16:46:17 -0500
Here's the PATH and each of directories in the PATH's permissions. I wonder if it choking on the permissions of the links?
It shouldn't, because link permissions can only revoke bits (IIRC), rather than grant additional ones.
PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin"
lrwxrwxrwx 1 root root 8 Dec 8 2023 /sbin -> usr/sbin . . . lrwxrwxrwx 1 root root 7 Dec 8 2023 /bin -> usr/bin
Odd that /bin and /sbin are symbolic links; odder still that they are links to other standard program directories, since both pairs ought to exist. Oddest of all that they are expressed as relative pathnames.
Which might be the case because on the server that is working /sbin and /bin are *not* links . . .
On the off chance that it's choking on the fact that they are relative links, you could try using a PATH without /bin and /sbin, since (as you've shown) these two directories are redundant. Really, that shouldn't matter, since relative link targets are interpreted with respect to the link directory. So if it works, that would have to be a bug in that version of Perl. But since it's a real difference you've found between the two installations, it could be worth a try.
-- Bob