Hi Daniel,
Thanks for this. I gave it a go...
With it running:
shark# pwd
/var/ossec/bin
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...
I stopped it:
shark# ./ossec-control stop
Killing ossec-logcollector ..
Killing ossec-remoted ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
Killing ossec-execd ..
OSSEC HIDS v0.9-1 Stopped
Checked and saw that the "ar" file was still present:
shark# ls ../queue/alerts
ar execq
Removed it and checked that it was gone:
shark# rm ../queue/alerts/ar
shark# ls ../queue/alerts
execq
Restarted:
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.
Checked its status:
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...
Checked that ossec-remoted really wasn't running:
shark# ps -ef | grep remoted
root 7586 626 0 15:41:26 pts/4 0:00 grep remoted
Same error logged:
2006/08/25 15:40:50 ossec-remoted: Started (pid: 7553).
2006/08/25 15:40:50 ossec-remoted: Started (pid: 7555).
2006/08/25 15:40:50 ossec-remoted(1210): Queue '/queue/alerts/ar' not
accessible.
I just tried (with it stopped) removing and recreating the queue/alerts
directory but with the same startup problem.
(truss -f to the rescue)
Is there anyone out there running a server installation under Solaris 9 who
isn't having this problem (is there anyone out there....having this same
problem)?
Cheers,
Richard
--On 25 August 2006 10:35 -0300 Daniel Cid <[EMAIL PROTECTED]> wrote:
Hi Richard,
This is weird. Basically, when you get this error "Queue
'/queue/alerts/ar' not
accessible" it means that remoted wasn't able to create the socket. Can
you remove "/var/ossec/queue/alerts/ar" and try to start ossec again?
Make sure that before you start the file is not there...
*Yes, I have no clue what may be going on.. :)
--
Daniel B. Cid
dcid ( at ) ossec.net
On 8/23/06, Richard Hopkins <[EMAIL PROTECTED]> wrote:
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
Richard Hopkins,
Information Services,
Computer Centre,
University of Bristol,
Bristol, BS8 1UD, UK
Tel +44 117 928 7859
Fax +44 117 929 1576
