On 8/26/18 5:49 AM, David C. Rankin wrote:
On 08/26/2018 03:37 AM, Ralph Corderoy wrote:
Testing manually works fine:
# ./phb.php It's not getting that far.
I bet you would as root. The file is actually http:http owned, e.g.
-rwxr-xr-x 1 http http 988 Sep 14 2016 /srv/http/avantfax/includes/phb.php
So running as root has no problem. Running as any other user (other than http) now invokes the error that is the basis for this thread. That's why it is hard to put my finger on the cause, unless the linux-firmware update tightened security in some manner so that the cron user no longer can run as http causing the job to fail.
That's literally not how Linux permissions work. In fact, I'm not aware of any operating system on which that *is* how file permissions work. You did not get a "permission denied" error. You got a "failed to exec /etc/cron.hourly/avantfax_hourly: Exec format error". And thusly, you're completely missing Ralph's point here. The error message states "failed to exec /etc/cron.hourly/avantfax_hourly". It is saying the *file* avantfax_hourly is itself the invalid executable file. Which makes sense because "run-parts runs all the executable files named within constraints described below, found in directory directory." Why do you think run-parts "should" execute this file as a cron script? Is there some wonderful shebang in the "avantfax_hourly" file which says "execute this script as a cron executable"?
If you (as root, or http) call /srv/http/avantfax/includes/phb.php, it will silently run normally and exit with a 0 exit code. Running with any other user cause about 100 fopen (foo/bar/...) messages to scroll by and a returned exit code of 1.
That sounds like a completely different problem, since by executing the .php file you actually execute the php file, whereas by executing the crontab(5) file you get a case where programs determine on their own how to treat an executable file, in this case by failing to find a shebang line or an ELF header and complaining that it isn't a valid executable -- I will note that this actually uses execl/execve to directly execute the file, returning ENOEXEC *because it doesn't have a valid shebang* and does not use execlp/execvp which emulate shells like sh/csh/ksh/bash/zsh in attempting to fall back on executing the shell /bin/sh with the executable file as the first argument. ... In summary, if you tried to execute /etc/cron.hourly/avantfax_hourly rather than run-parts /etc/cron.hourly/avantfax_hourly, you would get the entirely different effect of it attempting to fallback on executing /bin/sh /etc/cron.hourly/avantfax_hourly, then failing with a return code of 1: /etc/cron.hourly/avantfax_hourly: line 2: 0: command not found Because the "0" in that cron invocation is not, in fact, valid as the argv0 of a shell command.
I have run this server for years and years, no problems, until today after updates. I changed nothing on the system other than 'pacman -Syu'. That what has me bewildered...
Color me equally bewildered, since the manpage of run-parts(1) emphatically declares that this shall never, ever, ever work under any conditions whatsoever. I'm assuming that you're running anacron, not run-parts. anacron will in fact run, on an hourly schedule, all executables in /etc/cron.hourly/ and will use run-parts (which is designed to "execute all executables in a directory") to, well, execute all executables in that directory. anacron, is a thing which is configured using a valid crontab(5) containing cron invocations... to run `run-parts /etc/cron.hourly/` Once again, your attempt to install crontabs as executables is the problem here. Unless you either misremembered the events of the day when you stated "I changed nothing on the system other than 'pacman -Syu'", or your -Syu updated a program that of its own volition used to execute anacron and now executes run-parts, I don't see what the issue is here. But I'm pretty sure casting the blame on CPU microcode updates is pretty darn erroneous no matter what. I think you changed something long before that, then compared the time when anacron was scheduled to begin running your invalid file, to the time you did an -Syu, and somehow decided that the two were related. They are not. If you change something, and anacron breaks, but anacron does't run until an hour later by which point you've already -Syu'ed again and updated linux-firmware, it's... understandable that the timestamps for a program designed for *delayed execution* would match up to something completely and utterly irrelevant. Mind you, this is just a guess. The only thing I know for sure is that your real problem is exactly what Ralph said it was. You're installing a crontab designed to run every hour, into a location meant to be run as an executable (by anacron which runs every hour). Please re-read the cron(8), anacron(8), and crontab(5) manpages to see where you went wrong. -- Eli Schwartz Bug Wrangler and Trusted User