Description of problem: I've ran restraint against a RHEL-4 installation and the restraintd failed to start: Starting restraintd: execvp: No such file or directory [FAILED] Version-Release number of selected component (if applicable): restraint.i386 0:0.1.34-1.git.11.65d4e59.el4_8 How reproducible: 100% Steps to Reproduce: 1. Try to start restraintd on RHEL-4 Actual results: execvp: No such file or directory Expected results: starting up Additional info:
So one odd thing is that yum ends up installing: restraint-rhts.i386 restraint-rhts.x86_64 restraint.x86_64 which I guess is some yum inferior arch / multilib mess, similar to the problem we had on ia64 RHEL5 in bug 1328153. Not sure if that makes a difference though...
(In reply to Dan Callaghan from comment #2) Nope, that appears to be a non-issue. There is nothing in restraint-rhts aside from a bunch of noarch scripts and so forth. (In fact we should really make it a noarch subpackage, at least on RHEL6+ where that is allowed.) So the multilib support works fine, it is not breaking the init script. In /var/log/messages I think I found the real error: Jul 31 22:05:01 dev-kvm-guest-07 ((: execvp: No such file or directory The (( is a big hint... this does not appear on the console when the service fails to start for some reason. The init script has this: daemon --check $prog "(( $prog 3>&1 1>&2 2>&3 ) | tee /dev/console ) >> /var/log/restraintd.log 2>&1 &" There are some slight differences in how the "daemon" shell function is implemented on RHEL4 vs. RHEL5 (it's of course different in RHEL6 for upstart, and gone in RHEL7+ for systemd). The consequence seems to be on RHEL5 the command string *is* passed through a shell, and thus the whole construct with all its shell syntax works fine. Whereas on RHEL4 the command is executed directly. We can fix it by explicitly passing the command through bash -c. With this: daemon --check $prog "bash -c '(( $prog 3>&1 1>&2 2>&3 ) | tee /dev/console ) >> /var/log/restraintd.log 2>&1 &'" the init script can start restraintd successfully. On RHEL5 and RHEL6 this probably leads to one additional superfluous bash process hanging around but I am not too bothered by that. The "proper" solution back in the RHEL4-6 days is that you teach your daemon program how to double-fork and properly daemonize itself and write its own log files explicitly, etc... but we have avoided doing that because all that complexity is *not* needed under systemd. So I think just hacking it with extra shell wrappers for RHEL4-6 seems fine.
Indeed, on RHEL5 because of some tweaks in the "daemon" shell function, we currently get the following processes (you can see it is invoking the command through bash with "ulimit ... ;" prepended): 1 S root 30055 1 0 85 0 - 16495 wait 16:34 pts/0 00:00:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; (( restraintd 3>&1 1>&2 2>&3 ) | tee /dev/console ) >> /var/log/restraintd.log 2>&1 & 0 S root 30056 30055 0 85 0 - 8931 388677 16:34 pts/0 00:00:00 restraintd 0 S root 30057 30055 0 85 0 - 14737 pipe_w 16:34 pts/0 00:00:00 tee /dev/console With the proposed fixed, it still works. The inner bash backgrounds from the outer "ulimit ; ..." bash and then exits, so you get the same number of bashes. 1 S root 30111 1 0 83 0 - 16495 wait 16:35 pts/0 00:00:00 bash -c (( restraintd 3>&1 1>&2 2>&3 ) | tee /dev/console ) >> /var/log/restraintd.log 2>&1 & 0 S root 30112 30111 0 83 0 - 8931 498457 16:35 pts/0 00:00:00 restraintd 0 S root 30113 30111 0 83 0 - 14737 pipe_w 16:35 pts/0 00:00:00 tee /dev/console Same goes for RHEL6.
It looks like this probably regressed in: https://git.beaker-project.org/cgit/restraint/commit/?id=cd6c2914f7e0236a62984514959036c5a058ddfb which was *before any release of Restraint*, so it seems likely that Restraint has simply never worked at all on RHEL4...
https://gerrit.beaker-project.org/#/c/restraint/+/6238 But I would say, once 0.1.36 is released let's call it done for RHEL4 and stop supporting it after that.
I've spun up a RHEL 4 machine on beaker-devel with harness=restraint-rhts. The restraint daemon starts up. [root@dev-kvm-guest-10 ~]# service restraintd status restraintd (pid 3237) is running... /var/log/restraintd.log also contains standard restraint output. Marking as VERIFIED.
Restraint 0.1.36 was released on 24 August.