Hello,
I am running Radiant on a HostingRails shared server.
-
I installed a couple of extensions (Shards + Wymeditor) and migrated the
database. I refreshed the admin extensions page and it did not reflect
the new extensions. It took about 20 minutes before the extensions
appeared. Then they disappeared and reappeared several times until
finally staying. Has anybody heard of anything like this?
Is there a vital step I am missing that must be performed after
installing any extensions (like a server reboot?).
-
In addition, after installing these two extensions I receive a
“Application error (Apache)” error only on the “/admin/pages” page.
This error has been discussed in the forums but I didn’t find a clear
solution. I am almost positive this error is related to the extensions,
but it’s hard to troubleshoot with the inconsistent delay to any
extension changes (mentioned above).
Thanks so much!
Ben
I am running Radiant on a HostingRails shared server.
Is there a vital step I am missing that must be performed after
installing any extensions (like a server reboot?).
Yes, a restart is required for extensions to work. They would have
worked intermittently because you have multiple
fastcgi/mongrel/etc processes running - it sometimes worked as soon as
one was restarted (which normally happens periodically on a
shared host) and started working properly after all the processes got
restarted.
If you’ve restarted and still get the application error messages, look
in your production.log file and see what it’s reporting.
Dan.
Yes, a restart is required for extensions to work. They would have
Thanks for the reply Dan. How would I restart a shared server … is
that something I can do from the command line? Or do I just have to wait
it out until it automatically restarts?
Ben
On Thu, Feb 28, 2008 at 7:14 AM, Ben K. [email protected] wrote:
Yes, a restart is required for extensions to work. They would have
Thanks for the reply Dan. How would I restart a shared server … is
that something I can do from the command line? Or do I just have to wait
it out until it automatically restarts?
It is probably started as a fcgi process, since its on a shared host?
Then, just change the timestamp on public/dispatch.fcgi:
$ touch path/to/dispatch.fcgi
The fcgi process will restart as soon as it noticess the change,
practically imediatelly. You could also send a message to the process
to kill itself explicitely with a (s)kill command:
$ skill -9
(same for the kill command). PID stands for process id. Use the “ps”
command to find out the PID of the fcgi process:
$ ps ux
Or you could kill them all:
$ skill -9 dispatch.fcgi
(won’t work for “kill” command)
Or you could just wait for it to reastart automatically. 
Sorry,
this is written for total beginners, I’m not sure how good is your
“command line fu”.