The Joyent Community

Fixing Capistrano was a snap. I'm assuming you already have a working deploy.rb (if you don't, that's another thread.) You just need to redefine the spinner and restart tasks in deploy.rb:

task :spinner, :roles => :app do

  send(run_method, "svcadm start mongrel/yourappname")

end

    
task :restart, :roles => :app do
  send(run_method, "svcadm restart mongrel/yourappname")

end

You also need :use_sudo set to true (it's true by default, but I had it set to false as a relic from when this app was on shared hosting.) And if you were requiring mongrel_cluster/recipes, you don't need that any more.

Last edited by mcornick (2006-11-22 16:43:32)

Hi everyone--

I'm pretty new to the TxD containers and Solaris and am currently setting up some instances of Typo with mongrel (not mongrel_cluster yet). We used this example as an SMF (thanks!) for a single mongrel instance of Typo (we'll call it Typo1) and it's running under the owner of Typo1's virtual host. It worked great.

Then we tried to use the same SMF template to get Typo2 running with a single instance of mongrel under its virtual host's owner and for some reason the SMF fails and mongrel isn't run. The service is put under "maintenance" and here's the message we get under svcs -vx:

svc:/network/mongrel/typo2:default (?)

 State: maintenance since Sun Nov 26 10:57:51 2006

Reason: Method failed.
   See: http://sun.com/msg/SMF-8000-8Q
   See: /var/svc/log/network-mongrel-typo2:default.log

Impact: This service is not running.

And the *.log file seems to be not much help in this case, because here's all I get:

[ Nov 26 10:57:51 Enabled. ]

[ Nov 26 10:57:51 Rereading configuration. ]

Here's the SMF file (with names replaced with Typo2):

<?xml version='1.0'?>


    
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>

    
<service_bundle type='manifest' name='mongrel/typo2.com'>
  <service name='network/mongrel/typo2com' type='service' version='0'>
    <create_default_instance enabled='true'/>
    
    <dependency name='fs' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='net' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/loopback'/>
      <!-- need nfs/client because the mongrel stuff is on /home which is nfs mounted -->
      <service_fmri value='svc:/network/nfs/client'/>
    </dependency>
    <dependent name='mongrel_multi-user' restart_on='none' grouping='optional_all'>
      <service_fmri value='svc:/milestone/multi-user'/>
    </dependent>
    
    <exec_method name='start' type='method' exec='/opt/csw/bin/mongrel_rails start -d -p 8001 -e production -P log/mongrel-2.pid' timeout_seconds='60'>
      <method_context working_directory='/home/typo2/web/blog'>
        <method_credential user='typo2user' group='typo2group' />
        <method_environment>
          <envvar name="PATH" value="/usr/bin:/bin:/opt/csw/bin" />
        </method_environment>
      </method_context>
    </exec_method>

    <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
      <method_context/>
    </exec_method>

  </service>

    
</service_bundle>

The only difference between Typo2 and Typo1 (the working one) is the replaced names and the name of the pid file. The error in svcs for this was "Method failed", but if I'm in the working directory as the typo2user I can run the exact same method and mongrel will run successfully from the command line. Another thing we can do is run the user/group in the SMF as root/root and it'll run fine, but we want to have these apps run respective of their owners. Does anyone have any ideas what the problem might be or anything I could do to look further into this?

-tieg

Thanks for the suggestion Mcornick. It sounded right, but we tried it and unfortunately it didn't work. We've also tried using multi-user-server instead of multi-user as the milestone, but it didn't work either. We tried renaming the dependency every which way to Kansas, but none of the permutations worked.

Eventually I tried taking that whole dependency out of the SMF and it still didn't work, so we thought it might be some other problem. We then tried to replace the credentials in the SMF as the user/group from the Typo1 instance that was working, and it worked... insofar as the service was "online" instead of "maintenance". The mongrel spit out a blank page, but I'm sure that was because that user/group didn't have permissions in that Typo2 directory.

So our thoughts are that it might be because of the way that we setup the Typo2 virtual host with a custom username as the owner (the user and group in the credentials have the same name, btw), so I think our last resort might be to just throw out the virtual host and start that guy from scratch.

Last edited by tzaharia (2006-11-28 07:10:15)

Good stuff... Here's a quick capistrano mod to make it easier to call svcadm:

Capistrano::Actor.class_eval do

  # svcadm :start, "nginx/foo"
  def svcadm(action, svc)
    sudo "svcadm #{action} #{svc}"
  end

end

One change, if you're using the textdrive myprivateip script for your mongrel cluster (I was pointed to it for the BIG-IP setup), you need to add /usr/sbin to <envar name=PATH value="/usr/bin:/bin:/opt/csw/bin:/usr/sbin"/> (ifconfig is used in the script and it's in /usr/sbin).

rainbowsheep wrote:

How would you modify that SMF to do a restart via 'mongrel_rails cluster::restart'?

I haven't tried this yet, but couldn't you just add:

<exec_method name='restart' type='method' exec='/opt/csw/bin/mongrel_rails cluster::restart' timeout_seconds='60'>

  <method_context working_directory='/home/your/app/current'>
        <method_credential user='your_user' group='your_group'/>
        <method_environment>
          <envvar name='PATH' value='/usr/bin:/bin:/opt/csw/bin:/usr/sbin'/>
        </method_environment>
  </method_context>

</exec_method>

Would there be any advantages or disadvantages to changing the 'stop' exec_method to use 'mongrel_rails cluster::stop' rather than ':kill'?

And, just to make sure I understand correctly, the default behavior for 'restart' (if you don't provide a method) is to run the 'stop' then the 'start' methods, right?

Last edited by JustinG (2007-03-19 02:31:34)

here and here

At the wiki I have generalized mcornick's manifest so that you can have multiple mongrel_cluster instances, one for each Rails app that you might be running.

I would appreciate input on the mongrel_rails cluster:stop vs. :kill as well as the cluster:restart method.

Thanks to mcornick for the original manifest!