Ah, I've seen this once. It was debugged down an issue with the OS itself. As it was only once, we suspected something specific to that box.
If there are more reports, then there's more to it.
For general reference, the ticket in this case is #36411, also using Alma Linux 8.
We narrowed it down to this bug:
We are running: Red Hat Enterprise Linux release 8.5 (Ootpa). We allow the server to update weekly using "yum -y update". We recently began receiving the following errors when executing...
unix.stackexchange.com
and it creeps into the dump of the direct_crons=1 (which everyone uses), where the data/users/fred/crontab.conf is filled based on `crontab -u fred -l`, but only seems to show up when a specific variation of the ENV is used, so duplicating it from the shell was unsuccessful.
I believe it's related to this file:
Where the ENV DA is using when the crontab.conf rewrite happens contains:
Code:
0: BASH_FUNC_which%%=() { ( alias
...
25: which_declare=declare -f
If you type:
in the shell, you'd see the similar thing:
Code:
BASH_FUNC_which%%=() { ( alias; eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@" }
where it seems to be some sort of dynamic function feature, all preceded by BASH_FUNC_... where something about it isn't working correctly.
Now that there's other reports, I've added a
temporary workaround to just filter out any crontab output lines that start with "sh: ".
By temporary, I've set a date of June 2022 to remove the code, so AlmaLinux should have definitely sorted it out by then, as I really don't like adding extra complexity to DA code for other bugs, but the DA filtering with at least suppress the issue for now.
Reports on the above URL state that updating the system again should resolve it, but does clarify exactly which steps were taken.
I can speculate that you'd need to:
- Update your system with yum, and confirm that the /etc/profile.d/which2.sh has changed.. assumingly to include the } on the same line.
- You might need to login to ssh fresh to get the latest ENV vars loaded and restart DA so it gets the new ENV.
- Worst case, reboot the box to purge all instances of the bad ENV.
In any case, I've completed the workaround in DA, the alpha binaries should be up after the daily run (we only do it once a day now).
So if you'd like the workaround/fitler, wait until tomorrow, switch to the alpha update channel in your Licenses/Updates page, and grab those binaries. The next time the crontab.conf is re-written (eg: try full ./build rewrite_confs), it should filter out that output.
The other reported workaround solution was to add:
to your /etc/bashrc, start a new shell (run "bash") and restart directadmin. The restart
might not be required as the crontab call does trigger a fresh shell, but it's plausible that the old ENV vars DA already has might need to be purged. I'm not sure what that affects though, so might be a bit of an agressive hack, in case something needs the "which" function/alias they've setup.
Hopefully this gets everyone affected moving in the right direction. The main solution is to update the box with yum to get a proper fix.. and then flush the env.. likely with a fresh ssh login and DA restart. (reboot if required).
John
