I’ve installed ruxit on a server that had InterWorx running. I had to restart all webservers to have ruxit monitor it, and that’s the last I’ve heard from InterWorx’ webserver.
[root@dev ~]# /usr/local/interworx/etc/init.d/iworx restart
Stopping InterWorx-web: [ OK ]
Stopping InterWorx-db: [ OK ]
Starting InterWorx-db: [ OK ]
Starting InterWorx-web: [ OK ]
/usr/local/interworx/etc/init.d/iworx: line 255: 5759 Segmentation fault $IWORXHOME/bin/ip.pex --bind-aliases 2> /dev/null
Binding IP Aliases: [FAILED]
/usr/local/interworx/etc/init.d/iworx: line 97: 5764 Segmentation fault $IWORXHOME/bin/ip6tables-control.pex --iptables-to-ip6tables
Has anyone else had this happen before? I’m gonna get to the bottom of this in the meantime.
Edit1: Found which line makes it segfault. From /usr/local/interworx/bin/decoder.sh (to which ip.pex is a symlink to), line 13
exec /home/interworx/bin/php -c /home/interworx/etc
basename $0 .pex.php “$@”
Edit2: I think I got it. I needed to copy /home/interworx/bin/php to /root and chmod 777 it, cause otherwise it refused to run inside of Valgrind. I remember that ruxit was messing about with SELinux, and this is what I got from Valgrind:
[root@dev ~]# valgrind ./php
==6487== Memcheck, a memory error detector
==6487== Copyright (C) 2002-2012, and GNU GPL’d, by Julian Seward et al.
==6487== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6487== Command: ./php
==6487==
vex amd64->IR: unhandled instruction bytes: 0x7 0x11 0x0 0x0 0x0 0x0 0x0 0x0
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==6487== Invalid read of size 1
==6487== at 0x5315002: ??? (in /usr/lib64/libc-client.so.2007)
==6487== by 0x4E33FB3: fclose (in /lib64/libruxitagentproc.so)
==6487== by 0xB82DE6E: ??? (in /lib64/libselinux.so.1)
==6487== by 0xB836CB5: ??? (in /lib64/libselinux.so.1)
==6487== by 0xB825FA2: ??? (in /lib64/libselinux.so.1)
==6487== Address 0x0 is not stack’d, malloc’d or (recently) free’d
==6487==
==6487==
==6487== Process terminating with default action of signal 11 (SIGSEGV)
==6487== Access not within mapped region at address 0x0
==6487== at 0x5315002: ??? (in /usr/lib64/libc-client.so.2007)
==6487== by 0x4E33FB3: fclose (in /lib64/libruxitagentproc.so)
==6487== by 0xB82DE6E: ??? (in /lib64/libselinux.so.1)
==6487== by 0xB836CB5: ??? (in /lib64/libselinux.so.1)
==6487== by 0xB825FA2: ??? (in /lib64/libselinux.so.1)
==6487== If you believe this happened as a result of a stack
==6487== overflow in your program’s main thread (unlikely but
==6487== possible), you can try to increase the size of the
==6487== main thread stack using the --main-stacksize= flag.
==6487== The main thread stack size used in this run was 10485760.
==6487==
==6487== HEAP SUMMARY:
==6487== in use at exit: 568 bytes in 1 blocks
==6487== total heap usage: 2 allocs, 1 frees, 688 bytes allocated
==6487==
==6487== LEAK SUMMARY:
==6487== definitely lost: 0 bytes in 0 blocks
==6487== indirectly lost: 0 bytes in 0 blocks
==6487== possibly lost: 0 bytes in 0 blocks
==6487== still reachable: 568 bytes in 1 blocks
==6487== suppressed: 0 bytes in 0 blocks
==6487== Rerun with --leak-check=full to see details of leaked memory
==6487==
==6487== For counts of detected and suppressed errors, rerun with: -v
==6487== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Segmentation fault
Edit3: Contrary to my suspicions, SELinux is not running.
[root@dev ~]# sestatus
SELinux status: disabled