Sinatra on Passenger always fails on first attempt - sinatra

I have a small Sinatra app I'm running on a shared hosting account using Passenger. However, the first time the app is accessed after a while, I get a Passenger error page saying the application could not be started. Usually because Sinatra could not be found.
I am assuming this is just a normal delay from when a new instance is spawned. However, is there a way to delay trying to load Siantra until it Passenger has fully loaded?

I seem to have solved the issue by setting the GEMS_PATH environment variable in the .htaccess file. I haven't encountered the error again. YET!

I took this up with Dreamhost support recently (not a great experience) and eventually they recommended freezing the gems into the application. This is at best a partial solution, because it seems to work for some gems and not for others.
Instead of
require 'sinatra'
I have:
require 'vendor/gems/sinatra-0.9.4/lib/sinatra'
Freezing gems is covered elsewhere, but briefly: to prepare for this, one needs to do
mkdir vendor/gems
cd vendor/gems
gem unpack sinatra
As a result of this change, I never get the startup failure screen quoting sinatra as the file it can't load. However, I still get it for some other gems which require themselves or parts of other gems. Not too clear about the details, but I'm working on the idea of hacking the installed gems to make every "require" use a path directly out of my "vendor" library.

I think you may need to add Gem.clear_paths! in there

I had a similar problem a long time ago. Updating to a newer Sinatra gem helped me - what version are you running?

Related

sails.getDatastore is not a function

I'm currently in the middle of upgrading our API from v0.12 of Sails to v1. Not the easiest task, but will be worth it.
The current problem I'm having, is converting our old "ModelName.query" calls to the new style, which is supposedly "sails.getDatastore". Great, fine.
Except, that when trying to do this in config/bootstrap.js, I constantly get the error "sails.getDatastore is not a function".
Yes, I am using the default sails-hook-orm, the .sailsrc has it turned on explicitly; and yes, I have globals turned on.
Is the problem that the function isn't registered until after bootstrap? Because that is not an option for us; bootstrap is validating our database schema before lift (custom code, using native queries), so our production servers fail to deploy if we missed a database update. It eliminates a ton of human error.
Thanks for taking the 1.0 plunge!
I'm not sure what you mean by the "default" sails-hook-orm -- that hook is installed directly as a dependency on each Sails 1.0 project -- but I can almost guarantee that the version you're using is not correct. I would do:
npm cache clean
npm install sails-hook-orm#beta
in your project to make sure you get the latest (currently v2.0.0-21). It adds getDatastore to the app object when it initializes.

My Meteor projects skip MongoDB-startup

Three weeks ago my Meteor projects worked fine, but today I noticed that all my Meteor projects skip the 'start-MongoDB' step, or at least it seems that way. All my projects that rely on one or more collections now get stuck on the 'starting your app' step, while new projects start normally (probably because no MongoDB doesn't cause problems for them). Note: I'm having these problems while running applications locally on my laptop.
Most posts that I can find about apps freezing on 'starting your app' mention that the app can't connect MongoDB, which relates to my case, because it is never started, but I don't know how to tell Meteor it should start up MongoDB first before running any of my apps.
Any tips on this matter?
Have you set the environment variable MONGO_URL? If so, meteor (aka meteor run) will not start MongoDB.
Thx for the tips guys, I fixed it, but the root of the problem was kind of far-fetched. The METEOR_LOG=debug option, as suggested by #aedm, helped me figure out what was wrong though.
One of my older applications posted the error message Meteor 1.2.0.2 - Couldn't run tasklist.exe on Windows 10, and when searching on that error message someone suggested that something might be wrong with my environment variables. Apparently when installing some new software a couple of days ago I created a new 'path' variable, rather than editing the old one, which overwrote the original 'path' variable, which included something essential for Meteor. I deleted the new 'path' variable, and added its contents to the old one, and now everything works and Mongo starts as it should when I run my apps.

Redmine plugin install (RedmineCRM Finance) results in 503

So my problem is that for some some reason installation of some plugins kills my bitnami redmine "permanently" (thin_redmine and thin_redmine2 stops after like 5 seconds).
The plugin which most recently did this is Finance Plugin from RedmineCRM. Version should be okay.
http://www.redmine.org/plugins/finance
Method I used (note that I added :migrate in the second line compared to their website (Is this the problem?)):
bundle install --without development test
bundle exec rake redmine:plugins:migrate NAME=redmine_finance RAILS_ENV=production
Am I missing or wrongly doing something? (Please note that I'm not really an expert in this field so I mainly go after how to-s.)
Are there anymore prerequirements for this (besides a very basic working redmine) e.g. I did not set up e-mail notifications, can stuff like this cause the problem?
Unfreez the gemfile. It solved the problem.

Dotcloud uWSGI Error

I am trying to deploy one of my applications on dotcloud. However, I keep getting:
uWSGI Error
wsgi application not found
Somebody could hint at some useful docs where this issue is discussed? My application is here:
https://github.com/kfk/datacrowd
and I do think everything is done by the tutorials.
Not sure if you looked at this page or not, but it is a good resource for deploying flask apps onto dotCloud. http://flask.pocoo.org/snippets/48/
Looking at your application, it looks like most things are setup correctly the only thing that looks a little odd is your wsgi.py file.
Have you tried to change your wsgi.py file so that it looks like this.
import sys
sys.path.append('/home/dotcloud/current')
from datacrowd.app import app as application
application.config.update(DEBUG=True)
basically I removed the if statement at the end. Try that and see if it helps at all.
If not, try commenting out the application.config.update(DEBUG=True) line and see if that helps as well.
oh yeah one more thing, it looks like you have a static file instead of a static directory, not sure if you did that on purpose or not, but usually static is a directory where you put your static media, so that is most likely suppose to be symlink to datacrowd/static
Update:
Since you had the same error, then it is most likely something wrong with your application.
ssh into your service.
$ dotcloud ssh <app.service>
And then look at your logs in /var/log/supervisor/uwsgi.log, you will most likely see a syntax error, and a stack trace, telling you where the error is.
Common issues are usually
dependencies not being installed
Using features from a new version of python. (python 2.7, 3.x, features) when the python version on dotCloud is only 2.6.x.
syntax typos (indent issues, etc)

spine.js hem server, hem build FAQ for Windows

I'm trying to mimic some basic functionality of the Todos example. After reading spinejs.com, many articles, and taking a few attempts and not getting off the ground, I do need to ask and get some help here. I wish this was more clear-cut, and I'd like to help others as well. I'm on Windows7 and I'm using spine.app to create my app, controllers, models - also using jQuery.tmpl
I'm using CS, but pretty new to it.
I'm not really sure where I need to use require (if at all) - I'm using an modules.exports = .... statement on all M, C
so index.coffee should be able to find, I assume
Maybe this is not the case - I see even though controllers/contacts used a modules.exports statement, the index still used a require.
Is index.coffee just particular about visibility ?
I see Contacts uses Contact without any require statement.
I've seen the main.App Controller be instantiated, from CS, as in Todos
or in the jQuery() script in the html, as in Contacts.
I'm assuming you should either
-build the whole thing and include application.js OR
-use the jQuery() function to create your App via javascript.
If this does compile, will it end up in public/application.js ??
I'm getting a nasty parse error,
and yes, I'm aware you consistently have to use spaces (no tabs)
That being out of the way, I'm getting hung up on the 1st require line
require('lib/setup')
Am I going to need some Cygwin stuff ? I can get it if it helps.
and I've seen the Google Groups, guillaume86's comments, contrib and CS irc channel.
I'm not sure what (date) version of hem I have
but I did try the minify: false, option and a few other things, to try to debug this.
The good news: I'm pretty stubborn and will get this to work, if I can get a little help here.
More to come, but I'm going to close at this point.
Thanks in advance for your suggestions.
I don't think this will help the OP too much, but thought I'd write this up to help anyone else who is looking to get started with these awesome tools.
Before you go further: I've rewritten this with updates at How to manage client-side JavaScript dependencies?
Here's a basic list for getting set up with a Spine, hem, coffeescript app. I only develop on Linux, so I'm not sure if some of these steps would have problems on windows, namely npm commands. Should work fine on Mac; I know other who use the same toolchain.
Install NPM: curl http://npmjs.org/install.sh | sh on a *nix system. I'll assume it's available from the command line.
npm install -g spine.app will make spine available as a global command
spine app folder will make a Spine project called app in folder, generating the right directory structure and a bunch of skeleton files to get started.
cd to folder and edit dependencies.json for the libraries you need. Add them to slug.json so that hem knows where to find them as well. You can install hem globally (npm install -g hem) or locally, as in the next step.
npm install . to download all the dependencies you just entered in, including hem.
If you take a look at the default spine config, there is a app/lib/setup.coffee where you require all the libraries you need from your dependencies. Examples:
# Spine.app had these as dependencies by default
require('json2ify')
require('es5-shimify')
require('jqueryify')
require('spine')
require('spine/lib/local')
require('spine/lib/ajax')
require('spine/lib/manager')
require('spine/lib/route')
# d3 was installed via dependencies.json
require 'd3/d3.v2'
In index.coffee, you just require lib/setup and load the main controller for your app. In addition, you need to require any other classes in those other controllers.
The default generated index.html will usually be fine for loading your app, but modify as necessary.
From folder, run node_modules/hem/bin/hem server to start a hem server, and navigate to localhost:9294 to see your app. If you installed hem globally (npm install -g hem), then hem server by itself may work, but sometimes it gets confused about the path.
Build the rest of your app using proper MVC techniques, and use stylus for CSS and eco for views.
One more thing: normally, hem server will update automatically as you update your code and save files, which makes it a cinch to debug. Running hem build will compile your app into two files, application.js, which is minified and application.css. If you run hem server after this, it will use those files and no longer update automatically. So don't hem build until you actually need a minified version of your app for deployment.
See this other thread about that: Spine.js & hem getting started
Windows is supported (there were concerns in the past, but they have been resolved). There is actually a branch of hem that being more actively developed, since the original branch is no longer being maintained by the developer. You can check out branches version0_2 or version0_3 which have been getting updates and may eventually get windows support.
HTH.