HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   General (http://www.howtoforge.com/forums/forumdisplay.php?f=25)
-   -   Problems with Monitor and DNS since upgrade (http://www.howtoforge.com/forums/showthread.php?t=56317)

drapsag 25th February 2012 18:36

Problems with Monitor and DNS since upgrade
 
Running ISPConfig 3.0.4.3 on two servers (master/slave). Both servers are running Squeeze and are currently up to date.

Since upgrading from 3.0.4.2 to 3.0.4.3 my system monitor quit updating. Nothing updates at all in any of the system monitor tab. Might be related to the following bug:

http://bugtracker.ispconfig.org/inde...s&task_id=2054

So, I will assume it is and leave it at that until the next update.

More importantly, since the update, changes in ISPConfig to any DNS Zone will not update the zone files on either server. I have to manually go into both servers and add the changes by hand and restart BIND9 to affect the changes.

Everything had been working fine before the update and everything else is working fine but not being unable to add DNS records in ISPConfig3 is a pain. I have changed nothing in either server configuration wise in quite a while.

falko 26th February 2012 12:09

I've added this to our bugtracker, so we will check that.

till 27th February 2012 09:31

Quote:

More importantly, since the update, changes in ISPConfig to any DNS Zone will not update the zone files on either server. I have to manually go into both servers and add the changes by hand and restart BIND9 to affect the changes.
DNS updates work fine here with 3.0.4.3, on new installed servers as well as on updated systems. You might want to check whats wrong on your servers by debugging the server process:

http://www.faqforge.com/linux/debugg...-of-a-failure/

drapsag 28th February 2012 18:25

The only thing that shows up in the Debug log in both ISPConfig and on the command line is:

There is already an instance of server.php running. Exiting.

This is in both server's logs and command line and it happens over and over again.

till 29th February 2012 10:58

Delete the ispconfig lock file and run the command again:

rm -f /usr/local/ispconfig/server/temp/.ispconfig_lock

and then run

/usr/local/ispconfig/server/server.sh

drapsag 29th February 2012 14:58

Ok, that worked. Sort of.

Now when I run the server.sh from a command line, this commits all the changes that have been queued up in the Jobqueue, so that's good. There are no errors.

But, when I make more changes in the panel, they stay in the Jobqueue uncommitted until I go back into the command line and run the server.sh command again. I don't see any errors in the System-Log nor do I get any errors when I run the command from the command line.

And, my System Monitor is still not working. No updates since I upgraded to 3.0.4.3 on the 13th of Feb.

till 29th February 2012 15:08

This indicates that cron is not working on your server as the server.sh script is normally executed by cron once a minute. Please check that cron is installed and started and that you enabled the cronjob in the root crontab again after your tests.

drapsag 29th February 2012 16:05

cron is running.

service cron status on both servers gives me:

Checking periodic command scheduler...done (running).

The cronjob is (re)enabled in crontab.

Still no updates and jobs sit in the Jobqueue in ISPConfig.

Not sure what to do from here.

till 29th February 2012 16:12

Check the syslog in /var/log, if cron is running correctly, you should see a record once a minute about the excution of the ispconfig server.sh cronjob. If you dont see them, then you have a problem with cron as ispconfig works correctly when you execute it manually.

drapsag 29th February 2012 20:30

When I tail the syslog, I can see cron running the server.sh shell every minute with the following message:

There is already an instance of server.php running. Exiting.

If I rm the lock file, the script will run from the command line over and over again but when I add a new job in ISPconfig, it still sits in the Jobqueue.

Then when I ssh back into the command line and try to run the script, I get the same error: There is already an instance of server.php running. Exiting.

It's like the script isn't removing the lock file.


All times are GMT +2. The time now is 19:22.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.