I have apache pointing to a symbolic link for a website. I'm using capistrano to deploy the code so it updates the symbolic link to point to the new release
After capistrano updates the symbolic link to the new release directory apache uses the previous release directory.
The weird thing is it doesn't happen all the time. After a deploy everything either works fine or apache follows the previous link until i restart or reload apache.
any ideas?
This may depend on Apache httpd holding a handle on the old symlink. As long as that is the case the old data (symlink) is not thrown away in Unix based filesystems.
It seems you are unable to predict whether this is the case. Maybe use of lsof can help. What could also help is to trigger a graceful restart of httpd.
Related
I was trying to get the Apache server to work. When I was done with it I uninstalled the service and deleted all the server files. However I noticed even after all that going to localhost address shows me this page
How do I go on about removing this page from my localhost? Thanks
To expand on the previous comment ... after killing all httpd processes (and this may be a problem because Apache will respawn children) ... then reboot the system to see if the problem persists.
If it does persist, then Apache has not been uninstalled and it'll have to be uninstalled. If the system uses sysvinit, look in /etc/init.d for a script that starts Apache and disable that script.
If the problem does not persist then Apache was properly uninstalled and the problem will not recur.
I am using Apache httpd on localhost to connect to the project I'm working on, I have been deleting web cache when website is showing the old project instead of the new one. However recently the project is stuck on an outdated version and restarting/clearing cookies won't work with the user I'm assigned.
I tried using another user with my project and it works just fine. I recently did use svn revert which may have caused my user to get stuck with old project, but I'm not sure that's the problem.
Commands I use to start and stop:
sudo service httpd start
sudo service httpd stop
Any advice or tips are greatly appreciated.
Update: I managed to get the page to update the html, however my JavaScript won't load which I suspect is due to another user being stored and thus not accessing the database I use which leads to nothing being generated.
(Posted on behalf of the OP).
I got everything to "work" again by accident, I made some edits to PHP and my PHP crashed because of a syntax error. When I fixed it back to original stage it was working again. It most likely is related to a user the previous owner created that caused the problem.
Just clear Temporary files
In windows CTRL+R and type %temp% and delete all the files it will help to you
I have an application with some cacheing backend and I want to clear the cacheing whenever the webserver is been restarted.
Is there a apache configuration directive or any other way to execute a shell script upon webserver (re)start?
Thanks,
Phil
Adding some more information, as asked by some answers already:
Base system is ofc linux based, in this exact situation: CentOs
Modifying the startup script is unfortunately no option as pointed out by one of the comments already, due to it beeing not configuration file within the respective RPM packages and therefor beeing replaced by updates. Also I think modifying the startup script would be a bad thing in general
I see, that actually linking both "restarting the webserver" and "clearing my app cache" is not exactly what should be tied together. I will consider other alternatives
My situation is as follows: I can define how the virtual host config looks like, but I can not define how the rest of the servers configuration looks like.
The application is actually PHP based (and runs on the symfony framework). Symfony pre-compiles alot of stuff into dynamic php files from what it finds in the static configuration files. We deploy our apps via RPM and after deployment, an webserver restart is actually initiated already, so I thought it might make sense to tie the cache-cleanup to it. But I think after getting all your feedback, it looks like it is better to put the cache cleanup process into the installation process itself.
You haven't provided a lot of detail here, so it's hard to give a concrete answer, but I would suggest that your best option is to write a script which handles restarting apache, and clearing your cache. It would look something like this:
#!/bin/sh
# restart apache
/etc/init.d/httpd graceful
# whatever needs to be done to clear cache
rm -rf /my/cache/dir
Ramy suggests modifying the system startup script for Apache -- this is a bad idea! If and when you update Apache on your server, there is a good chance that your change will be lost.
Dirk suggests that what you are trying to do is probably misguided, and I think he's right. You haven't told us what platform you are running, but I can think of few situations where restarting your webserver and clearing a cache actually need to happen together.
You can modify Startup script for the Apache Web Server in /etc/init.d/httpd and write your own syntax inside it.
chattr +i /etc/init.d/httpd
If you have (root) access to the server you could do this by shell scripts but I would consider if it is the best way of cache management to rely on apache restarts.
Is there a way to include configuration settings in Apache based on if a directory exists? Basically I have a portable hard drive that I transport between work and home that has some stuff I'm developing on it. I only want the Apache config to load a particular virtual host if the folder exists.
Since Apache 2.4.34 you can now use <IfFile>...</IfFile> which will check to see if a file exists. There's more details on the <IfFile> page.
No, there seems to be no direct way to do this.
The only thing that might be a solution is the IfDefine directive. You can define defines using the -d parameter to when the server is started.
The parameter-name argument is a define as given on the httpd command line via -Dparameter-, at the time the server was started.
You might be able to check for the existence of a directory in a batch or bash file, and set the -d parameter accordingly.
Whether that is an option, will depend on how your server is started from the portable hard drive.
I've come up with a solution that seems to work for Linux and OS X, and it hinges on "mountpoints". It might be possible to emulate it within Windows, as well, but you would probably have to get creative with FUSE and/or Cygwin.
If you create an empty folder in your home directory, such as "/Users/username/ExtraVhosts", you can add an apache directive to "Include /Users/username/ExtraVhosts/*".
Then, when you insert your thumb drive, you can mount somewhere and then use mountpoint "binding" to cross-link the ExtraVhosts folder to a folder on the mobile device.
An OS X example:
I have a thumb drive called 'Cherrybomb'
When I insert it, it always gets mounted to /Volumes/Cherrybomb
I can then use bindfs (sudo port install bindfs) to mount a subfolder of it, like so:
sudo bindfs /Volumes/Cherrybomb/Projects/vhosts /Users/username/ExtraVhosts
Then I can restart apache to read in the updated configuration:
sudo /opt/local/apache2/bin/apachectl restart
At that point, it's just a matter of adding entries in /etc/hosts for server aliases to get picked up.
The linux equivalent would be using the "--bind" parameter of the mount command.
One caveat: This makes it difficult to quickly unmount the USB drive, since it is always marked as "in use" by apache. Here's a removal procedure:
Close all open files and terminal sessions that are using the drive (the present-working-directory in terminal can cause unmount issues)
Stop apache: sudo /opt/local/apache2/bin/apachectl stop
umount /Users/username/ExtraVhosts
Then you can either unmount it graphically or manually (umount /Volumes/Cherrybomb).
If your work and home machines mount the drive to different locations, you could have multiple vhosts folders - home_vhost, work_vhost, etc - and use that in the binding step.
I hope this helps someone out :)
If you point apache to the mountpoint only there shouldn't be an issue. Just don't point Directory directives to directories within the drive.
eg, if you mount /dev/somedisk /mnt/somevhost, the
/mnt/somevhost directory will be there whether or not you have the drive mounted and apache will start. Apache doesn't care if the directory is empty so a <Directory "/mnt/somevhost"/> won't cause server to not start if the drive isn't mounted.
Work with UNIX not against it :-p This solution should be sufficient for development.
we are looking for a way to point our Apache DocumentRoot to a symlink.
E.g. DocumentRoot /var/www/html/finalbuild
finalbuild should point to a folder somewhere like /home/user/build3
when we move a new build to /home/user/build4 we want to use a shell script that changes the symbolic link "finalebuild" to this new directory /home/user/build4 and do an apache graceful restart to have a new web application version up and running with little risk.
What's the best way to create this symlink and to change this link afterwards using the shell script?
We're using capistrano to employ a similar setup. However, we've run into a few problems:
After switching to the setup, things appeared to be going fine, but then we started noticing that after running cap deploy, even though the symlink had been changed to point toward the head revision, the browser would still show the old pages, even after multiple refreshes and appending different GET parameters.
At first, we thought it was browser caching, so for development we disabled browser caching via HTTP headers, but this didn't change anything. I then checked to make sure we weren't doing full-page caching server-side, and we weren't. But I then noticed that if I deleted a file in the revision the symlink used to point to, we would get a 404, so Apache was serving up new pages, but it was still following the "old symlink" and serving the pages up from the wrong directory.
This is on shared hosting, so I wasn't able to restart Apache. So I tried deleting the symlink and creating a new one each time. This seemed to work sometimes, but not reliably. It worked probably 25~50% of the time.
Eventually, I found that if I:
removed the existing symlink (deleting it or renaming it);
made a page request, causing Apache to attempt to resolve the symlink but find it missing (resulting in a 404)
then created a new symlink to the new directory
it would cause the docroot to be updated properly most of the time. However, even this isn't perfect, and about 2-5% of the time, when the deploy script ran wget to fetch a page right after renaming the old symlink, it would return the old page rather than a 404.
It seems like Apache is either caching the filesystem, or perhaps the mv command only changed the filesystem in memory while Apache was reading from the filesystem on disk (doesn't really make any sense). In either case, I've taken up someone's recommendation to run sync after the symlink changes, which should get the filesystem on disk in sync with memory, and perhaps the slight delay will also help the wget to return a 404.
I've used symlinks as the apache DocumentRoot in production with no graceful restart necessary. In general, the idea should work. A 403 error probably indicates a permissions error unrelated to the symlink changing. An added wrinkle that you would want to add is making the symlink switch atomic so the symlink always exists. That is to say, at no time is the symlink nonexistent, even for a moment.
The solution to this problem is to effect the change by creating a new symlink and then renaming it over the old symlink. On Unix-like systems, renaming is an atomic operation, and thus the symlink “change” will be atomic too. By hand, the process looks like this:
$ ln -s new current_tmp && mv -Tf current_tmp current