Apache is set to start on runlevel 2, 3 and 5, just like MySQL. For some obscure reason this always fails. I tried resetting the runlevels, but this did not help and I always have to start apache manually after reboot.
How can I analyze this problem? In the Apache logs I don’t find the cause. Is there an other log I can check? Anybody else experiencing this problem?
On 2011-01-05 10:36, comunica2 wrote:
> How can I analyze this problem? In the Apache logs I don’t find the
> cause. Is there an other log I can check? Anybody else experiencing this
> problem?
The messages log.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
According to my openSUSE web server (which apache starts fine on runlevel):
# chkconfig --list | grep apache
apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off
I don’t have apache starting on runlevel 2, just 3 and 5 and it works. So just a guess but maybe try disabling apache2 on runlevel 2?
I also see no need for running Apache in runlevel 2 where you have no network connection. And it may result (I am not sure here) in the system starting Apache before the network is there, even when runlevel 3 or 5 are the ones you go to. And that may result in a failure because of no network.
When you just use the normal way to config this (YaST) it will also not be started in runlevel 2. I wonder why you changed this.
But looking in the system loggings (after all it is the system that tries to start Apache) might help.
On 2011-01-05 13:06, hcvv wrote:
>
> I also see no need for running Apache in runlevel 2 where you have no
> network connection.
It would not work in runlevel 2, but I see no reason why it would not start
in the other levels. :-?
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
I tried to explain my strain of thought in de post above. I will try to do this again in a few more words.
Step 1:
I am pretty sure (else there would be a lot of sequence problems I assume) that when booting into runlevel 3, those services that are also to be run in lower runlevels will be started before the services that are mentioned for runlevel 3 alone will be started. Thus even when starting into 3 or 5, Apache will be started before the network is available.
Step 2:
I am not so sure about this one because it still has to be proven. I think that somewhere during the start of Apache a test is made if the network is available, When not it bails out. I hope this can be checked by looking in the system loggings.
And to repeat myself once more: I hope the OP can explain why he differed from the standard way in letting Apache also start at runlevel 2. And of couse if it helps when he goes back to the standard way of life.
Thanks for all the interest in this problem. I disabled runlevel 2:
apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off
… but there is no change, apache is not started at reboot. I don’t see any error messages in any log file either.
Until now you did not tell us much what you did. You told us your conclusion, but not how you came to them. And I still have a pending question: why did you not use YaST > System > System services (runlvel) to get Apache2 running. AFAIK all the people here who did that got it running without problems. You may have reasons for it, but as long as you keep them for yourself, you can not expect us to understand exactly what you are after.
Then you say: apache does not run. How do you know? Did you do a
ps -ef|grep apache
And again, when you boot into runlevel 3 and hit the Esc key to see what happens, there must be at least one line saying that the apache run is going and then it says OK or Failed or something. The screen might go fast, but you must be able to see something there.
On 2011-01-06 21:36, hcvv wrote:
> And again, when you boot into runlevel 3 and hit the Esc key to see
> what happens, there must be at least one line saying that the apache run
> is going and then it says OK or Failed or something. The screen might go
> fast, but you must be able to see something there.
And the screen is logged to a file, too.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
On 2011-01-05 17:06, hcvv wrote:
>
> robin_listas;2274005 Wrote:
>> On 2011-01-05 13:06, hcvv wrote:
>> It would not work in runlevel 2, but I see no reason why it would not
>> start in the other levels. :-?
> I tried to explain my strain of thought in de post above. I will try to
> do this again in a few more words.
Tks 
> Step 1:
> I am pretty sure (else there would be a lot of sequence problems I
> assume) that when booting into runlevel 3, those services that are also
> to be run in lower runlevels will be started before the services that
> are mentioned for runlevel 3 alone will be started. Thus even when
> starting into 3 or 5, Apache will be started before the network is
> available.
I doubt it
/etc/init.d/apache2:
ypclient dhcp radiusd
Give the suse initd service scripts some credit, the apache service will
not attempt to start (automatically, that is) before the network is up.
> Step 2:
> I am not so sure about this one because it still has to be proven. I
> think that somewhere during the start of Apache a test is made if the
> network is available, When not it bails out. I hope this can be checked
> by looking in the system loggings.
It is possible.
I know that postfix bails out if there is no network, it would not surprise
me that apache does the same.
> And to repeat myself once more: I hope the OP can explain why he
> differed from the standard way in letting Apache also start at runlevel
> 2. And of couse if it helps when he goes back to the standard way of
> life.
Absolutely
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
Carlos,
Your remark about the INIT INFO section is correct, but this section only serves to give the script a correct sequence number in the links in the* rc?.d* directories. And that is done by the configuring tool (e.g. YaST) that understands these INIT INFO section at configuring time. It is not used at boot/shutdown time. Thus how could this work configuring it for runlevel 2 in the rc2.d directory? Would it create a sort of failure? And would that failure influence the links in the* rc3.d and rc5.d* directoruies? I do not know.
Also, the fact that the OP apparently did do at least some things manualy instead of trusting the installed scripts and YaST, how can we know he didn’t do much more things manualy? Especialy as until now he does not explain why he differed from the normal way of working, leaving us to guess what he did. He can equaly well use a different* init.d/apache2* script from the one you cite from.
On 2011-01-07 10:36, hcvv wrote:
>
> Carlos,
>
> Your remark about the INIT INFO section is correct, but this section
> only serves to give the script a correct sequence number in the links in
> the- rc?.d- directories. And that is done by the configuring tool (e.g.
> YaST) that understands these INIT INFO section at configuring time. It
> is not used at boot/shutdown time. Thus how could this work configuring
> it for runlevel 2 in the -rc2.d- directory? Would it create a sort of
> failure? And would that failure influence the links in the- rc3.d -and-
> rc5.d- directoruies? I do not know.
It works, believe me
YaST uses insserv to “install” those scripts. Or you can use “chkconfig”,
which also uses insserv. This “insserv” knows how to read the INIT INFO
section - it is a comment to bash, thus ignored, but it is interpreted by
insserv.
How? Well, traditionally by creating those symlinks in /etc/init.d/rc3.d/
and the rest directories, with names that start with S00, S01, S02, etc
(and K00, K01, for the halt sequence). On boot, those scripts are started
in order, numerical order. Simply by having “S02network” and “S12apache2”,
it is ensured that network is started before apache.
However, SUSE uses an improvement on this: makefile like configuration
files: depend.boot .depend.halt .depend.start .depend.stop. These allow
more complex dependency control that the links, and also allow parallel
booting. The links are in fact now ignored: if you create a link to a
script and put it there, it doesn’t run.
You can see the code in “/etc/init.d/rc”.
So the thing is that during boot on each runlevel the correct scripts are
started in the correct order. It simply works, it is a very much thought
about and engineered part of our distro
(and about to change for 11.4 or perhaps delayed to 12.0)
So, what happens in runlevel 2? Well, the network service is started in
level 2:
Telcontar:~ # chkconfig -l network
network 0:off 1:off 2:on 3:on 4:off 5:on 6:off
So apache can be configured there. But I think it is just the local
loopback (lo) networking.
Influence on the other levels? Limited. Links created in one level do not
affect other levels. But if you start on runlevel 2, then go to 3, services
that were previously started are not restarted again. This I think was an
improvement that appeared on I don’t remember what version.
What happens to apache started in runlevel 2?
I do not know. Network was started in level 2, the script is there, but I
suppose, educated guess, that only the local (lo) interface. On switch to
runlevel 3, network should really be started, and those services that need
it should restart again (if they are already running). I don’t know how,
if, the system figures this out, and I’m not going to test that hypothesis,
it would kill my session 
Oh, right, I could use a VM. But I’m hungry and I have to cook it
> Also, the fact that the OP apparently did do at least some things
> manualy instead of trusting the installed scripts and YaST, how can we
> know he didn’t do much more things manualy? Especialy as until now he
> does not explain why he differed from the normal way of working, leaving
> us to guess what he did. He can equaly well use a different-
> init.d/apache2- script from the one you cite from.
That is so, yes.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
I did both with Yast and with the commandline tool. I don’t think there is much difference but when one does not seem to work you resort to the other.
Apache is just not running at reboot, that’s all I can say. Your ps -ef|grep apache only shows itself.
When I reboot I see in the messages that Apache fails starting. My original question was, where can I see in a log the reason why? May be I should change the loglevel of Apache for this? Another log? When I look at /var/log/apache2/error_log I just don’t see any log entries for today (I especially did not try to start Apache manually yet).
After reading the answers about Apache possibly bailing out without networking I investigated in that direction and in fact found the problem.
I had my networking set to NetworkManager. If I understand right, this method is delaying network connection until a KDE session is started. That’s why Apache would not see a network connection or may was it the start script, because I cannot understand why Apache would not log this in the error_log. A bit more diagnostic (log) messages would be really helpful in the start script.
Thanks a lot for you bouncing off ideas. It was really helpful.