I have a CakePHP application setup on Heroku using the Heroku PHP buildpack (https://github.com/heroku/heroku-buildpack-php).
With Debug set to 1, the application uses the file cache and reduces the lifespan of the cache. In addition, the DebugKit toolbar appears.
With Debug set to 0, the application uses APC.
When I have Debug set to 1, it works properly, but the DebugKit toolbar shows up and the caching is essentially shutoff. When I set Debug = 0 I get the standard "Internal Error" message. Running "heroku logs" only shows me errors relating to php not being able to write to the tmp directory (specifically for error logs). I attempted to have cakePHP write to stdout, but that didn't help.
To see what exactly was causing the problem, I removed DebugKit from the installation and made the caching for Debug=1 match Debug=0. I thought this would cause the app to error again, but it's still working. Is there anything else that happens when Debug is turned off that could be causing this, or did I miss something with the error logs error?
I managed to get this working eventually. The answer was to make sure the app/tmp directory and all of the children directories were being created by the buildpack. I was under the impression that cakePHP wouldn't worry about them if it didn't need them, but I was incorrect.
I wanted to keep them out of the repo, so in the buildpack compile file I added:
CAKEPHP_APP_TMP_PATH="www/app/tmp"
# make tmp dir
echo "-----> Creating CakePHP tmp directories"
mkdir -p $CAKEPHP_APP_TMP_PATH/cache/models
mkdir -p $CAKEPHP_APP_TMP_PATH/cache/persistent
mkdir -p $CAKEPHP_APP_TMP_PATH/cache/views
mkdir -p $CAKEPHP_APP_TMP_PATH/logs
mkdir -p $CAKEPHP_APP_TMP_PATH/sessions
mkdir -p $CAKEPHP_APP_TMP_PATH/tests
chmod -R 777 $CAKEPHP_APP_TMP_PATH
With that, the directories were in place, but they never appear to be used. The app is now properly running with Debug set to 0.
It would be ideal if you could get write access to the tmp folder so that you can see the logs.
These Internal Error with Cake are usually related to the caching of the models. So in APC you may have and old cache that does not really match up with your database.
Try clearing the APC cache and see if that helps.
PS: The cake app has a couple of caches, so you'll have to make sure what uses what... you have the default, _cake_core_ and _cake_model_ at least! The last two could be the source of your problems.
Related
I went to view a postgres schema on my local (MacOS 11) database, and was not able to view my schemas.
Connection Refused in DBeaver!
So I opened my postgres desktop application, and got the warning message, "Stale postmaster.pid file"
How can I fix this?
The problem is that the postmaster.pid file needs to be removed manually and regenerated by postgres, and these are the steps to do it. (Keep in mind the version might change, var-12, might be var-13 etc)
Open your terminal, and cd into the postgres directory: cd /Users/$USER/Library/Application\ Support/Postgres
Make sure you're in the right place, ls you should see something like var-12 or var-<version #>
Verify the file is there, ls var-12 (keep in mind the var-XX is equivalent to your PGSQL version)
Verify the Postgres server is not running by viewing desktop app
Version might change so could be var-12, var-13, etc etc depending on age of this article.
Library/Application Support/Postgres
➜ ls var-12
PG_VERSION pg_hba.conf pg_replslot pg_subtrans postgresql.auto.conf
base pg_ident.conf pg_serial pg_tblspc postgresql.conf
global pg_logical pg_snapshots pg_twophase postgresql.log
pg_commit_ts pg_multixact pg_stat pg_wal postmaster.opts
pg_dynshmem pg_notify pg_stat_tmp pg_xact postmaster.pid <----
Then remove postmaster.pid, rm var-12/postmaster.pid
or rm var-<PG version #>/postmaster.pid
Go back to your console, start your postgres server, and it should be functioning again, and you should have full access to your schemas.
cd /Users/<UserName>/Library/Application\ Support/Postgres/
ls
Then we may view any of the directory names, such as var-9, var-10, var-11, etc... depending on which PostgreSQL version we have installed.
Following that, if we can see var-11,
cd var-11
rm postmaster.pid
In my case I used the code rm var-13/postmaster.pid and solved.
I'm using Jenksin v2.5.0 with Credentials plugin v 2.1.16 and CredentialsBinding plugin v1.13 (both latest available) and while it appears to work as intended, it exhibits and odd repeating behavior as I continue to re-run my pipeline.
The following pipeline syntax is in use:
withCredentials([file(credentialsId: '<credID>', variable: 'KEY_FILE')]) {
...steps here create ${workspace}/ssh script using KEY_FILE...
sh(script: "docker exec ${containerName} /bin/bash -c 'cd ${entryPoint} && GIT_SSH='${workspace}/ssh' git fetch --tags --progress git#gitserver.com:${group}/${project}.git +refs/h eads/${branch}:refs/remotes/origin/${branch}'")
} //credentials
It evaluates as expected and is functional, as shown here:
[Build] Running shell script
+ docker exec <container> /bin/bash -c 'cd /<buildRoot>/build && GIT_SSH=/<workspace>/ssh git fetch --tags --progress git#gitsserver.com:<group>/<project>.git +refs/heads/staging:refs/remotes/origin/staging'
Warning: Identity file /<workspace>/<job>#tmp/secretFiles/a36b7edb-2914-419a-8be0-478603d1b031/keyfile.txt not accessible: No such file or directory.
Permission denied, please try again.
Permission denied, please try again.
Received disconnect from gitserver.com port 22:2: Too many authentication failures for git
Connection to gitsserver.com closed by remote host.
Warning: Identity file /<workspace>/<job>#tmp/secretFiles/ccb1e11c-18f5-4697-b5c1-e4514c1ab1c7/keyfile.txt not accessible: No such file or directory.
*** The part where it states that it can't find the file during the git operation (that is using SSH underneath) is what continues to repeat, each time with a different secret files GUID in the path (shown above are two of the repeats). The underlying implementation appears to implement a loop of sorts over the 'git fetch' command, trying a new credentials path each time.
Both how/why Jenkins:
1) Creates these new paths each time
2) Knows to keep looping over the single failed git command until it finally delivers the secret file that enables the authentication and git succeeds
are mysteries to me.
Any insight would be appreciated.
PS> I'm already aware that newer versions of git not (yet) available in my environment have different methods for providing SSH options. I'd like this question to focus on the odd withCredentials behavior.
PPS> I've also already tried higher level constructs for the pipeline including at least the 'git' SCM plugin specialization and the 'docker' node type with it's "inside()" functionality, but many iterations of those constructs always left me with some oddity that, again, is not the focus of this question.
Turns out that this is not a problem with Jenkins or any of the plugins at all.
The temporary script that was written to the Jenkins workspace was continuously being appended to, meaning it was the source of all the invalid secret file paths and the "loop"...the last command in that script would always be the one with the correct path and it would succeed.
I have what is almost certainly a newbie question. I expected to find the issue while writing this question, but I am still stuck.
I want to change the DocumentRoot for apache, but I keep getting the error message "DocumentRoot must be a directory".
Situation:
The code is running in a virtual VMWare machine 4.0.4 build-744019
The version of linux is Scientific Linux release 6.4 (Carbon)
The version of apache is Apache/2.2.15 (Unix) (this is a yum install with nothing
special)
In the httpd.conf
DocumentRoot "/home/stave/www"
When I restart, I get the message
Starting httpd: Syntax error on line 292 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory
Steps taken so far:
I ensured that the directory exists:
ls -asl /home/stave
4 drwxrwxrwx. 2 stave stave 4096 Feb 9 09:08 www
It even has a file in it "index.html", so I am very sure that the directory exists
I considered that it might be a priviledges issue so (this is a virtual development machine isolated from the internet, and I am troubleshooting so I am not too worried about security) as you can see I set the priviledges to 777.
I even changed the user that apache is running as (and confirmed that the change worked with ps) to stave to ensure that priviledges just shouldn't be an issue.
Stackoverflow
There are a few stack overflow answers, but most of them say "read the error message. It is saying that the directory doesn't actually exist". Others implied that there might a trailing slash at the end which would be bad.
Other websites
The most useful I found was this that advised
You probably got "DocumentRoot must be a directory" error even it is really a directory because of SELinux extensions. Run system-config-securitylevel (or redhat-config-securitylevel) to disable SELinux for httpd or give SELinux permissions to that
directory:
chcon -R -h -t httpd_sys_content_t /path/to/directory*
My version of linux isn't Security Enhanced Linux, so without understanding I tried it anyway: no effect.
Current situation
I have run out of ideas to try, so any diagnostic questions or advice would be greatly appreciated
The link you posted under "Other websites" highlights the root cause of your problem, which is Selinux.
Unless the server is part of a super secure environment, I would simply disable Selinux.
On RedHat / CentOS / Scientific Linux this can easily be done by editing /etc/sysconfig/selinux - find the parameter "selinux" and change the option "enforcing" to "disabled" as per the extract below:
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
It is probably wise to reboot the server after making this change.
You shouldn't just disable SELinux.
You need to set httpd_enable_homedirs to on.
yum -y install policycoreutils-python
setsebool -P httpd_enable_homedirs on
I ran into this problem today as well and it was because I moved my DocumentRoot from /var/www/html to /srv/www/html. As part of our security policies, we do not have the option to just Disable SELinux.
SO my fix, as I discovered was to change the SELinux file context for /srv to match /var. A compromise yes, but still better than disabling it altogether. Other than that... I made sure /srv/www and all subfolders had the httpd_sys_content_t to match the folders under /var/www and all is well now.
This is basically the same answer as David's, but just a little clearer, http serving directory has wrong SELinux security context set.
The full explanation to fix this is here, http://mybroadband.co.za/vb/showthread.php/588183-Fix-403-Forbidden-on-newly-configured-CentOS-6-5-httpd-server-(or-13-10-Ubuntu-LAMP)
My issue was that I was housing my websites inside a different directory than the documentroot path of /var/www/, so I had to follow the 3rd option in the link above to correct. I set the same file context of my /websites/ directory to match that of the /var/www/. What was odd is earlier versions of CentOS 5.5 must not have had the SELinux installed/enabled, because my other servers had no issue with this and when running the ls -Z at the command prompt displayed those folders as 'unlabeled'.
I'm running CentOS 6.5 on AWS from the official marketplace minimal install. So when I ran the ls -Z command on my folders I saw exactly what the link above shows as a possible issue.
Running the chcon command fixed my issue!
Just replace html/ with the directory you want to use!
chcon -Rv --type=httpd_sys_content_t html/
chcon -Rv --user=system_u html/
On a side note I also had to disable iptables to get the routing working, the defaults were serving up blank pages.
service iptables stop
Hope that helps anyone with the same issue.
Envirnoment:
Linux - root file system on a SSD
DocumentRoot on a HDD and mounted via fstab
Restarting apache2 after boot - no problem
Seems to be a timing problem that apache is started before the fstab mounts are completed.
Workaround:
Define the DocumentRoot directory on the root file system with the correct owner, group and permissions. The directory may be empty.
Firstly, there is no reason at all to turn off selinux to fix this issue, just change the selinux file context.
Secondly, when changing selinux file context, you should to set up a permanent rule for that path, such that when new files are copied in and/or replace existing files, restorecon actually fixes the problem, instead of breaking it, as is the case when you only use chcon.
Thus, for a symlink'ed DocumentRoot (let's give the actual full path to the directory as '/media/myDoc' for this example), run these two commands:
semanage fcontext -a -t httpd_sys_content_t "/media/myDoc(/.*)?"
restorecon -R /media/myDoc
Note, the full path is required when using semanage this way. You will not only fix the problem, but it won't break again when you run restorecon (or auto-relabel) in the future.
I'm using CakePHP 2.0 RC-1. After checking out the project from SVN, the application is starting to complain that it can't write cache files to the tmp/cache directory. Since this is local, I know the directory is writeable and I can CLEARLY see that the directories are even filled with files, so the error is a bit strange.
Here are some of the errors I've encountered:
_cake_core_ cache was unable to write 'cake_dev_nb' to File cache
fopen(c:\cake\app\tmp\cache\models\cake_model_default_media) [function.fopen]: failed to open stream: No error [CORE\Cake\Cache\Engine\FileEngine.php, line 127]
No error?! Wth?
Now, if I look in the FileEngine file, at line 127 it reads:
if (!$handle = fopen($this->_File->getPathName(), 'c')) {
return false;
}
By replacing the "c" with "w", no error is encountered and everything works as it should. But, it should not be necessary to modify the core Cake libraries to work around this problem. Let me repeat that on my other computer this works as intended, without editing the core library. Both use the Windows OS and the read/write rights to the tmp/cache-folder is exactly the same.
Edit: Here's a site that experiences the error outputs I'm having locally
Example site found by Googling. Not my site: http://www.12h30.net/credit/
Any suggestions?
Update: Here is why: This is caused if you have a PHP-version that's too low, before 5.2.6, as outlined by "api55" in the comments. Thanks for the reply. Hope this helps you too.
Well, in my case, when I checked my app, it hadn't the /tmp folder. Then I created the structure (/tmp/cache/models, /tmp/cache/persistent) and all worked well. This happened to me maybe git ignore empty folders, so they weren't created.
I had a similar problem, it was because I had chown -R www to the app/tmp directory to get Cake to run "properly" without giving everyone write privileges. Looks like during development the only way to use the console and the web is to give everyone write privileges, or add yourself to the www group perhaps.
Easy solution:
chmod -R 777 app/tmp
or
chown -R username app/tmp
while using the console and
chown -R www app/tmp
when using the web
Just give the right CHMOD (776 works fine for me) to app/tmp
for windows users with the same error/warning: make sure you run the command prompt in elevated mode ;)
I'm trying to get Tomcat 6 running on Fedora 14. I'm quite new to this sort of thing, though I have managed to get Apache running before.
I suspect I've made mistakes on some quite basic levels, because the test page (http://localhost:8080) can't be found.
If I try to check the service's status, as root or as an ordinary user, this is what I get:
tomcat6 (pid) is running...[OK]
tomcat6 lockfile exists but process is not running [FAILED]
So I'm confused, because I seem to be being told that Tomcat 6 both is and isn't running. If anyone can tell me what this really is telling me, and where my suspicions should turn next, I'd be very grateful.
There's no mention of any of this sort of thing in the docs.
I had the same problem. I found beetstra's answer to be necessary but insufficient. I also needed to change some permissions. As indicated (mostly) by this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=708694
# get rid of pid
rm /var/run/tomcat6.pid
# give tomcat sufficient permissions
chown tomcat:tomcat -R /usr/share/tomcat6/conf/
chown tomcat:tomcat -R /usr/share/tomcat6/conf
chown tomcat:tomcat -R /usr/share/tomcat6/logs
After that I could start tomcat successfully:
service tomcat6 start
Starting tomcat6: [ OK ]
I had the same problem, and it was caused by a stale lock file. The process was not really running, there was just a file that said it might be running. The solution was to remove that file:
rm /var/run/tomcat6.pid