I recently upgraded my Mac's OS from Lion to Lion Server, which changes how the httpd.conf settings are read when Apache is started. In particular, environment variables like WEBSHARING_ON and MACOSXSERVER are set by the Server.app process, so that extra modules and files are read in when Apache is started.
So now, to restart the Apache server with all the proper settings and modules loaded, I have to use the command:-
sudo serveradmin stop web && sudo serveradmin start web
Previously, I would run:-
sudo apachectl -S
sudo apachectl graceful
I prefer the latter method by far. For one thing, the command returns much quicker, and I also imagine that the apache / httpd server process doesn't completely terminate, just the settings are reloaded.
So, is there a way to gracefully restart Apache in Lion Server?
The quick answer is no.
The 'apachectl' program is actually just a shell script, so (after realising this) it's easy to see what it's doing, and why it's not doing what I expected.
When restarting Apache (gracefully or otherwise) on a Mac, the relevant launchctl job is just unloaded and reloaded, which I imagine is not as per the official Apache description of a graceful restart:
The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they're not serving anything)
The reason apachectl -S doesn't show the configured virtual servers is because this command is not run by launchctl, and so the environment variables set in /System/Library/LaunchDaemons/org.apache.httpd.plist are not loaded.
So, apachectl graceful, apachectl restart and others do load the proper variables, and therefore read the config files properly, but not all commands do by default.
To overcome this, I've manually edited /usr/sbin/apachectl, as below. All I did was add "-D MACOSXSERVER -D WEBSERVICE_ON" where appropriate.
case $ARGV in
start)
run_launchctl load -w $LAUNCHD_JOB
ERROR=$?
;;
stop|graceful-stop)
run_launchctl unload -w $LAUNCHD_JOB
ERROR=$?
;;
restart|graceful)
run_launchctl unload -w $LAUNCHD_JOB 2> /dev/null
run_launchctl load -w $LAUNCHD_JOB
ERROR=$?
;;
startssl|sslstart|start-SSL)
echo The startssl option is no longer supported.
echo Please edit httpd.conf to include the SSL configuration settings
echo and then use "apachectl start".
ERROR=2
;;
configtest)
$HTTPD -t -D MACOSXSERVER -D WEBSERVICE_ON
ERROR=$?
;;
status|fullstatus)
echo Go to $STATUSURL in the web browser of your choice.
echo Note that mod_status must be enabled for this to work.
;;
*)
$HTTPD $ARGV -D MACOSXSERVER -D WEBSERVICE_ON
ERROR=$?
esac
Related
System release: CoreOS 2135.5.0
Kernel: 4.19.50-coreos-r1
System install way: vmware
When I change the port in the sshd.service，it displays:
CoreOS-234 ssh # echo "Port 10000" >> /usr/share/ssh/sshd_config ;systemctl mask sshd.socket;systemctl enable sshd.service;systemctl restart sshd.service
-bash: /usr/share/ssh/sshd_config: Read-only file system
The file system that you are working in is currently in Read-only mode. Remounting the file system to read-write should resolve the issue. You will need to have root privilages:
$ mount -o remount,rw /
Occasionally the reason your file system will be running in read-only mode is due to Kernel issues, therefore there may be further problems with the system that will need to be debugged. Regarding the Kernel errors you may want to have a look at the following link: https://unix.stackexchange.com/questions/436483/is-remounting-from-read-only-to-read-write-potentially-dangerous?rq=1
In coreos /usr is designed to be a read-only file system, Remounting /usr is theoretically feasible, but is not officially recommended
You can refer to this
I use the following command to solve this problem
sudo sed -i '$a\Port=60022' /etc/ssh/sshd_config && \
sudo systemctl mask sshd.socket && \
sudo systemctl enable sshd.service && \
sudo systemctl start sshd.service
I am using Kirby on Ubuntu 16.04, and every time I reboot I have to login on my server, go to my website folder and type
sudo php -S 0.0.0.0:80
for the server to start.
What's a correct way of getting this to start automatically after a reboot?
Sorry for the trivial question, I just don't seem to be able to find a simple answer on the web...
You can use root's crontab with #reboot directive. Edit it with sudo crontab -e
#reboot cd /path/to/directory && php -S 0.0.0.0:80
Notice that there is no sudo before the php command, because it's run from root's crontab.
I'm running Apache2 in a docker container and want to write nothing to the disk, writing logs to stdout and stderr. I've seen a few different ways to do this (Supervisord and stdout/stderr, Apache access log to stdout) but these seem like hacks. Is there no way to do this by default?
To be clear, I do not want to tail the log, since that will result in things being written to the disk in the container.
The "official" version checked into Docker Hub (https://hub.docker.com/_/httpd/) still write to disk.
Also, what do I need to do to stop Apache from failing when it tries to roll the logs?
One other thing - ideally, I'd really like to do this without another add-on. nginx can do this trivially.
I'm not positive that this won't mess with httpd's logging at all (e.g. if it tries to seek within the file), but you can set up symlinks from the log paths to /dev/stdout and /dev/stderr, like so:
ln -sf /dev/stdout /path/to/access.log
ln -sf /dev/stderr /path/to/error.log
The entry command to the vanilla httpd container from Docker Hub could be made to be something like
ln -sf /dev/stdout /path/to/access.log && ln -sf /dev/stderr /path/to/error.log && /path/to/httpd
According to the apache mailing list, you can just directly write to /dev/stdio (on Unix like systems) as that's just a regular ol' file handle. Easy! Pasting...
The most efficient answer depends on your operating system. If you're
on a UNIX like system which provides /dev/stdout and /dev/stderr (or
perhaps /dev/fd/1 and /dev/fd/2) then use those file names. If that
isn't an option use the piped output feature. For example, from my
config:
CustomLog "|/usr/sbin/rotatelogs -c -f -l -L
/private/var/log/apache2/test-access.log
/private/var/log/apache2/test-access.log.%Y-%m-%d 86400 "
krader_custom ErrorLog "|/usr/sbin/rotatelogs -c -f -l -L
/private/var/log/apache2/test-error.log
/private/var/log/apache2/test-error.log.%Y-%m-%d 86400"
Obviously you'll want to substitute another program for
/usr/sbin/rotatelogs in the example above that writes the data where
you want it to go.
https://mail-archives.apache.org/mod_mbox/httpd-users/201508.mbox/%3CCABx2=D-wdd8FYLkHMqiNOKmOaNYb-tAOB-AsSEf2p=ctd6sMdg#mail.gmail.com%3E
I know it's an old question, but I had this need today.
On an Alpine 3.6, the following instructions, in httpd.conf, are working:
Errorlog /dev/stderr
Transferlog /dev/stdout
I add them to my container this way:
FROM alpine:3.6
RUN apk --update add apache2
RUN sed -i -r 's#Errorlog .*#Errorlog /dev/stderr#i' /etc/apache2/httpd.conf
RUN echo "Transferlog /dev/stdout" >> /etc/apache2/httpd.conf
...
I adjusted config, as from the Dockerfile recipe of httpd, they use sed to adjust the config, to change ErrorLog and CustomLog as follows:
sed -ri ' \
s!^(\s*CustomLog)\s+\S+!\1 /proc/self/fd/1!g; \
s!^(\s*ErrorLog)\s+\S+!\1 /proc/self/fd/2!g; \
' /usr/local/apache2/conf/httpd.conf \
See https://github.com/docker-library/httpd/blob/master/2.4/Dockerfile (towards the end of the file)
You can send your ErrorLog to syslog directly, and you can send any CustomLog (access log) to any executable that reads from stdin. There are log aggregation tools, or you can again use syslog w/ e.g. /usr/bin/logger.
You could try using the dockerize tool. With that you could wrap the httpd-foreground command and redirect its log files to stdout/stderr (don't know exactly the httpd log file paths, simply adjust them to your needs):
CMD ["dockerize", "-stdout", "/var/log/httpd.log", "-stderr", "/var/log/httpd.err", "httpd-foreground"]
In addition to that you could grab that containers stdout/stderr then by specifying a syslog log driver and redirect them to the /var/log/syslog log file on the docker host:
docker run -d --log-driver=syslog ...
I'm running a Docker container with CoreOS which uses Debian latest as a base and has various packages installed including supervisor and apache2. I can start and successfully run apache using the following command:
# /usr/bin/pidproxy /var/run/apache2.pid /bin/bash -c "source /etc/apache2/envvars && /usr/sbin/apache2 -DFOREGROUND -k start"
However, when I stick this command in a supervisor config file:
[program:apache2]
command=/usr/bin/pidproxy /var/run/apache2.pid /bin/bash -c "source /etc/apache2/envvars && /usr/sbin/apache2 -DFOREGROUND -k start"
redirect_stderr=true
and do this:
# supervisorctl start apache2
I get back this response:
apache2: ERROR (abnormal termination)
Looking at the supervisor process log file I see the help output from the apache2 command, as if it had been called like so apache2 -h. I have no idea why a command which runs when executed on the command line as root (ssh into the container) would not work when verbatim executed by supervisorctl (run as root).
Any point in the right direction would be greatly appreciated.
Not really sure why, but adding quotes to my option values seems to have done the trick, and allowed me to use apachectl. Must be something with the context in which the command is interpreted, whatever supervisor is doing vs input from a bash prompt. Here's my working config file:
[program:apache2]
command=apachectl -D "FOREGROUND" -k start
redirect_stderr=true
You really want to use this. If you don't use pidproxy, a supervisorctl stop apache will not kill all it's children.
This will also make sure that the container will quit when it gets a SIGTERM instead of waiting for a SIGKILL.
[program:apache]
command=/usr/bin/pidproxy /var/run/apache2/apache2.pid /bin/bash -c "/usr/sbin/apache2ctl -D FOREGROUND"
autorestart=true
This is what works for me (using an ubuntu base image, but that should not matter):
Dockerfile:
# Pull Ubuntu as base image
FROM dockerfile/ubuntu
...
# Install supervisor to allow starting mutliple processes
RUN apt-get -y install supervisor && \
mkdir -p /var/log/supervisor && \
mkdir -p /etc/supervisor/conf.d
RUN mkdir /var/log/supervisord
# Add supervisor configuration
ADD etc/supervisor/supervisor.conf /etc/supervisor.conf
# Install Apache and enable CGI
RUN apt-get install -y apache2
ADD etc/apache/000-default.conf /etc/apache2/sites-available/000-default.conf
RUN a2enmod cgi
....
supervisor.conf
[supervisord]
; supervisord log file
logfile=/var/log/supervisord/supervisord.log
; info, debug, warn, trace
loglevel=debug
; pidfile location
pidfile=/var/run/supervisord.pid
; run supervisord as a daemon
nodaemon=false
; number of startup file descriptors
minfds=1024
; number of process descriptors
minprocs=200
; default user
user=root
; where child log files will live
childlogdir=/var/log/supervisord/
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; Apache server
[program:apache2]
command=/usr/sbin/apache2ctl -D FOREGROUND
environment=APACHE_LOG_DIR=/var/log/apache2
redirect_stderr=true
In CentOS apache is Called httpd not apache2
Your supervisor conf file will need to be updated for CentOS
/usr/sbin/httpd is the program location.
[program:apache2]
command=/usr/bin/pidproxy /var/run/httpd.pid /bin/bash -c "/usr/sbin/httpd -DFOREGROUND -k start"
redirect_stderr=true
I am setting up a Debian Etch server to host ruby and php applications with nginx. I have successfully configured inittab to start the php-cgi process on boot with the respawn action. After serving 1000 requests, the php-cgi worker processes die and are respawned by init. The inittab record looks like this:
50:23:respawn:/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 8000 -C 3 -u someuser -- /usr/bin/php-cgi
I initially wrote the process entry (everything after the 3rd colon) in a separate script (simply because it was long) and put that script name in the inittab record, but because the script would run its single line and die, the syslog was filled with errors like this:
May 7 20:20:50 sb init: Id "50" respawning too fast: disabled for 5 minutes
Thus, I got rid of the script file and just put the whole line in the inittab. Henceforth, no errors show up in the syslog.
Now I'm attempting the same with thin to serve a rails application. I can successfully start the thin server by running this command:
sudo thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start
It works apparently exactly the same whether I use the -d (daemonize) flag or not. Command line control comes immediately back (the processes have been daemonized) either way. If I put that whole command (minus the sudo and with absolute paths) into inittab, init complains (in syslog) that the process entry is too long, so I put the options into an exported environment variable in /etc/profile. Now I can successfully start the server with:
sudo thin $THIN_OPTIONS start
But when I put this in an inittab record with the respawn action
51:23:respawn:/usr/local/bin/thin $THIN_OPTIONS start
the logs clearly indicate that the environment variable is not visible to init; it's as though the command were simply "thin start."
How can I shorten the inittab process entry? Is there another file than /etc/profile where I could set the THIN_OPTIONS environment variable? My earlier experience with php-cgi tells me I can't just put the whole command in a separate script.
And why don't you call a wrapper who start thin whith your options?
start_thin.sh:
#!/bin/bash
/usr/local/bin/thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start
and then:
51:23:respawn:/usr/local/bin/start_thin
init.d script
Use a script in
/etc/rc.d/init.d
and set the runlevel
Here are some examples with thin, ruby, apache
http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin
http://blog.fiveruns.com/2008/9/24/rails-automation-at-slicehost
http://elwoodicious.com/2008/07/15/nginx-haproxy-thin-fastcgi-php5-load-balanced-rails-with-php-support/
Which provide example initscripts to use.
edit:
Asker pointed out this will not allow respawning. I suggested forking in the init script and disowning the process so init doesn't hang (it might fork() the script itself, will check). And then creating an infinite loop that waits on the server process to die and restarts it.
edit2:
It seems init will fork the script. Just a loop should do it.