Take the 2-minute tour ×

On our live production server, we forgot which folder our website was stored in. My colleague asked me where it was. I did not know but suggested to just run a search for the folder name on the server.

He responded that you can't do that, as it runs the risk of the server becoming unresponsive.

We ran into a little argument here, with my point of view that it is nonsense that a live production server would become unresponsive of running a find command that would take a minute.

But then again, I am not a server guru. What is your opinion?

share|improve this question

closed as too broad by Scott Pack, Dave M, mdpc, Ward, dawud Sep 13 '13 at 8:40


Which OS are you on? What command were you going to run? Are you searching in an indexed location? What kind of I/O load is there already on the disk subsystem? There are many variables at play here. –  Mark Henderson Sep 12 '13 at 9:59
"we forgot which folder our website was stored in" - I think its a very good time to relook your documentation –  Journeyman Geek Sep 12 '13 at 10:00
@JourneymanGeek: And learn about configuring $webserverofchoice –  Iain Sep 12 '13 at 10:01
The configuration file of your Apache / nginx / whatever should be able to tell you where the website is at. –  Jack Sep 12 '13 at 10:02
My opinion is that you both should be kept as far way from the server as possible. –  joeqwerty Sep 12 '13 at 13:36

3 Answers 3

I guess it would depend on how your server is loaded but I can't say I've ever known a find command make a server go unresponsive. If you're concerned about it then you could always use nice.

You don't say which OS/Distro or Webserver you're using but it may be easier to just look at the webserver config files. For example you can look for DocumentRoot directives in Apache.

As pointed out in the comments ionice may be more useful depending on your workload.

share|improve this answer
+1 Would have said the same thing. Except that I'd use ionice for this. –  lsmooth Sep 12 '13 at 10:04
Assuming Linux, disk based search would rarely hit CPU issues. ionice -c 3 might help. –  mtm Sep 12 '13 at 10:10

Well you don't mention which Operating System you're using but if it were either Windows or one of the production-oriented server flavours of Linux there's little to no risk of impacting service unless your actual IO chain is particularly slow or already overloaded. Searching can be a little intensive but shouldn't be so much so that it kills the box, I've seen older laptops use Windows and Outlook search to the detriment of the whole machine but never seen that in a server. If you want to really know then simply do some tests, both from an IO perspective and a client-response side.

Basically don't worry if it's once in a while.

share|improve this answer

grep your webserver configuration files

Why is no one mentioning the obvious solution? Assuming apache...

cat /etc/apache2/apache2.conf | grep 'DocumentRoot'

Or if you're using a virtual host...

cat /etc/apache2/sites-enables/virtualhost.conf | grep 'DocumentRoot'

Files may not be in those exact locations depending on your distro, but they should be under /etc and should be pretty easy to locate.

share|improve this answer
Because he didn't say the server uses apache. And even then the config could be elsewhere or use includes or have multiple VirtualHosts etc. –  lsmooth Sep 12 '13 at 10:06
except that there is no guarantee that that file will contain the required information, for example on CentOS it's /etc/http/conf/httpd.conf and it may also be split over several file in conf.d or sites-enabled etc depending on distro and OS –  Iain Sep 12 '13 at 10:07
@lsmooth Because there's no way you could grep an nginx/lighty config, right? That's apache specific. –  Suhosin Sep 12 '13 at 10:07
@iain If none of the configuration files contain the web root, I am very worried as to how it's serving files. –  Suhosin Sep 12 '13 at 10:09
@Jack: No, not at all. I was commenting on the comment If none of the configuration files contain the web root, I am very worried as to how it's serving files. which was commenting on an earlier comment of mine which itself was a comment on the original answer the OP provided which was debian/ubuntu/apache centric ;) –  Iain Sep 12 '13 at 10:21
