Hi, I've deleted one administrator email user, john, then empty the recycle bin. All is correct: the Maildir symlink points to the /home/www/web15/user/john/Maildir that doesn't exists (I use Courier instead WU). Then I've moved one existing user (joseph) to administrator. No changes in the symlink after many than 2 hours. Now I've modified this account (joseph): added «catchAll email» and SSH access. With this changes, the Maildir symlink now is correct only 5 minutes after the change: /home/www/web15/user/joseph/Maildir. Then I've unselected the SSH access and I can see the changes in /etc/passwd. Good! Seems that some changes have long delay --or maybe doesn't works? What is the normal delay that I can should wait for? I've previously seen this detail with one new site: only when I've created new users (administrator, catchAll email, SSH) the new site appears in /etc/apache2/vhosts/Vhosts_ispconfig.conf and apache2 service reloaded. One detail that maybe is important: the server is in one intranet with the 192.168.1.150 IP. I'm out of the office working with the Internet router IP that with NAT «see» the 192.168.1.150:81. I can see that my browser looks for some details in 192.168.1.150 and maybe some PHP scripts doesn't works for this reason. Thanks for this great software --and sorry for my poor english
What's the output of Code: ls -la /root/ispconfig ? Can you run this? Code: strace /root/ispconfig/php/php -q /root/ispconfig/scripts/writeconf.php Do you see any errors (segmentation faults)? PHP 5.1.2 has a few bugs that cause segmentation faults on some systems...
Tests done Code: $ ls -la /root/ispconfig total 120 drwxr-xr-x 9 root root 4096 2006-05-26 14:52 . drwxr-xr-x 8 root root 4096 2006-04-12 21:25 .. -rwxr-xr-x 1 root root 55866 2005-11-26 14:09 cronolog -rwxr-xr-x 1 root root 9673 2005-11-26 14:09 cronosplit drwxr-xr-x 12 root root 4096 2005-11-26 13:21 httpd drwxr-xr-x 11 root root 4096 2005-11-26 14:09 isp -rw-r--r-- 1 root root 9 2006-05-26 14:52 .old_path_httpd_root drwxr-xr-x 6 root root 4096 2005-11-26 13:18 openssl drwxr-xr-x 6 root root 4096 2005-11-26 13:24 php drwxr-xr-x 4 root root 4096 2005-11-26 14:09 scripts drwxr-xr-x 4 root root 4096 2005-11-26 14:09 standard_cgis drwxr-xr-x 2 root root 4096 2005-11-26 14:09 sv -rwx------ 1 root root 8190 2005-11-26 14:09 uninstall Works fine, no segmentation fault errors. Is one Debian Etch with PHP4. I've replied too late (I'm sorry for the delay) because today I've used ISPConfig from the intranet --and I see the same delays too. Maybe is due that I should press the «save» button of the main «ISP Site» page after any user changes? NOTE: is one old ISPConfig version: 2.1.1. Yes, is time to upgrade ...
Yes, try that. The latest release comes with PHP 5.1.4 where the developers solved some problems with segmentation faults, etc.
Today I can ca reproduce this delay problem: I change one user email password in the ISPConfig interface, but in the user still have the old password. Running Code: strace /root/ispconfig/php/php -q /root/ispconfig/scripts/writeconf.php this message loops again and again: Code: stat64("/root/ispconfig/.ispconfig_lock", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, {1, 0}) = 0 The file: Code: $ ls -l /root/ispconfig/.ispconfig_lock -rw-r--r-- 1 root root 0 2006-06-15 08:50 /root/ispconfig/.ispconfig_lock Is safe that I delete this file or I should wait for / force another ISPConfig process? Update: After browsing this forum looking for .ispconfig_lock: - I've deleted .ispconfig_lock - Run (as root) root/ispconfig/php/php -q /root/ispconfig/scripts/writeconf.php Code: start chmod: no s'ha pogut accedir a "joan:web10": El fitxer o directori no existeix (traduction: chmod: can't access to "joan:web10": file or directory not found) ERROR: Nothing parsed, nothing printed <BR> UPDATE USER: 153 ende - I don't see errors in ISPConfig log (before and after). - No .ispconfig_lock file now. Loking for the .ispconfig_lock file presence reason.
You can delete the lock file. It's created by the ISPConfig backend to prevent that a second backend process is running at the same time trying to write configuration files. If during a backend run the process is aborted for some reason (power failure, ...), then the .ispconfig_lock file remains in /root/ispconfig, preventing further updates to be written to the configuration files.