Forum .LRN Q&A: Aolserver issue?

Collapse
1: Aolserver issue?
Posted by Mauricio Ramírez on 03/06/12 03:58 PM
Hello, we are having a problem with aolserver4.
After migrate from dotlrn 2.4 to 2.5, the service was working fine; but yesterday something really weird started to happend.
Network conections are fine, aolserver is alive, but the services just stop and we can't access the website.
There is no changes on aolserver configuration file, or dotlrn config file... and there is no failure logs. ("pings" to both IP's are answering,too)
Today, the services don't want to take the 80 port and this is a critical services for the university, we realice that after made a change un acs-subsite (changes like delete white spaces which always be there) the system at least try to be up.
Can anyone help me? or refers me to someone who had a problem like this?
Collapse
2: Re: Aolserver issue? (response to 1)
Posted by Byron Linares on 03/06/12 07:47 PM
maybe in your system there is another service that is using port 80 which does not allow start aolserver

look for messages in the error.log or in the system log

Collapse
3: Re: Aolserver issue? (response to 2)
Posted by Mauricio Ramírez on 03/06/12 09:00 PM
Thank you for your answer, but there is no other service using that port. I used a pkill before trying to start aolserver.
Collapse
4: Re: Aolserver issue? (response to 1)
Posted by Torben Brosten on 03/06/12 09:09 PM
If you also upgraded aolserver, check the config.tcl defaults for the new version against the version you are using. Perhaps there is a configuration issue.
Collapse
5: Re: Aolserver issue? (response to 3)
Posted by Byron Linares on 03/06/12 11:08 PM
execute "sudo ps aux|grep nsd" in a terminal shell to see if another aolserver process is running and kill it
Collapse
6: Re: Aolserver issue? (response to 5)
Posted by Jacqueline Solís Céspedes on 03/11/12 02:31 AM
Hello Torben and Byron, thank you both of you for your help.
We only changed the amount of sockets and we kill nsd before each restart.
After many days of retries, we found a weird behavior on network interfaces and temporaly fixed it restarting them.
It looks like this fixed the port problem, too.