This daemon should be starting on demand, but it's not on one hosting server (host1), the second is okay (I'll call it host2).
My only workaround for this so far is a crontab (on host1). There is another system (host2) I installed this on, but killed all the ispcp daemons after I noticed some "text file busy" cp error messages during install.
cp: cannot create regular file `/var/www/ispcp/daemon/ispcp_daemon': Text file busy
The md5sum is the same on both hosting servers, so I'm at a loss as to why it's not automagical.
~# md5sum /tmp/ispcp/var/www/ispcp/daemon/ispcp_daemon /var/www/ispcp/daemon/ispcp_daemon
815af228a14e5284e2e198e7d8cd3fde /tmp/ispcp/var/www/ispcp/daemon/ispcp_daemon
815af228a14e5284e2e198e7d8cd3fde /var/www/ispcp/daemon/ispcp_daemon
~# md5sum /tmp/ispcp/var/www/ispcp/daemon/ispcp_daemon /var/www/ispcp/daemon/ispcp_daemon
815af228a14e5284e2e198e7d8cd3fde /tmp/ispcp/var/www/ispcp/daemon/ispcp_daemon
815af228a14e5284e2e198e7d8cd3fde /var/www/ispcp/daemon/ispcp_daemon
I recorded transcripts of the upgrade attempts, and despite this anomoly, I do not find anything else that explains a problem during upgrade. Steps from the upgrade process were copied verbatim to individual shell scripts, and exit codes were compared at completion.
Code:
ispcp-omega-1.0.0# head -n 999 start go-step-*
==> start <==
#!/bin/sh
set -e
make install
for s in ./go* ; do source $s ; done
cd /var/www/ispcp/engine/setup
perl ispcp-update
==> go-step-6 <==
cp -v /var/www/ispcp/engine/ispcp-db-keys.pl /tmp/ispcp/var/www/ispcp/engine/
cp -v /var/www/ispcp/engine/messager/ispcp-db-keys.pl /tmp/ispcp/var/www/ispcp/engine/messager/
cp -v /var/www/ispcp/gui/include/ispcp-db-keys.php /tmp/ispcp/var/www/ispcp/gui/include/
cp -v /var/www/ispcp/gui/themes/user_logos/* /tmp/ispcp/var/www/ispcp/gui/themes/user_logos/
cp -TvR /var/www/ispcp/gui/domain_default_page /tmp/ispcp/var/www/ispcp/gui/domain_default_page
cp -v /var/www/ispcp/gui/tools/pma/config.inc.php /tmp/ispcp/var/www/ispcp/gui/tools/pma/
==> go-step-7 <==
rm -fR /var/www/ispcp/gui/{admin,client,include,orderpanel,themes,reseller}/
rm -fR /var/www/ispcp/gui/*.php
==> go-step-8 <==
cp -Rv /tmp/ispcp/usr/* /usr/
cp -Rv /tmp/ispcp/var/* /var/
==> go-step-9 <==
mv -v /etc/ispcp/ispcp.conf /etc/ispcp/ispcp.old.conf
cp -Rv /tmp/ispcp/etc/* /etc/
Any suggestions to isolate this would be most welcome. I think it's pretty late to just restore from backup, because about a week of changes are in effect now. I've been researching this with Gilbert in the meantime, but this is rather elusive.
(02-16-2009 07:41 AM)gilbert Wrote: (02-16-2009 07:19 AM)sci2tech Wrote: (02-16-2009 07:18 AM)gilbert Wrote: (snip)
Any ideas to help find out why the request manager isn't being run after changes in the control panel?
Password are encoded by gui not by engine. If you not speak about this, check if ispcp_daemon is running
I made sure that ispcp_daemon is running
I made a change to an existing email.
panel says Modification in progress
database says status=change
the change never takes place.
If I manually run /var/www/ispcp/engine/ispcp-rqst-mngr
status then changes to ok in panel.
Any ideas?