ISP Services wouldn't restart any service, possibly Domain Host configuration issue.

I am experiencing problem changing status of a service in ISP Services, it wouldn't restart any service listed in ISP Services. As I don't know what is the problem I have mentioned three symptoms and trying symptomatic approach. Please advise, your help will be much appreciated.

Symptom 1:
When I change a service value to Restart which was previously On and click on Save, it refreshes the page but the status keeps displaying Restart all the time until I change it back to On and save it again. I believe this is not working and not really restarting the services.

Only thing I can think of can possibly be the domain name and host name configuration as this is the only thinkg I changed in past at some point.

Symptom 2:
They way i have configured domain name is below, can anyone please confirm if this is correct configuration.

DNS points portal.domainname.com to my Public IP Address.
Unix hostname I have configured as is portal.domainname.com
/etc/hosts contains "192.168.0.1 portal.domainname.com"
- (Not sure if I should specify public IP Address anywhere in hosts or ISPConfig?)
ISP Config Server Settings Domain is portal.domainname.com while hostname is default as www with IP Address as 192.168.0.1.
- (Not sure if it should be portal and domain should be domainname.com?)

Symptom 3:
Also if I try using with a hosted domain or IP address like https://www.blahblah.com:81/ instead of https://portal.domainname.com:81/, I cannot use anything i Management part of ISP Config, everythig else works.

 

Which distribution do you use? Are there errors in /home/admispconfig/ispconfig/ispconfig.log?

Only thing I can think of can possibly be the domain name and host name configuration as this is the only thinkg I changed in past at some point.

This seems to be correct. Don't use the public IP address because you're behind a router.

Use portal as hostname and domainname.com as domain.

Have a look here: http://www.howtoforge.com/forums/showthread.php?t=534

 

No errors in log and still can't restart services.

I am using Fedora Core 4 and do not see any errors in log file. When I change the service to Restart all I see in Log file is as below.

14.02.2006 - 13:37:27 => INFO - Signalfile Set: update

I have also changed host & domain and restarted ISPConfig servery using /etc/init.d/ispconfig_server restart but didn't make any difference.

 

Not sure if this is the correct permissions for config.inc.php, can anyone please cofirm?

-rwxr-xr-x 1 admispconfig admispconfig 7438 Jan 9 01:29 go_info.inc.php
-rwxr-xr-x 1 admispconfig admispconfig 354 Jan 9 01:29 copyright.inc.php
-rwxr-xr-x 1 admispconfig admispconfig 1768 Jan 9 01:29 banner.inc.php
-rwxr-xr-x 1 admispconfig admispconfig 6275 Jan 9 01:29 app.inc.php
-rw------- 1 admispconfig admispconfig 5801 Jan 9 01:29 config.inc.php

 

Although "chmod 755 config.inc.php" and restarting ISPConfig server did not fix problem of restarting services.

 

This is the correct setting. If you change the perimissions to 755, then anyone can read that file (and you have your root MySQL login in there!). Please change it back to 600:

Code:

chmod 600 config.inc.php

Did you install your Fedora Core 4 system following this tutorial? http://www.howtoforge.com/perfect_setup_fedora_core_4

 

I have changed permissions of config.inc.php to 600 as originally it was.

I certainly followed Fedora Core 4 documentation from above turorial, which is probably only but perfect. It was a while ago though, and I have installed update to the latest version which was again successful without any errors.

 

I performed following and got Segmentation fault

[root@portal ~]# rm /root/ispconfig/.ispconfig_lock -rf
[root@portal ~]# /root/ispconfig/php/php -q /root/ispconfig/scripts/writeconf.php
start
Segmentation fault

 

If you get segmentation faults, you should have a look at this thread: http://www.howtoforge.com/forums/showthread.php?t=807

 

I am running Fedora Core 4 with Software RAID (mirrored) and tried to check mirroring status + any hard drive errors but couldn't spot any problems at all. Don't think it will be memory fault as it is not intermittent and happening exactly on the same steps. Would you advise any other tests or recomend me to ISPConfig from scrach.

 

It was only yesterday that I wanted to install ISPConfig for a customer, but got a segmentation fault multiple times, and always at the same step. My customer changed the memory, and then it was working.

You can test your memory with this tool: http://www.memtest86.com/

 

segmentation fault or whatever but still not working

Hi,

It took me a while in investigating again and coming back to forum as I broke all of my system in debugging.

I initially had a RAID mirroring installed on Redhat FC4 so to debut I ran memtest on memory which passed without any errors. Secondly I took primary hard disk and performed full format using DOS disk which came back without any errors and no bad sectors at all. I tried to establish RAID again but secondary disk wouldn't boot up so I literally *ed up my system. I had a backup of system so performed format on secondary disk again and again no errors at all.

Now I decided to re-install system, one of the newer disk is now main disk, older disk is spare where I am keeing a scheduled backup with rdiff-backup instead of mirroring.

Worked fine for couple of weeks, been playing with rdiff bakup and found quite handy & useful.

Two days back I got a cronwatch error again I think this is where my previous problems started from.

Cron started producing following error.
Use of uninitialized value in numeric le (<=) at /etc/cron.daily/0logwatch line 683.

I can replicate this error by executing /etc/cron.daily/0logwatch but it produces LogWatch output perfectly which I get in root email. I suspect yum installed following updates around the first error.
kernel.i686 2.6.15-1.1833_FC4 & kernel-devel.i686 2.6.15-1.1833_FC4
and dhclient.i386 10:3.0.2-34.FC4 xterm.i386 208-2.FC4 a day before that.

Today when I tried to stop firewall, looked working but again I thought of restarting couple of services as a test and got stuck there. Services Restart command doesn't work again.

I have now uninstalled following and still cannot restart services.
rpm -e kernel.i686 2.6.15-1.1833_FC4 kernel-devel.i686 2.6.15-1.1833_FC4

In my today's investigation I also get segmentation fault when I execute following.
rm /root/ispconfig/.ispconfig_lock -rf
/root/ispconfig/php/php -q /root/ispconfig/scripts/writeconf.php

As I have yum scheduled to update every night, I suppose this is something done by updates which ruined ispconfig or rather the system itself.

I do not believe there are any hardware errors in disk or memory as I have performed full tests earlier and do not see any symptoms at all. Not getting any luck with ISPConfig, not sure if it is worth trying webmin.

Any suggestions please?

 

Did you search the Fedora forum if anyone else had these problems? They aren't caused by ISPConfig.

 

broken link for /var/log/httpd/ispconfig_access_log.1

Guys, I tried few other things including webmin and ISPConfig on debian which doesn't give me much of a freedom with OS and finally back to FC4+ISPConfig again.

I started getting following errors from cron.daily and investigated which resulted in finding a broken link to ISPConfig log file.
Reload this Page Use of uninitialized value in numeric le (<=) at /etc/cron.daily/0logwatch line 683

See http://forums.fedoraforum.org/showthread.php?p=478464#post478464 for details.

I am not sure why I ended up with a broken link to ISPConfig file.
lrwxrwxrwx 1 root root 46 Mar 19 03:25 /var/log/httpd/ispconfig_access_log.1 -> /var/log/httpd/ispconfig_access_log_2006_03_19

I might have to exclude ispconfig_access_log from logwatch cron, but not sure how.

ISPConfig is great piece of software compare with all others which are too complicated with not enough documentation. I would recommend this and would love to keep it on as long as it works for me and keeps developing.

 

What's the output of

Code:

ls -la /var/log/httpd

?

 

I have deleted the file causing error today and now I get following output.

 

Looks ok. Maybe the logrotate cron job doesn't like symlinks. However, I woudn't worry about it, logrotate does still work.

 

I got below error again, is it possible to define how many IPSConfig access l ogs you want to keep and or the naming convention anywhere?

/etc/cron.daily/0logwatch:
Use of uninitialized value in numeric le (<=) at /etc/cron.daily/0logwatch line 683.

I see the error below when I list directory, obviously one fo the file has its symbolic link but does not exist.

HTML:

[root@portal httpd]# ls -latr
total 312
-rw-r--r--   1 root root    497 Mar 17 21:18 ssl_request_log.1
-rw-r--r--   1 root root    412 Mar 17 21:18 ssl_access_log.1
-rw-r--r--   1 root root   6491 Mar 18 00:56 ssl_error_log.2
-rw-r--r--   1 root root 134990 Mar 19 03:47 access_log.2
-rw-r--r--   1 root root      0 Mar 19 04:02 ssl_request_log
-rw-r--r--   1 root root      0 Mar 19 04:02 ssl_access_log
-rw-r--r--   1 root root  20103 Mar 19 04:02 error_log.2
-rw-r--r--   1 root root    630 Mar 22 20:46 ssl_error_log.1
lrwxrwxrwx   1 root root     46 Mar 26 00:52 ispconfig_access_log.1 -> /var/log/httpd/ispconfig_access_log_2006_03_26
-rw-r--r--   1 root root  75751 Mar 26 00:52 access_log.1
-rw-r--r--   1 root root   7842 Mar 26 04:02 error_log.1
-rw-r--r--   1 root root    378 Mar 26 04:02 ssl_error_log
-rw-r--r--   1 root root   6916 Mar 27 23:40 ispconfig_access_log_2006_03_27
drwxr-xr-x  14 root root   4096 Mar 27 23:59 ..
lrwxrwxrwx   1 root root     46 Mar 28 03:13 ispconfig_access_log -> /var/log/httpd/ispconfig_access_log_2006_03_28
-rw-r--r--   1 root root   2919 Mar 28 03:13 error_log
drwx------   2 root root   4096 Mar 28 03:13 .
-rw-r--r--   1 root root    453 Mar 28 04:12 ispconfig_access_log_2006_03_28
-rw-r--r--   1 root root   9952 Mar 28 04:12 access_log

 

The reason the service control hung

I can tell you that this problem where switching a service off/on does not work any more due to the "/root/ispconfig/scripts/writeconf.php" process dieing on a SIGSEGV (Segmentation fault) is not in fact bad ram or hard drive. This problem is one that can be reproduced on different systems and different installations, but I can only speak for the installations based on Fedora Core 4.
On closer inspection (after removing the /root/ispconfig/.ispconfig_lock) when running the process through strace:

strace -f /root/ispconfig/php/php /root/ispconfig/scripts/writeconf.php

The segmentation fault happens when it is reading data from the dns_isp_dns table. It is the data in that table that some how causes /root/ispconfig/scripts/writeconf.php to die with a segmentation fault. You have to keep in mind that when you are dealing with PHP, there are software causes for segmentation faults, as in errors or situations in the code that cause unhandled problems with that PHP interpreter process. This is one of those cases. I just removed the single DNS entry from the table, and ran through the process again, no problems at all. The contents of the dns_isp_dns table was as follows:

Code:

+--------+------------+-----------------+-------------+-----------+------------+---------+-------------------------------+-------------------------------+-----------------------+-----------+--------+--------------+
| doc_id | doctype_id | dns_soa         | dns_refresh | dns_retry | dns_expire | dns_ttl | dns_ns1                       | dns_ns2                       | dns_adminmail         | server_id | status | dns_soa_ip   |
+--------+------------+-----------------+-------------+-----------+------------+---------+-------------------------------+-------------------------------+-----------------------+-----------+--------+--------------+
|      1 |       1016 | norealdomai.net | 28800       | 7200      | 604800     | 86400   | virtuozzo-fc4.norealdomai.net | virtuozzo-fc4.norealdomai.net | [email protected] | 1         | d      | 10.254.138.14 |
+--------+------------+-----------------+-------------+-----------+------------+---------+-------------------------------+-------------------------------+-----------------------+-----------+--------+--------------+

The domain and IP address were the only things that were modified for privacy sake. If anyone has any questions, or would like more information, I do have the full strace on file. I discovered this by finding why one of my installations was having this problem, when the other was not. Well it turns out, my other installation had no DNS entries set up.