0

I've an instance running CentOS 7. And I'm having a difficulty when/if I restart httpd.

My configuration is working fine, my sites are broadcasted as I wanted; moreover, when I execute the command sudo apachectl configtest, I get back Syntax OK.

But when I restart httpd, it fails to comply with the following status message:

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2018-08-28 12:30:26 CEST; 6s ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 9569 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
  Process: 9568 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
 Main PID: 9568 (code=exited, status=1/FAILURE)

Aug 28 12:30:26 vps httpd[9568]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Aug 28 12:30:26 vps httpd[9568]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Aug 28 12:30:26 vps httpd[9568]: no listening sockets available, shutting down
Aug 28 12:30:26 vps httpd[9568]: AH00015: Unable to open logs
Aug 28 12:30:26 vps systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Aug 28 12:30:26 vps kill[9569]: kill: cannot find process ""
Aug 28 12:30:26 vps systemd[1]: httpd.service: control process exited, code=exited status=1
Aug 28 12:30:26 vps systemd[1]: Failed to start The Apache HTTP Server.
Aug 28 12:30:26 vps systemd[1]: Unit httpd.service entered failed state.
Aug 28 12:30:26 vps systemd[1]: httpd.service failed.

I get that something else is working in place of httpd when I restart it. Therefore I execute netstat -tulpn | grep :80.

tcp        0      0 0.0.0.0:8060            0.0.0.0:*               LISTEN      2560/nginx: master  
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2560/nginx: master  
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      1434/unicorn master 
tcp        0      0 127.0.0.1:8082          0.0.0.0:*               LISTEN      1307/sidekiq 5.1.3 

The above result kind of confuses me since I don't have Nginx installed on my system and which nginx also returns nothing.

However, when I reboot my instance, httpd works as intended.

What should I do to resolve my issue?

1
  • 3
    you have the process id from nginx, you can use ps -Af |grep $pid to see the full path of the program. – Gerald Schneider Aug 28 '18 at 12:20
1

Ok, mystery solved; thanks to Gerald Schneider.(although it was not a trojan, thankfully)

Executing ps -Af | grep $pid gave me some more insight and highlighted GitLab to my attention.(I knew there was something fishy about it but couldn't get to the root cause of the issue and identify it properly)

httpd was conflicting with gitlab. Once I executed sudo gitlab-ctl stop and then tried restarting httpd, everything was business as usual.

Also, this question gives some more insight into Apache - GitLab - Nginx dilemma.(and the first mention is that Apache and GitLab contradicts on port 80 :])

1
  • I'm guessing you are using an omnibus installation. Change the port and set up Apache as a reverse proxy (be warned SSL in proxy termination is a pain for GL to configure) docs.gitlab.com/omnibus/settings/… – Jan Dorniak Aug 28 '18 at 15:57
0

You can use systemctl command to identify the running service.

In your case systemctl list-unit-files | grep nginx

Example

systemctl list-unit-files | grep nginx
nginx-nr-agent.service                 generated
nginx.service                          enabled  

After that you can find more information about the running service with the command systemctl status servicename

Example

● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-08-28 15:03:08 EEST; 47min ago
     Docs: man:nginx(8)
  Process: 1455 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid (code=exited, status=0/SUCCESS)
  Process: 1460 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 1458 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 1462 (nginx)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nginx.service
           ├─1462 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           └─1463 nginx: worker process

Probably ExecStop and ExecStart will help you to identify where the binary located.

1
  • 1
    Chances are slim that a systemd unit exists when nginx has not been installed via system packages. And there is still the possibility that it isn't an actual nginx, but rather a trojan. – Gerald Schneider Aug 28 '18 at 13:00
-3

master is used by postfix in linux servers. Try stopping postfix by the following command

/sbin/service postfix stop

Also if postfix is not required for your configuraton, you can stop it from restarting when the server reboots, by the following command

chkconfig postfix off

Also from the error it is clear that you are trying to start httpd on 0.0.0.0:80. Try to use an ip address in httpd.conf file instead for getting more specific error.

Now try stopping and restarting httpd service.

4
  • 1
    the postfix process is direcly called master, not nginx: master. And postfix usually does not block port 80. There is surely is an nginx running, the question is just where it is located. – Gerald Schneider Aug 28 '18 at 12:45
  • Anyway he said nginx is not installed. You can try stopping nginx by 'nginx -s stop' command to see the results. – Dileep KK Aug 28 '18 at 12:54
  • The OP most probably only checked the system packages if it is installed. It still can have been compiled from source. If which nginx has no result nginx is clearly not in the path, so nginx -s stop gains nothing. – Gerald Schneider Aug 28 '18 at 12:58
  • Moreover, I tried stopping postfix and then restarting httpd. Didn't help. – Can Sürmeli Aug 28 '18 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.