httpd and dovecot service start fails
Rick Stevens
rstevens at vitalstream.com
Mon Feb 6 17:54:36 UTC 2006
On Mon, 2006-02-06 at 10:41 -0600, Bob McClure Jr wrote:
> > On Mon, Feb 06, 2006 at 07:54:20AM -0800, Harold Hallikainen wrote:
> >
> > > On Sun, Feb 05, 2006 at 01:53:38PM -0800, Harold Hallikainen wrote:
> > >>
> > >> > On Sat, Feb 04, 2006 at 09:43:02PM -0800, Harold Hallikainen wrote:
> > >> >> I'm installing FC4 on an old machine after having success on a new
> > >> >> machine. I did a new install (instead of update) and modified the
> > >> same
> > >> >> configs I modified on the new machine. Here's the latest problem.
> > >> This
> > >> >> is
> > >> >> getting real close to working correctly!
> > >> >>
> > >> >> If I do /sbin/service httpd restart or /sbin/service dovecot restart,
> > >> >> the
> > >> >> restart fails (the stop fails too since they did not start properly
> > >> >> during
> > >> >> boot). However, if I do /usr/sbin/httpd or /usr/sbin/dovecot , they
> > >> both
> > >> >> seem to run fine. How can I find out what's going wrong during boot
> > >> or
> > >> >> restart that's causing these to not run? I've looked in the httpd
> > >> logs
> > >> >> and
> > >> >> the messages log and found nothing.
> > >> >
> > >> > Look again. For httpd, look in /var/log/httpd/error_log. For
> > >> > dovecot, look in /var/log/maillog. If a service isn't starting
> > >> > properly, there _must_ be some information either on the screen or in
> > >> > a log.
> > >> >
> > >>
> > >> I left httpd running last night by manually starting it. I then did a
> > >> service httpd restart this afternoon. Here's the restart:
> > >>
> > >> [root at kauko sbin]# ./service httpd restart
> > >> Stopping httpd: [ OK ]
> > >> Starting httpd: [FAILED]
> > >> [root at kauko sbin]#
> > >>
> > >>
> > >>
> > >> And here's the error_log:
> > >>
> > >> [Sun Feb 05 04:02:20 2006] [notice] Digest: generating secret for digest
> > >> authentication ...
> > >> [Sun Feb 05 04:02:20 2006] [notice] Digest: done
> > >> [Sun Feb 05 04:02:20 2006] [notice] LDAP: Built with OpenLDAP LDAP SDK
> > >> [Sun Feb 05 04:02:20 2006] [notice] LDAP: SSL support unavailable
> > >> [Sun Feb 05 04:02:22 2006] [notice] mod_python: Creating 4 session
> > >> mutexes
> > >> based on 150 max processes and 0 max threads.
> > >> [Sun Feb 05 04:02:23 2006] [notice] Apache/2.0.54 (Fedora) configured --
> > >> resuming normal operations
> > >> [Sun Feb 05 13:49:44 2006] [notice] caught SIGTERM, shutting down
> > >> Waiting for data... (interrupt to abort)
> > >>
> > >>
> > >> The 13:49:44 appeared when I did the restart. Nothing appeared after
> > >> that...
> > >>
> > >> THANKS!
> > >>
> > >> Harold
> > >
> > > Hmm. This does not compute. Try to start it again, and very soon
> > > after, do this:
> > >
> > > cd /var/log
> > > ls -lrt
> > >
> > > The last log touched will be at the bottom of the list. My guess is
> > > it will be messages. Check that. Also check
> > > /var/log/httpd/access_log. It must be leaving a suicide note somewhere.
> > >
> >
> >
> > OK, doing ls -lrt on the right directory, I get:
> >
> > [root at kauko log]# pwd
> > /var/log
> > [root at kauko log]# date
> > Mon Feb 6 07:46:39 PST 2006
> > [root at kauko log]# /sbin/service httpd restart
> > Stopping httpd: [FAILED]
> > Starting httpd: [FAILED]
> > [root at kauko log]# ls -lrt
> > total 5152
> > drwx------ 2 root root 4096 Nov 2 2004 ppp
> > drwxr-xr-x 2 privoxy privoxy 4096 Mar 2 2005 privoxy
> > drwxr-xr-x 2 root root 4096 Mar 5 2005 fax
> > drwxrwsr-x 2 root mailman 4096 Mar 7 2005 mailman
> > drwxr-xr-x 2 canna canna 4096 Mar 7 2005 canna
> > drwxrwx--- 2 quagga quagga 4096 Apr 4 2005 quagga
> > drwx--S--- 2 amanda disk 4096 Apr 22 2005 amanda
> > drwxr-xr-x 2 tomcat tomcat 4096 May 10 2005 tomcat5
> > drwxr-x--- 2 squid squid 4096 May 16 2005 squid
> > drwxr-xr-x 2 iiimd iiimd 4096 May 23 2005 iiim
> > drwxr-xr-x 2 root root 4096 May 27 2005 vbox
> > -rw------- 1 root root 0 Jan 7 18:21 spooler.4
> > -rw------- 1 root utmp 0 Jan 7 18:21 btmp.1
> > drwxr-xr-x 2 root root 4096 Jan 7 18:25 mail
> > -rw-r--r-- 1 root root 72220 Jan 7 20:29 scrollkeeper.log
> > -rw-r----- 1 mysql mysql 0 Jan 7 20:51 mysqld.log.4
> > drwxr-xr-x 3 news news 4096 Jan 7 22:14 news
> > drwx------ 2 root root 4096 Jan 7 22:18 iptraf
> > drwxr-xr-x 2 uucp uucp 4096 Jan 7 22:18 uucp
> > -rw------- 1 root root 39790 Jan 7 22:58 anaconda.xlog
> > -rw------- 1 root root 38944 Jan 7 22:58 anaconda.syslog
> > -rw------- 1 root root 15832 Jan 7 22:58 anaconda.log
> > -rw------- 1 root root 0 Jan 8 14:17 boot.log.4
> > drwxr-x--- 2 root root 4096 Jan 8 14:17 audit
> > -rw-r--r-- 1 root root 55878 Jan 11 04:02 rpmpkgs.4
> > -rw------- 1 root root 4068 Jan 15 11:13 secure.4
> > -rw------- 1 root root 6813 Jan 15 12:19 maillog.4
> > -rw------- 1 root root 186559 Jan 15 12:19 cron.4
> > -rw------- 1 root root 467643 Jan 15 12:19 messages.4
> > -rw------- 1 root root 0 Jan 15 12:19 spooler.3
> > -rw-r----- 1 mysql mysql 0 Jan 15 12:19 mysqld.log.3
> > -rw------- 1 root root 0 Jan 15 12:19 boot.log.3
> > -rw-r--r-- 1 root root 55878 Jan 21 04:02 rpmpkgs.3
> > -rw------- 1 root root 1327 Jan 21 22:35 secure.3
> > -rw------- 1 root root 567926 Jan 22 04:02 messages.3
> > -rw------- 1 root root 8451 Jan 22 04:02 maillog.3
> > -rw------- 1 root root 376146 Jan 22 04:02 cron.3
> > -rw------- 1 root root 0 Jan 22 04:02 spooler.2
> > -rw------- 1 root root 0 Jan 22 04:02 secure.2
> > -rw-r----- 1 mysql mysql 0 Jan 22 04:02 mysqld.log.2
> > -rw------- 1 root root 0 Jan 22 04:02 boot.log.2
> > -rw-r--r-- 1 root root 56543 Jan 28 04:02 rpmpkgs.2
> > -rw------- 1 root root 517218 Jan 29 04:02 messages.2
> > -rw------- 1 root root 6096 Jan 29 04:02 maillog.2
> > -rw------- 1 root root 395521 Jan 29 04:02 cron.2
> > -rw------- 1 root root 0 Jan 29 04:02 spooler.1
> > -rw------- 1 root root 0 Jan 29 04:02 boot.log.1
> > -rw-r----- 1 root root 2300 Jan 29 17:47 acpid
> > -rw-rw-r-- 1 root utmp 165888 Jan 29 18:01 wtmp.1
> > drwx------ 3 radiusd radiusd 4096 Feb 1 04:02 radius
> > -rw-r--r-- 1 root root 56543 Feb 4 04:02 rpmpkgs.1
> > -rw------- 1 root root 2260 Feb 4 22:10 secure.1
> > -rw------- 1 root root 632534 Feb 5 04:02 messages.1
> > -rw------- 1 root root 15036 Feb 5 04:02 maillog.1
> > -rw------- 1 root root 395130 Feb 5 04:02 cron.1
> > drwxr-xr-x 2 lp sys 4096 Feb 5 04:02 cups
> > -rw------- 1 root root 0 Feb 5 04:02 spooler
> > drwx------ 2 root root 4096 Feb 5 04:02 httpd
> > -rw------- 1 root root 0 Feb 5 04:02 boot.log
> > -rw------- 1 root utmp 384 Feb 5 17:57 btmp
> > -rw-r----- 1 mysql mysql 3440 Feb 5 18:10 mysqld.log.1
> > -rw-r--r-- 1 root root 46138 Feb 5 18:12 Xorg.0.log.old
> > -rw-r--r-- 1 root root 11655 Feb 5 18:16 dmesg
> > -rw-r----- 1 mysql mysql 757 Feb 5 18:16 mysqld.log
> > -rw-r--r-- 1 root root 676 Feb 5 18:17 sshblacklisting
> > drwxr-xr-x 2 root root 4096 Feb 5 18:17 gdm
> > -rw-r--r-- 1 root root 46138 Feb 5 18:17 Xorg.0.log
> > -rw-r--r-- 1 root root 225 Feb 5 18:28 yum.log
> > drwx------ 2 root root 4096 Feb 5 21:32 samba
> > drwxr-xr-x 2 root root 4096 Feb 6 00:00 sa
> > -rw-r--r-- 1 root root 67742 Feb 6 04:04 prelink.log
> > -rw-r--r-- 1 root root 56561 Feb 6 04:05 rpmpkgs
> > -rw------- 1 root root 5001 Feb 6 04:54 maillog
> > -rw-rw-r-- 1 root utmp 76032 Feb 6 07:40 wtmp
> > -rw------- 1 root root 1511 Feb 6 07:40 secure
> > -r-------- 1 root root 19136220 Feb 6 07:40 lastlog
> > -rw------- 1 root root 65638 Feb 6 07:45 cron
> > -rw------- 1 root root 130754 Feb 6 07:45 messages
> > [root at kauko log]#
> >
> >
> > It looks like there were entries in messages and cron. Here's the last few
> > lines of messages:
> >
> > Feb 6 07:40:52 kauko sshd(pam_unix)[15144]: session opened for user root
> > by root(uid=0)
> > Feb 6 07:45:01 kauko crond(pam_unix)[15256]: session opened for user root
> > by (uid=0)
> > Feb 6 07:45:02 kauko crond(pam_unix)[15256]: session closed for user root
> > Feb 6 07:50:01 kauko crond(pam_unix)[15320]: session opened for user root
> > by (uid=0)
> > Feb 6 07:50:01 kauko crond(pam_unix)[15321]: session opened for user root
> > by (uid=0)
> > Feb 6 07:50:01 kauko crond(pam_unix)[15321]: session closed for user root
> > Feb 6 07:50:02 kauko crond(pam_unix)[15320]: session closed for user root
> >
> > and cron
> >
> > Feb 6 07:40:01 kauko crond[15134]: (root) CMD (/usr/lib/sa/sa1 1 1)
> > Feb 6 07:45:01 kauko crond[15257]: (root) CMD (/usr/bin/mrtg
> > /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache
> > -file /var/lib/mrtg/mrtg.ok)
> > Feb 6 07:50:01 kauko crond[15322]: (root) CMD (/usr/bin/mrtg
> > /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache
> > -file /var/lib/mrtg/mrtg.ok)
> > Feb 6 07:50:01 kauko crond[15323]: (root) CMD (/usr/lib/sa/sa1 1 1)
> >
> >
> > I don't see anything related to the httpd restart... More ideas?
>
> I give up. Maybe when Rick Stevens gets his morning coffee, he'll
> have some obvious solution that we've all missed.
<yawn!> Hi, guys.
Hmmm...looking at the thread, you've tried a lot of things. First off,
check /etc/sysconfig/httpd to see if there are any oddities in the
configuration.
Also note that /etc/rc.d/init.d/httpd does NOT use apachectl to start.
It does check the /etc/httpd/conf/httpd.conf file for any Apache 1.3
config directives and aborts if it sees any. It's odd, but Apache 2.0
will start with 1.3 directives in the file, but it tries to ignore them.
The start script, however, aborts. The directives it looks for are:
ServerType
BindAddress
Port
AddModule
ClearModuleList
AgentLog
RefererLog
RefererIgnore
FancyIndexing
AccessConfig
ResourceConfig
If any of those are found in /etc/httpd/conf/httpd.conf, the script will
abort. Of course, if you just do a "/usr/sbin/httpd", then it'll start
up.
As to the dovecot stuff, dovecot is the new IMAP/POP daemon (replacing
the old imapd/ipop3d system). It writes its logs to /var/log/maillog,
so check that for errors. It is controlled by a config
file, /etc/dovecot.conf, and there may be a typo in there.
As to someone's comment about how startup scripts are done:
All actual startup/shutdown scripts are in /etc/rc.d/init.d. In
/etc/rc.d/rcX.d (where the X refers to the system run level), there
are symlinks back to the /etc/rc.d/init.d scripts. These links are
prefixed with either "Sxx" or "Kxx". The "Sxx" links are used when the
system enters the given run level and are called "start scripts". The
system ordinarily runs them in numerical order ("S01" before "S02" and
so on) and passes them the "start" command.
The "Kxx" scripts are used when the system _leaves_ the run level and
are called "kill scripts". These are also run in numerical order and
are given the "stop" command.
/usr/sbin/service is a simple script that checks the appropriate
/etc/rc.d/init.d/rcX.d directory for a link containing the service name
you give it, and passes it the option you give it:
service smb start
checks the appropriate /etc/rc.d/rcX.d directory for a symlink
containing the string "smb" and passes it the "start" option.
As to how to enable any service to start at boot time:
chkconfig servicename on
E.g.:
chkconfig smb on
will enable smb to start on the next boot. Conversely:
chkconfig smb off
will prevent it from starting at boot. Note that chkconfig only enables
or disables the start from boot. If you need it to start now, use the
"service smb start" (or "service smb stop") command as well.
Does that help?
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer rstevens at vitalstream.com -
- VitalStream, Inc. http://www.vitalstream.com -
- -
- If the enemy's in range...so are you! -
----------------------------------------------------------------------
More information about the Redhat-install-list
mailing list