Bug#252067: more info?
On Tue, Jun 08, 2004 at 09:45:37AM +0200, Fabio Massimo Di Nitto wrote:
On Tue, 8 Jun 2004, Christopher Mann wrote:
Fabio Massimo Di Nitto wrote:
Hi guys,
please CC the maintainer when reassigning bugs since the BTS
doesn't do that automatically.
Whoops, sorry about that. I thought it did.
My best guess is that, since installing php4-sqlite that depends on
php4api that is provided by 2 packages that pulls in apache and apache2,
There are only two packages that I can find in unstable that provide
phpapi-20040918: php4 and php4-cgi. Nothing is providing zendapi-20020429.
php4 depends on apache-common. I'm not quite sure how that qualifies as a
dependency nightmare, nor am I sure how php4-sqlite would manage to pull in
apache2. I can't find a dependency link on it.
apache2 was running before apache. Both of them listening on port 80. As a
result apache failed to start.
But if /etc/init.d/apache{,-ssl} doesn't call apachectl, how did we manage
to end up with the apachectl help message, no matter what might have already
been running?
Matthew btw php4-sqlite call to apache restart seems ok even if
force-reload is not required (and your prerm script is broken ;)).
reload fails if apache isn't already running. I feel that's probably a bug
in apache, even though Policy doesn't forbid it (we really need an
initscript argument that says restart if already running, or succeed with
no action if not already running). The only way to reload without a
possible failure is force-reload.
In anycase i can't reproduce the problem here. Can anybody provide me with
more info?
I can't reproduce it either. Personally, the only way I can manage to
rationalise it is that someone has done an ln -sf /usr/sbin/apachectl
/etc/init.d/apache. Nothing else makes the slightest sense.
- Matt
Re: Bug#252067: more info?
On Tue, 8 Jun 2004, Matthew Palmer wrote:
Whoops, sorry about that. I thought it did.
no problem. i wasn't upset.. just a note ;)
My best guess is that, since installing php4-sqlite that depends on
php4api that is provided by 2 packages that pulls in apache and apache2,
There are only two packages that I can find in unstable that provide
phpapi-20040918: php4 and php4-cgi. Nothing is providing zendapi-20020429.
libapache2-mod-php4 does too and it pulls in apache2-mpm-prefork.
php4 depends on apache-common. I'm not quite sure how that qualifies as a
dependency nightmare, nor am I sure how php4-sqlite would manage to pull in
apache2. I can't find a dependency link on it.
Basically in this setup apache2 and apache-common are pulled in. Nothing
bad until now, but if a user wants only apache1.3, he or she will endup
with both a1.3 and a2 installed.
apache2 was running before apache. Both of them listening on port 80. As a
result apache failed to start.
But if /etc/init.d/apache{,-ssl} doesn't call apachectl, how did we manage
to end up with the apachectl help message, no matter what might have already
been running?
That is my point. I have no idea. I have been rechecking all the cvs
history to be sure that was not introduced and removed for a mistake.
Matthew btw php4-sqlite call to apache restart seems ok even if
force-reload is not required (and your prerm script is broken ;)).
reload fails if apache isn't already running. I feel that's probably a bug
in apache, even though Policy doesn't forbid it (we really need an
initscript argument that says restart if already running, or succeed with
no action if not already running). The only way to reload without a
possible failure is force-reload.
Ok this has been discussed already with Joey H. as part of dh_installinit.
force-reload is an alias to reload atm and this can be fixed.
In anycase i can't reproduce the problem here. Can anybody provide me with
more info?
I can't reproduce it either. Personally, the only way I can manage to
rationalise it is that someone has done an ln -sf /usr/sbin/apachectl
/etc/init.d/apache. Nothing else makes the slightest sense.
I agree. I can't see any other way around it.
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
