Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an Apache 1.3 on a Sun machine (SunOS 5.10 Generic_138888-01 sun4u sparc SUNW,Sun-Fire-15000). If I keep the following two lines in httpd.conf, the server will not start:

LoadModule sm_module "/cmsm_sw/epiapr1/netegrity/webagent/bin/mod_sm.so"
SmInitFile "/apache/conf/WebAgent.conf"

This is all I get when I try to start Apache:

:/apache/bin # ./apachectl start
1392: CSemCounter created a semaphore with ID 1157627995 using key 989855746.

The mod_sm.so is the netegrity siteminder module (iPlanet).

Today there were some network issue (which were solved in the mean time) so I assume that this might have something to do. Maybe I should restart some services? I appreciate any help/hints.

Thank you.

share|improve this question
    
does apachectl configtest give any clues? –  Tim Kennedy Feb 2 '12 at 16:25
    
The configuration test works fine. It says "OK". Anyway, the issue was fixed and it seems that the cause was this: on the local machine there was a netegrity web agent that was communicating with a policy server (I believe iPlanet) and the communication from the policy to my server failed (hence the apaching hangs at startup when sisteminder .so module was loaded). It was solved with a restart of the policy server. I know, it was impossible to tell this without knowing the configuration. Anyway, thanks for your replies. –  Razvan Feb 2 '12 at 20:52
add comment

2 Answers

up vote 2 down vote accepted

Given the part of the message "semaphore with ID 1157627995 using key 989855746", I'd say this module uses SysV IPC primitives. Use the ipcs command to see how many semaphores, how many shared memory segments, etc exist. The network problems may have caused the module to create semaphores and not delete them. Or something. I seem to recall that a pretty low limit on number of semaphores and/or shared memory segments exist by default, so you may be running afoul of those limits.

share|improve this answer
add comment

It seems that, indeed, there was a network issue. Trying to telnet from the client machine to the server machine on port 44441 failed.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.