Maybe this will help:
http://stackoverflow.com/questions/32977557/how-do-i-compile-apache-httpd-2-4-16-with-systemd-support
On Tue, Mar 28, 2017 at 9:35 AM, John Iliffe <john.ili...@iliffe.ca> wrote:
> Thank you Mickey.
>
> That is exactly what the problem is; all /var/run subdirectories get
> deleted on reboot.
>
> I tried to move the pid file to another location, for a start its default
> location under the apache install directory, but even directly on
> /var/run/, with the result that systemctl could not find it. The pid file
> was written correctly, under the correct name, and was readable by root,
> but was reported as missing by systemctl and as a result the "systemctl
> stop httpd" command didn't work. It just issued an error message and httpd
> kept right on running.
>
> One trhing that I have been careful to do is keep the start up script at
> init.d/httpd pointed at the same location as httpd.conf.
>
> I'm not sure why but systemctl seems to insist that that the httpd pid file
> be exactly /var/run/httpd/httpd.pid .
>
> I think there must be a configuration parameter somewhere for systemctl but
> I have not been able to find it; can't believe it would be hard coded in
> the
> programme!
>
> That said, thank you for the reply. It does give me the idea that I am on
> the right track.
>
> John
> ===========================================
>
> On Tuesday 28 March 2017 03:05:31 Mickey Nordstrom wrote:
> > Hi John,
> >
> > I didn't read your full post so apologies if I'm not answering your
> > question. I have had similar problems on SuSE Linux whith systemd and
> > the solution was to create a file under /etc/tmpfiles.d with content
> > something like this:
> >
> > d /var/run/httpd 770 webservd webservd
> >
> > Modify it to the user and group that runs your httpd daemon.
> >
> > This is needed because /run and /var/run are volatile and gets cleaned
> > out at each reboot.
> >
> > /Mikael
> >
> > On 28/03/17 04:22, John Iliffe wrote:
> > > First, I know this is probably not an Apache question, but I'm hoping
> > > that someone on this list may have seen this problem before and knows
> > > the solution.
> > >
> > > I know this is going to be very long winded, my apologies in advance,
> > > but I have done quite a bit of research so I have a good idea what
> > > won't work :-(
> > >
> > > Problem:
> > >
> > > OS is Fedora 25
> > >
> > > Fedora replaces service with systemctl control using service files for
> > > starting and stopping daemons. This is a bit different than the
> > > traditional init.d approach.
> > >
> > > I installed Apache-2.4.25 from source without using the Fedora
> > > installation so I had to produce my own start up scripts and used the
> > > compatibility feature of systemctl so httpd can be started from
> > > /etc/init.d/httpd
> > >
> > > My startup script works perfectly UNTIL I reboot. At that point the
> > > directory where httpd.pid resides (/var/run/httpd/httpd.pid) gets
> > > deleted. I have a good idea of why this happens; it is this line in
> > >
> > > /etc/rc.d/init.d/functions which runs during shutdown or reboot:
> > > rm -f "${pid_file:-/var/run/$base.pid}"
> > >
> > > It is obvious that $base includes the httpd/ subdirectory so that gets
> > > deleted too.
> > >
> > > Changing the pid file location away from /var/run/httpd/ can't be
> > > done. Even if the start up script in init.d is changed systemctl
> > > expects to find it there. So I changed the httpd.conf file to put it
> > > where systemctl wants it to be.
> > >
> > > In case anyone wonders, I can put the pid file anywhere during start
> > > up but if I do that systemctl hangs and then times out during startup
> > > with a message that the pid file is unreadable, leaving httpd running
> > > and an orphan. Also "systemctl stop httpd" hangs and httpd stays up.
> > > In this one case, "systemctl reboot" never completes; you end up
> > > having to push the reset button; although I would assume that in the
> > > fullness of time it might time out.
> > >
> > > "systemctl status httpd" in this case shows that httpd is NOT running
> > > due to a missing resource (the pid file) even though it is up and
> > > running fine.
> > >
> > > There is one obvious work-around, check for /var/run/httpd on startup
> > > in the init.d script, and it it isn't there, create it, but that begs
> > > the question of what am I not understanding.
> > >
> > > So, has anyone encountered this before. I sure hope it isn't a fat
> > > finger error on my part but two days is enough for something like
> > > this. I need help!
> > >
> > > Here is the relevant part of the (current) httpd.conf file in
> > > /usr/apache-2.4.25/conf/httpd.conf
> > >
> > > # Added with 2.4.25, 25/3/2017, to work with Fedora which won't
> > > # relocate the pid file to the default location
> > > PidFile /var/run/httpd/httpd.pid
> > > #
> > >
> > > and here is the complete init.d/httpd startup script. Mostly it was
> > > cribbed from the old server's (RHEL6 and apache-2.4.10) script. A
> > > lot of the commented lines are where I have been trying to find a
> > > solution to the problem. In general, one # is Red Hat's comments and
> > > two ## is my testing.
> > >
> > > #!/bin/bash
> > > #
> > > # httpd Startup script for the Apache HTTP Server
> > > #
> > > # chkconfig: - 85 15
> > > # description: The Apache HTTP Server is an efficient and extensible
> > > \ # server implementing the current HTTP standards. #
> > > processname: httpd
> > > # config: /etc/httpd/conf/httpd.conf
> > > # config: /etc/sysconfig/httpd
> > > # pidfile: /var/run/httpd/httpd.pid
> > > #
> > > ### BEGIN INIT INFO
> > > # Provides: httpd
> > > # Required-Start: $local_fs $remote_fs $network $named
> > > # Required-Stop: $local_fs $remote_fs $network
> > > # Should-Start: distcache
> > > # Default-Start: 2 3 4 5
> > > # Default-Stop: 0 1 6
> > > # Short-Description: start and stop Apache HTTP Server
> > > # Description: The Apache HTTP Server is an extensible server
> > > # implementing the current HTTP standards.
> > > ### END INIT INFO
> > >
> > > # Source function library.
> > > . /etc/rc.d/init.d/functions
> > >
> > > if [ -f /etc/sysconfig/httpd ]; then
> > >
> > > . /etc/sysconfig/httpd
> > >
> > > fi
> > >
> > > # Start httpd in the C locale by default.
> > > HTTPD_LANG=${HTTPD_LANG-"C"}
> > >
> > > # This will prevent initlog from swallowing up a pass-phrase prompt if
> > > # mod_ssl needs a pass-phrase from the user.
> > > INITLOG_ARGS=""
> > >
> > > # Set HTTPD=/usr/sbin/httpd.worker in /etc/sysconfig/httpd to use a
> > > server # with the thread-based "worker" MPM; BE WARNED that some
> > > modules may not # work correctly with a thread-based MPM; notably PHP
> > > will refuse to start. # Path to the apachectl script, server binary,
> > > and short-form for messages. # This was damaged by Red Hat system
> > > update 23/4/2013. Changed back to # probable initial code.
> > > #
> > > # Converted for new prod04 server 26/3/2017 JI
> > > #
> > > ## apachectl=/usr/sbin/apachectl
> > > apachectl=/usr/apache-2.4.25/bin/apachectl
> > > ## httpd=${HTTPD-/usr/sbin/httpd}
> > > httpd=${HTTPD-/usr/apache-2.4.25/bin/httpd}
> > > prog=httpd
> > > pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
> > > ##>>>pidfile=${PIDFILE-/usr/apache-2.4.25/logs/httpd.pid} <<-- this
> > > doesn't work
> > > lockfile=${LOCKFILE-/var/lock/subsys/httpd}
> > > RETVAL=0
> > > STOP_TIMEOUT=${STOP_TIMEOUT-10}
> > >
> > > # The semantics of these two functions differ from the way apachectl
> > > does # things -- attempting to start while running is a failure, and
> > > shutdown # when not running is also a failure. So we just do it the
> > > way init scripts
> > > # are expected to behave here.
> > > start() {
> > >
> > > echo -n $"Starting $prog: "
> > >
> > > ## LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
> > >
> > > $apachectl -k start
> > >
> > > RETVAL=$?
> > > echo
> > > [ $RETVAL = 0 ] && touch ${lockfile}
> > > return $RETVAL
> > >
> > > }
> > >
> > > # When stopping httpd, a delay (of default 10 second) is required
> > > # before SIGKILLing the httpd parent; this gives enough time for the
> > > # httpd parent to SIGKILL any errant children.
> > > stop() {
> > >
> > > echo -n $"Stopping $prog: "
> > >
> > > ## killproc -p ${pidfile} -d ${STOP_TIMEOUT} $httpd
> > >
> > > $apachectl -k stop
> > >
> > > RETVAL=$?
> > > echo
> > >
> > > ## [ $RETVAL = 0 ] && rm -f ${lockfile} ${pidfile}
> > >
> > > [ $RETVAL = 0 ]
> > >
> > > }
> > >
> > > reload() {
> > >
> > > echo -n $"Reloading $prog: "
> > > if ! LANG=$HTTPD_LANG $httpd $OPTIONS -t >&/dev/null; then
> > >
> > > RETVAL=6
> > > echo $"not reloading due to configuration syntax error"
> > > failure $"not reloading $httpd due to configuration syntax
> > > error"
> > >
> > > else
> > >
> > > # Force LSB behaviour from killproc
> > >
> > > # LSB=1 killproc -p ${pidfile} $httpd -HUP
> > >
> > > $apachectl -k restart
> > >
> > > RETVAL=$?
> > > if [ $RETVAL -eq 7 ]; then
> > >
> > > failure $"httpd shutdown"
> > >
> > > fi
> > >
> > > fi
> > > echo
> > >
> > > }
> > >
> > > # See how we were called.
> > > case "$1" in
> > >
> > > start)
> > >
> > > start
> > > ;;
> > >
> > > stop)
> > >
> > > stop
> > > ;;
> > >
> > > status)
> > >
> > > status -p ${pidfile} $httpd
> > > RETVAL=$?
> > > ;;
> > >
> > > restart)
> > >
> > > stop
> > > ;;
> > >
> > > status)
> > >
> > > status -p ${pidfile} $httpd
> > > RETVAL=$?
> > > ;;
> > >
> > > restart)
> > >
> > > stop
> > > start
> > > ;;
> > >
> > > condrestart|try-restart)
> > >
> > > if status -p ${pidfile} $httpd >&/dev/null; then
> > >
> > > stop
> > > start
> > >
> > > fi
> > > ;;
> > >
> > > force-reload|reload)
> > >
> > > reload
> > > ;;
> > >
> > > graceful|help|configtest|fullstatus)
> > >
> > > $apachectl $@
> > > RETVAL=$?
> > > ;;
> > >
> > > *)
> > >
> > > echo $"Usage: $prog
> > > {start|stop|restart|condrestart|try-restart|
> > >
> > > force-reload|reload|status|fullstatus|graceful|help|configtest}"
> > >
> > > RETVAL=2
> > >
> > > esac
> > >
> > > exit $RETVAL
> > >
> > >
> > > FYI, the usual "S" and "K" links are in /etc/rc[1-6].d directories.
> > > They were created automatically when I ran "systemctl enable" on
> > > httpd.
> > >
> > > Any suggestions as to where to go next would be appreciated!
> > >
> > > Regards,
> > >
> > > John
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > > For additional commands, e-mail: users-h...@httpd.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> > For additional commands, e-mail: users-h...@httpd.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
