api:ready is not getting fired, and this is the error I am getting back when my app is making a request to dsp.
{“error”:[{“context”:null,“message”:“Failed to get or create swagger cache.”,“code”:500}]}
And this is the few logs which show in my DSP logs:-
5:25][app][DEBUG ] * Discovered 73 event(s).
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: sql.json
[2015-04-30 10:35:25][app][DEBUG ] * Discovered 73 event(s).
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: sqldev.json
[2015-04-30 10:35:25][app][DEBUG ] * Discovered 73 event(s).
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: sqlpatchme.json
[2015-04-30 10:35:25][app][DEBUG ] * Discovered 73 event(s).
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: sqlprod.json
[2015-04-30 10:35:25][app][DEBUG ] * Discovered 73 event(s).
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: sqlzydness.json
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: _.json
[2015-04-30 10:35:25][app][ERROR ] * System error creating swagger cache file: _events.json
API docs also dont open.
A little bit of background before this issue occurred.
- It all started when I restarted my LAMP stack. The DSP never went up again, and the logs gave me the error that .cache is not writable in apache logs:-
‘The directory “/opt/bitnami/apps/dreamfactory/htdocs/vendor/kisma/kisma/.cache” is not writable.’
So, I went and changed the permission to 777, and atleast the DSP app started, and I could see something on the browser.
-
Then the next issue was that the web.ip…log was not writable and that error showed in the browser.
So, I once again changed that to 777 permission and then the DSP site came up atleast.
-
And now even through my DSP is up my API DOCS doesn’t show up.
500 : undefined http://dsp.**./rest/api_docs
I have no clue what could go wrong in a perfectly working DSP after restart.
I am on EC2, on 1.7.8.
Any help would be appreciated.
Did you use the Bitnami ctlscript.sh to restart your stack, or did you do so manually?
It sounds like your Apache user/group (or the user/group your Apache process is run by) may have changed. Can you also run ls -al on the problem directories so we can confirm users and permissions?
I had run the Bitnami ctlscript.sh to restart. nothing manual.
~/apps/dreamfactory/htdocs/log$ ls -al
total 37084
drwxrwxr-x 2 root daemon 4096 Mar 3 15:44 .
drwxrwxr-x 15 root daemon 4096 Dec 12 18:40 …
-rw-r–r-- 1 root daemon 88 Mar 3 15:44 state.bin
-rw-r–r-- 1 root daemon 7221 Dec 22 16:33 web.54.log
-rwxrwxrwx 1 root daemon 37913543 May 2 20:49 web.ip-172-369.log
/stack/apps/dreamfactory/htdocs/vendor/kisma/kisma$ ls -al
total 132
drwxrwxr-x 6 root daemon 4096 Dec 12 18:40 .
drwxrwxr-x 3 root daemon 4096 Dec 12 18:38 …
drwxrwxr-x 2 root daemon 4096 Dec 12 18:38 assets
drwxrwxrwx 4 root daemon 4096 Dec 12 18:40 .cache
-rwxrwxr-x 1 root daemon 754 Nov 13 16:19 composer.json
-rwxrwxr-x 1 root daemon 37170 Nov 13 16:19 composer.lock
-rwxrwxr-x 1 root daemon 123 Nov 13 16:19 .gitattributes
-rwxrwxr-x 1 root daemon 58 Nov 13 16:19 .gitignore
-rwxrwxr-x 1 root daemon 796 Nov 13 16:19 .kisma.php
-rwxrwxr-x 1 root daemon 35146 Nov 13 16:19 LICENSE.txt
-rwxrwxr-x 1 root daemon 494 Nov 13 16:19 phpdoc.dist.xml
-rwxrwxr-x 1 root daemon 725 Nov 13 16:19 phpunit.xml
-rwxrwxr-x 1 root daemon 4841 Nov 13 16:19 README.md
drwxrwxr-x 3 root daemon 4096 Dec 12 18:38 src
drwxrwxr-x 3 root daemon 4096 Dec 12 18:38 testsh
I tested this in my Bitnami DSP deployed into an EC2 instance and could not reproduce the issue. I ran the Bitnami ctslscript.sh just as you did, but the DSP remains up and running and responding to API calls with a functional API Docs in the admin console.
The permissions in my instance are different from yours. All of your directories and files appear to be owned by root instead of bitnami. Here are my results from the same ls -al commands:
~/apps/dreamfactory/htdocs/log$ ls -al
total 192
drwxrwxr-x 2 bitnami daemon 4096 May 15 14:09 .
drwxrwxr-x 15 bitnami daemon 4096 Apr 30 14:22 ..
-rw-r--r-- 1 daemon daemon 85879 May 27 18:23 web.52.log
-rw-r--r-- 1 daemon daemon 81937 May 27 17:52 web.ip-10-10-2-107.log
-rw-r--r-- 1 daemon daemon 878 May 14 07:43 web.testp2.log
-rw-r--r-- 1 daemon daemon 1756 May 14 16:58 web.testp5.log
~/apps/dreamfactory/htdocs/vendor/kisma/kisma$ ls -al
total 132
drwxrwxr-x 6 bitnami daemon 4096 Apr 30 14:22 .
drwxrwxr-x 3 bitnami daemon 4096 Apr 30 14:19 ..
drwxrwxr-x 2 bitnami daemon 4096 Apr 30 14:19 assets
drwxr-xr-x 4 daemon daemon 4096 Apr 30 14:22 .cache
-rwxrwxr-x 1 bitnami daemon 754 Jan 23 20:59 composer.json
-rwxrwxr-x 1 bitnami daemon 37170 Jan 23 20:59 composer.lock
-rwxrwxr-x 1 bitnami daemon 123 Jan 23 20:59 .gitattributes
-rwxrwxr-x 1 bitnami daemon 58 Jan 23 20:59 .gitignore
-rwxrwxr-x 1 bitnami daemon 796 Jan 23 20:59 .kisma.php
-rwxrwxr-x 1 bitnami daemon 35146 Jan 23 20:59 LICENSE.txt
-rwxrwxr-x 1 bitnami daemon 494 Jan 23 20:59 phpdoc.dist.xml
-rwxrwxr-x 1 bitnami daemon 725 Jan 23 20:59 phpunit.xml
-rwxrwxr-x 1 bitnami daemon 4841 Jan 23 20:59 README.md
drwxrwxr-x 3 bitnami daemon 4096 Apr 30 14:19 src
drwxrwxr-x 3 bitnami daemon 4096 Apr 30 14:19 tests
I hope this helps while you’re working on correcting permissions.
I also recommend considering an upgrade. DSP 1.7.8 is behind by six major DSP releases, and the upgrade process is very simple.
Hi @jeffreystables
I know 1.7.8 is behind, but I had some bad experiences while upgrading.
Also some things like relations with multiple field primary keys don’t work with 1.9.1 but work fine in 1.7.8.
So, I am wondering if there are some things not working in 1.9.x or is it that it has been purposely removed.
I will correct the permissions, and also try installing the latest DSP.