The Toolkit for Online Communities
18160 Community Members, 0 members online, 2330 visitors today
Log In Register
OpenACS Home : Forums : .LRN Q&A : Aolserver issue?

Forum .LRN Q&A: Aolserver issue?

Icon of envelope Request notifications

Posted by Mauricio Ramírez on
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?
2: Re: Aolserver issue? (response to 1)
Posted by Byron Linares on
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

3: Re: Aolserver issue? (response to 2)
Posted by Mauricio Ramírez on
Thank you for your answer, but there is no other service using that port. I used a pkill before trying to start aolserver.
4: Re: Aolserver issue? (response to 1)
Posted by Torben Brosten on
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.
5: Re: Aolserver issue? (response to 3)
Posted by Byron Linares on
execute "sudo ps aux|grep nsd" in a terminal shell to see if another aolserver process is running and kill it
6: Re: Aolserver issue? (response to 5)
Posted by Jacqueline Solís Céspedes on
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.