I have this container: 5.6.21-apache from https://hub.docker.com/_/php/
I have installed all I need and my application but I made a mistake doing something wrong with Apache configs.
When I try start my container I get this message:
docker start -ai my-container
[Mon May 02 19:46:33.358838 2016] [core:warn] [pid 1] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
[Mon May 02 19:46:33.365305 2016] [core:warn] [pid 1] AH00111: Config variable ${APACHE_LOG_DIR} is not defined
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
(2)No such file or directory: AH02291: Cannot access directory '/etc/apache2/${APACHE_LOG_DIR}/' for main error log
AH00014: Configuration check failed
How can I solve this? I want drop this configs. I can't just lose this container.
Since you haven't given enough information to go on, I'm just going to guess. Feel free to add more info to your questions so that it will be easier to help you.
If you search your apache config file and look for APACHE_LOG_DIR, it will probably point to your issue.
This line in the logs is interesting:
Cannot access directory '/etc/apache2/${APACHE_LOG_DIR}/'
Not sure why you would have a log directory under /etc/apache2, but look in that directory to see what you have in there, and set APACHE_LOG_DIR accordingly.
Another thing you can try is to do the following
docker commit (container name or Id) myimage
docker run -it myimage /bin/bash
Then commit changes again to create the fixed image and try to start it up like normal.
docker commit (container Id or name) myimage2
docker run -d -p 80:80 myimage2
Basically save the current container state as an image so you can start it up in a shell and fix the issues. Then once you have fixed the issues you can create a new image and use that to run your container.
I usually avoid this pain by not making changes directly in the containers, I only make changes in my dockerfiles and then when I need to make, I change the dockerfile. If there is an issue, I just need to fix the dockerfile, and the containers don't get in this bad state.
In my case after rebooting computer (or sleeping/restarting system) I have a problem with starting a container.
Before run start I use docker exec command.
Example:
docker exec -ti CONTAINER_NAME /bin/bash
(Have a message that container is not running and then)
docker start CONTAINER_NAME
Related
I have an issue in my SSH session with a docker container.
Actually can't execute any command because of a running process that never gives me hand on the terminal, see output:
[Thu Apr 02 19:39:46.056749 2020] [mpm_prefork:notice] [pid 7] AH00163: Apache/2.4.43 (Unix) PHP/7.3.16 configured -- resuming normal operations
[Thu Apr 02 19:39:46.057465 2020] [core:notice] [pid 7] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
Dockerfile install Apache on Alpine and ends:
ENTRYPOINT [ "/opt/entrypoint.sh" ]
entrypoint.sh:
/usr/sbin/httpd -D FOREGROUND
Any hint how I can get my SSH session working and gives me hand to execute other commands? Thank you.
The container paradigm does not promote usage of things like ssh servers. The core concept is that you are only hosting a single isolated process inside the container, in your case 'httpd'.
in other words, there is no ssh server running inside the apache container, it is only hosting the web server process.
You can use a command like docker exec <container_name> <command>, to execute another process in the same container. For example:
docker exec myhttpd ls -la
Which will list the content of the configured working directory in the container.
docker exec will connect the stdout and stderr in your current terminal session to the stdout and stderr of the container, and execute your command in the environment of the container.
This is a good solution for trouble shooting and trying things out. But look for alternatives if you are seeking to permanently change the environment of your contained application. Such as using the Dockerfile.
If you supply some more information about your usecase, I will be happy to make a suggestion.
Actually moving command from my dockerfile to the procfile provided by my hosting provider solved the issue.
Dockerfile after this change:
FROM alpine
# install apache
# other installation requirements
EXPOSE 80
# commented the line below
# ENTRYPOINT ["/opt/entrypoint.sh"]
And moved the last instruction to Procfile. After this change the process will be a service published from my container and not an entrypoint that will be executed each time the image built or restarted.
I followed the guide on https://blog.ssdnodes.com/blog/installing-nextcloud-docker/ and got the docker containers running.
I changed the port mappings of nextcloud-proxy to 7443:443, 780:80, since my server already has an apache running.
When I open the page foo.bar.com:7443, it shows me a server error 500 page by nginx.
docker logs --details nextcloud-proxy only shows me, that the error-500-page was successfully delivered.
docker logs --details nextcloud-app does not show any errors regarding the request. It only shows some messages during startup:
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.19.0.5. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.19.0.5. Set the 'ServerName' directive globally to suppress this message
[Mon Mar 04 19:23:01.413561 2019] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.25 (Debian) PHP/7.2.15 configured -- resuming normal operations
[Mon Mar 04 19:23:01.413653 2019] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
It is pretty clear, that there is an error with apache or php (both should be logged by nextcloud-app). But I need to see the error log entries. How do I do this?
Logs are redirected to nextcloud's data folder.
From your nextcloud's root, try with:
$ tail nextcloud/data/nextcloud.log
(or the folder you set for data storage).
It's even better if you run the nextcloud with this switch to mount it to a folder on your host, edit config/config.php to have finer-grained logs through setting loglevel, the run tail -f data/nextcloud.logs
docker run -v ~/Projects/nextcloud:/var/www/html -d -p 8080:80 nextcloud
<?php
$CONFIG = array (
'htaccess.RewriteBase' => '/',
...
...
...
'loglevel' => 0,
);
Restart the docker image by running docker restart YOUR_INSTNANCE_ID
Then docker exec -it YOUR_INSTNANCE_ID bash -c "tail -f /var/www/html/data/nextcloud.log"
In my case, it helped to configure Nextcloud to use stdout instead of a dedicated logfile for its logging output.
This allows you to see all the logs instead of just the php fpm output in the if you execute docker logs <yourcontainerid> or view it in Portainer or some other management software.
Just add the following to your config.php
"logfile" => "/dev/stdout",
I am new to docker. In our docker environment - Apache has been installed and it is up and running.
Now I need to get into the container, modify the httpd.conf, save it and then I need to restart the apache.
Can you guys please let me know, what needs to be done.
I am pretty much confused about -
'exec' and 'attach' commands.
No need to attach or exec (which is really a debug feature anyway)
You can use docker cp to copy a local version of your httpd.conf to the container. (That way, you can modify the file from the comfort of your local environment)
docker cp httpd.conf <yourcontainer_name>:/path/to/httpd.conf
Once that is done, you can send an USR1 signal to ask for a graceful restart (see docker kill syntax):
docker kill --signal="USR1" <yourcontainer_name>
Replace <yourcontainer_name> by the container id or name which is running Apache.
That will only work if the main process launched by your container is
CMD ["apachectl", "-DFOREGROUND"]
See more at "Docker: How to restart a service running in Docker Container"
To update Apache configs you need to:
Replace Apache configs.
If you have config folder mapped from outside of container you should update configs outside of container.
If your apache configs are stored inside of container, you will need to run something like this:
docker cp httpd.conf YOUR_CONTAINER_NAME:/path/to/httpd.conf
Do Graceful Apache restart:
sudo docker exec -it YOUR_CONTAINER_NAME apachectl graceful
Enter a container by opening a bash shell:
docker exec -it containerName bash
I guess you better just reload apache config and not reboot apache.
But I wouldn't go this route and just modify Dockerfile and rebuild and rerun the image.
edit for link: https://docs.docker.com/engine/reference/commandline/exec/
So I just recently downloaded Apache server with all of its files (httpd, apr, apr-util, pcre) following the instructions dictated here: http://httpd.apache.org/docs/2.4/install.html
However, after set-up, when I tried to start my Apache server, which is located in my usr/local/bin/, I was prompted with this message:
[allen#allen-lnx ~]$ /usr/local/bin/apachectl start
(13)Permission denied: AH00091: httpd: could not open error log file /usr/local/logs/error_log.
AH00015: Unable to open logs
After some research, I have found that I need to edit my httpd.conf file, which I did so earlier to allow for the correct ServerName and Listen options. However, I am unsure as to how to edit my conf file to allow for access to the "logs" directory.
Notably, the command will run when I use the "sudo" command, but I would prefer to not always use that since it seems like a work around.
Any help would appreciated. Thanks!
Edit: I've actually noticed that I may have two httpd.conf files, which is proving to be a little troublesome. The other one is located in my root /etc/ directory (etc/httpd/conf/httpd.conf). I think my modified question now is... which one should I be keeping? Is the /etc/ version the one that is built in, as indicated by faff's comment below?
Current Solution: I figured I would just accept the fact that I need to use sudo when editing this file since I need to be root. I might change it later so that I'm always running as root, but for now, sudo will suffice.
This looks like an issue with he filesystem permissions. Make sure the /usr/local/logs/ directory exists and is writeable by the user you're running Apache as.
If you don't want to have your logs directory writeable by normal user, you can create the log file:
sudo touch /usr/local/logs/error_log
And then change the owner of the file to the correct user:
sudo chown allen /usr/local/logs/error_log
Assuming you want to run Apache as the user allen.
If you want to change the location of Apache logfile, look for the ErrorLog directive in your httpd.conf file (you will have to add it if it's not there):
ErrorLog path/to/logfile
For everyone that is using SELinux, if you deleted the folder or come across similar problems you may need to do several things.
Re-link the folder with ln -s /var/log/httpd /etc/httpd/logs
By default logs are kept under the var folder but are referenced in the /etc/httpd/logs folder
Apply SELinux security permissions with chcon system_u:object_r:httpd_config_t:s0 /etc/httpd/logs
And of course run everything as admin
Changing SELinux security policy to permissive fixed my problem.
Before fix my SELinux worked with enforced mode:
$ sestatus -v
sestatus -v
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
I changed security policy in SELinux configuration file and in the system.
#/etc/selinux/config
SELINUX=permissive
# In terminal set SELinux to run in permissive mode.
$ setenforce 0
After fix my SELinux worked with enforced mode:
$ sestatus -v
SELinux status: enabled
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 30
For those who are stuck with the SElinux policies, I was able to do it by creating a custom policy
Basically I wanted to move the /var/log/httpd to my own directory under /r/
So I run the following
semanage fcontext -a -t httpd_sys_content_t "/r/www(/.*)?"
semanage fcontext -a -t httpd_log_t "/r/logs(/.*)?"
restorecon -Rv /z/logs/
restorecon -Rv /z/www/
service httpd restart
# worked
The issue
Now, I am a complete n00b on Apache, and I could certainly use some help with my current issue. I have installed the httpd rpm's on 3 different systems (all Advantech computers, 1 Box PC, 1 Advanced TCA blade, 1 Compact PCI blade, and all have RHEL6 installed). I have configured Apache with files used earlier, on other installations. When I issue the command
# service httpd restart
All goes well and I get this output:
Stopping httpd: [ OK ]
Starting httpd: httpd: apr_sockaddr_info_get() failed for <PC_Name>
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
[ OK ]
Now, when I try to connect to the machine via Apache, I get the log-in screen asking for the username and password, as you would expect. However, it fails to log-in. When I look at the error_log in /var/log/httpd/, it shows this error message:
[Thu Sep 15 14:24:40 2011] [error] [client 192.168.10.175] (13)Permission denied: Could not open password file: /etc/shadow
[Thu Sep 15 14:24:40 2011] [error] [client 192.168.10.175] PAM: user 'root' - not authenticated: System error
It seems to me that this is either a configuration error, or it has something to do with permissions. Yet I can't seem to find out which. Another interesting fact is, that this only applies to the last two installations(Advanced TCA & Compact PCI), and not the first (Box PC), while all 3 installations are exactly the same.
Additional Info
The way I installed it was install httpd from yum,
# yum install httpd
Next install mod_auth_pam, which is needed by the configuration,
# yum install mod_auth_pam
Then I configured Apache with the files I got from previous installations (which basically is just replacing the configuration files from the standard Apache install), and after that I restarted the Apache service.
For this error "apr_sockaddr_info_get() failed"
You need to properly set your hostname.
hostname actual-non-expired-domain-name.com
Don't forget to set the name in your httpd.conf and in /etc/hosts as well.
I have been able to solve this by setting SELinux to allow Apache requests. This is done by issuing the following command:
semanage permissive -a http_t
Semanage is a utility from the policycoreutils-python package. This should come with the installation medium.