Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a dell server running redhat 9.
It came with apache 2 already installed and I've just
started playing with apache 2.2.
When I try to stop apache 2.2, it does stop, but it also
does something to the old instance of apache - It is still
running (as I can see webpages from it) but it no longer
shows up as a process??? I threw together a little cgi-script
and put it where the websever can get it, and it tells me that
it can see itself with a "ps -ef" and now I know its pid, but
I cannot kill it.
from my searching, it appears to have become a "hidden process"
i guess, but I can find nothing that helps me stop the server
without pulling the plug - I did try a shutdown, and it shutdown
everything but the apache2.0 server and hangs (hence the pulled plug).
any info would be helpful, any questions that might shed more
light on this are more than welcome.
-bluerover
Last edited by bluerover6; 08-09-2006 at 03:41 PM.
Are you saying that if you run ps -ef from the commandline it doesn't show up, but if you do it from the webserver it does?
That doesn't sound right.
When you see the running processes are they owned by root or by your webserver username (typically nobody, apache or www-data)? If owned by root, that is the initial instance of apache, any children should be owned by the username as defined in the config.
You should be able to kill any active processes using
Code:
kill -9 <processid>
as the root user. You would want to kill the root owned process, which should then close all the others.
_______________
See that from inside, the process 11721 is the root of the hidden apache server,
when I issue the kill command that follows, well, you see the results ...
# kill -9 11721
-bash: kill: (11721) - No such process
Definitely not right!
-Bluerover
Last edited by bluerover6; 08-15-2006 at 10:02 AM.
My First Thoughts (now dismissed)
---
One thing that may show that would be running apache through inetd (xinetd).
If so then you would only see the apache daemon running when it is called from inetd, so it would only exist when serving requests. So when you run ps from inside a request it shows up as it is running the daemon to handle that request.
I don't think that is the case here though as you don't appear to be running inetd (worth checking).
Perhaps another explanation is whether something is restarting the daemon, and it is then crashing, but being restarted again. This could be the case if you started the daemon from inside inittab with the respawn option, or if you had a monitoring application that was restarting it (e.g. something like Tivoli or Patrol etc...).
None of these are normally used by default.
---
After writing the above I then looked at the times in the ps, and although it looks like the client processes have only been started recently the parent process has been running for a few days, so it looks like that rules out the above ideas ...
Can you try using sudo to run the command as user apache, and even try a kill -9 from that to see if that shows up. That should effectively be doing the same as the web page does, but I can't see why it wouldn't show as root.
i tried to su to apache, but from there it is no better than from root,
i see the same processes and kill -9 has the same results.
"service httpd stop" will stop the new apache, but not the old one
- it just replies [FAILED]
"apachectl stop" replies: no such process.
it's appears to be behaving as if there are two parallel process tables -
one that i can see, and the one that is running - thought of a system
compromise crossed my mind, i've checked into this and can tell nothing.
it does not appear to have been plied by some root-kit, but i could be wrong.
How about the chkconfig tool?
#chkconfig --list
then check out if you find the real name of that second Apache thing.
If it is like apache2 then..
#chkconfig apache2 off
next boot it should be gone ;-)
Yep what odcheck said. chkconfig --list then for example once you find the name in the list you would type:
chkconfig httpd off
then it would not start at boot time.
The apache service has always been called httpd on my RH servers. So (as ocheck said previously) type:
service httpd stop
That should stop the apache service.
You might also do a:
rpm -qa | grep http
this should find out how many apache modules you have out there. I would be tempted to uninstall all of them, reboot then install the version you want.
Distribution: Gentoo Hardened using OpenRC not Systemd
Posts: 1,495
Rep:
Quote:
Can you try using sudo to run the command as user apache, and even try a kill -9 from that to see if that shows up. That should effectively be doing the same as the web page does, but I can't see why it wouldn't show as root.
Code:
sudo -u apache ps -ef
sudo is an Ubuntu thing. Without sudo, he will need a root account (Ubuntu does not have by default). He will need to login as root with this command.
Code:
su -
Last edited by fakie_flip; 08-17-2006 at 10:50 AM.
So for what is the command visudo and the sudoers file?
Your're right thats a standard Ubuntu configuration but its also usable for other types of Distributions.
But never the less.. could we yet give bluerover6 a clue on how to fix his apache thing? @bluerover6 did that work what fakie flip told you?
my objective in killing the hidden apache process is not simply to stop it, but to regain control - at the moment i can't alter the httpd.conf to add new virtual servers or change allow/deny on directories... anything. the apachectl script fails to find the process - it appears that anything from outside the hidden server can't get to it. the old apache does not even show up under the /proc directory. I get the impression that all these tools rely on processes being under that directory to find other processes -- of course when i list the /proc directory from inside the webserver, i can see all the hidden processes.
somehow i need to get the old apache to either reveal itself under /proc in order for any admin operations to affect it from the command line, another possibility would be to somehow get one of the old apache child processes to become root and kill it from the inside, but i don't know how to do that short of hacking in a root-kit.
does anyone know of methods that can be used that would cause the old apache to just stop on its own (and i don't mean direct admin functions as all the suggestions have buzzed around, but something more basic to the old apache itself -
maybe something along the line of renaming a path or the permisions to write in logs
i don't want to simply wipe the old apache out after a reboot (which i can't do cleanly anyhow since shutdown hangs on this).
killall apache (as root) replies "no process killed".
i still want the old apache started in the init scripts - the new apache is what
i'm experimenting with, so it's not ready to be the main stay yet. ergo, i am not
removing its rpm. the new apache is from compiled source (there is no rpm) - which i have loaded on a few other hosts to try and see if i can reproduce the effect on another system, and everything on the other systems work just fine and this problem does not appear.
the main reasons i'm very reluctant to pull the plug are 1) the machine sits at a co-location site 2 hours drive away, and 2) with 4 Tbytes spinning an integrity check after an "unplanned" shutdown takes over an hour.
the original plan was to have the old apache run on the current IP's and the new apache to run on new IP's then change the DNS and wait for the named cached records in the cloud to refresh and then shutdown the old apache - all to maintain zero downtime. (so much for the plan.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
