Hi all,
I have problems restarting ossec-remoted under Solaris 9. Note that I had
no problems starting it after I first installed ossec-hids.
shark# pwd
/var/ossec/bin
shark# ./ossec-control start
Starting OSSEC HIDS v0.9-1 (by Daniel B. Cid)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Completed.
shark# ./ossec-control status
ossec-logcollector is running...
ossec-remoted not running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...
shark# ls ../var/run
ossec-analysisd-21571.pid ossec-logcollector-21575.pid
ossec-remoted-21581.pid
ossec-execd-21567.pid ossec-maild-21563.pid
ossec-syscheckd-21587.pid
shark# ps -ef | grep remoted
root 21615 5061 0 12:34:57 pts/4 0:00 grep remoted
Each time it fails to start, I see this error logged...
shark# grep remoted ../logs/ossec.log | tail
2006/08/23 12:34:32 ossec-remoted: Started (pid: 21579).
2006/08/23 12:34:32 ossec-remoted: Started (pid: 21581).
2006/08/23 12:34:32 ossec-remoted(1210): Queue '/queue/alerts/ar' not
accessible.
shark# ls -lR ../queue/alerts
../queue/alerts:
total 0
srw-rw---- 1 root ossec 0 Aug 23 12:34 execq
Here, I remove the pid file and then do a "truss" (Solaris equivalent of
strace) on ossec-remoted...
shark# rm ../var/run/ossec-remoted-21581.pid
shark# truss /var/ossec/bin/ossec-remoted
output ends with...
fstat64(3, 0xFFBFEB58) = 0
brk(0x0005BE08) = 0
brk(0x0005FE08) = 0
fstat64(3, 0xFFBFEA00) = 0
ioctl(3, TCGETA, 0xFFBFEAE4) Err#25 ENOTTY
read(3, " y < o s s e c _ c o n f".., 8192) = 4325
brk(0x0005FE08) = 0
brk(0x00061E08) = 0
read(3, 0x0005BE14, 8192) = 0
llseek(3, 0, SEEK_CUR) = 4325
close(3) = 0
open64("/var/run/name_service_door", O_RDONLY) = 3
fcntl(3, F_SETFD, 0x00000001) = 0
door_info(3, 0xFF1C2728) = 0
door_call(3, 0xFFBFF748) = 0
brk(0x00061E08) = 0
brk(0x00063E08) = 0
door_info(3, 0xFFBFDB60) = 0
door_call(3, 0xFFBFDB48) = 0
getpid() = 21709 [21708]
sigprocmask(SIG_SETMASK, 0xFF0FA074, 0xFFBFFB90) = 0
fork1() = 21710
sigprocmask(SIG_SETMASK, 0xFFBFFB90, 0x00000000) = 0
lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFFBFFA64) = 0
_exit(0)
Same error logged...
shark# tail ../logs/ossec.log
2006/08/23 12:38:41 ossec-remoted: Started (pid: 21711).
2006/08/23 12:38:41 ossec-remoted: Started (pid: 21712).
2006/08/23 12:38:41 ossec-remoted(1210): Queue '/queue/alerts/ar' not
accessible.
shark# ls ../var/run
ossec-analysisd-21571.pid ossec-logcollector-21575.pid
ossec-remoted-21712.pid
ossec-execd-21567.pid ossec-maild-21563.pid
ossec-syscheckd-21587.pid
shark# rm ../var/run/ossec-remoted-21712.pid
Now, here's where things get very interesting. Running truss with a -f,
where:
-f Follows all children created by fork() or vfork() and
includes their signals, faults, and system calls in
the trace output. Normally, only the first-level com-
mand or process is traced. When -f is specified, the
process-id is included with each line of trace output
to indicate which process executed the system call or
received the signal.
shark# truss -f /var/ossec/bin/ossec-remoted
produces a heap of output, but it doesn't terminate. So, I kill truss with
a ctr/c and then see that all is as it should be..
shark# ./ossec-control status
ossec-logcollector is running...
ossec-remoted is running...
ossec-syscheckd is running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...
shark# ps -ef | grep remoted
root 21870 5061 0 12:43:12 pts/4 0:00 grep remoted
ossecr 21810 1 0 12:41:08 ? 0:00 /var/ossec/bin/ossec-remoted
shark# ls -lR ../queue/alerts
../queue/alerts:
total 0
srw-rw---- 1 ossecr ossec 0 Aug 23 12:41 ar
srw-rw---- 1 root ossec 0 Aug 23 12:34 execq
shark# tail ../logs/ossec.log
2006/08/23 12:41:08 ossec-remoted: Started (pid: 21808).
2006/08/23 12:41:08 ossec-remoted: Started (pid: 21810).
2006/08/23 12:41:10 ossec-remoted: Assigning counter for agent cam:
'3:7944'.
2006/08/23 12:41:10 ossec-remoted: Assigning counter for agent ccrjh:
'39:8870'.
2006/08/23 12:41:10 ossec-remoted: Assigning sender counter: 0:7920
This is consistent. A start will always fail; a simple truss will also fail
(to start ossec-remoted); a truss -f will succeed.
As I said at the start of this message, the problem did not arise when I
first started ossec-hids.
Does anyone have any idea what the heck's going on here?
Cheers,
Richard Hopkins,
University of Bristol
