daemondo / launchd just being silly on me

[dreamcat four]

On Mon, Nov 9, 2009 at 1:51 AM, Scott Haneda <talklists at newgeo.com> wrote:
> I do not know anything about stompserver.  How I would debug this...
>
> Can you start the server by hand, on the command line?  If so, sounds like
> you are doing pretty good.  Are you sure that --working_dir=/var" is
> correct?  My understanding is that path is a portfile violation,

* Yes, can start it on the command line no probs.
* Yes, am aware that the path should be /opt/var,

/opt/var/ would be fine for this "stompserver" ruby gem. That
particular one is easy to configure. However the stompserver is just a
pilot and the simplest case for me to get going with. The chef gem,
and chef-server gems are not so easy. Posix /var paths are hardcoded
everywhere in 3 init scripts. Which are distributed as part of a ruby
gem.

Init scripts:
http://github.com/opscode/chef/tree/master/chef/distro/redhat/etc/init.d/

The idea is not to re-invent the wheel, so we would use:
startupitem.{start, stop, restart} to get launchd to call all these
init scripts.

There would be 4 plist files in total.

> Then again, any launchd item installed by MP is going outside of ${prefix},
> so there have been provisions to allow it.  Though it is just a symblink.
>
> Maybe you need --working_dir=${prefix}/var" to keep everything in prefix?

So you would have to symlink the files from /opt/var to /var? I was
unsure how reasonable that is compared to just using /var. But it
probably would look like this:

/opt/var/run/chef/
/opt/var/log/chef/
/opt/var/log/stompserver.log
/opt/var/log/stompserver.pid
/var/log/chef/ -> /opt/var/log/chef
/var/run/chef/ -> /opt/var/run/chef

And with 3 lockfiles left remaining in /var
It would be inadvisable to move them.

/var/lock/subsys/chef-client
/var/lock/subsys/chef-indexer
/var/lock/subsys/chef-server

> If you can run via command line, great, you can then point the finger at
> debugging around the launchd item.  At that point, I wold make a basic
> launchd item by hand.  Look at something like "com.apple.ReportCrash.plist"
> for a basic shell template to use.

Okay, do you mean still calling daemondo or avoiding daemondo?

Its my impression that this error is an execvp() fail in daemondo/main.c.
Shouldn't i just recompile daemondo to printf() the execvup() arguments?

I have seen manually written plist examles to call other ruby programs
(as a daemon/server). But it seems like an backward step when
startupitem... in a portfile should do it for you. Also can the alias
command "port load stomperver" "port unload stompserver" still work
with a manual plist ? How to put a manual plist in a portfile rather
than using a startupitem declaration?

> For example, I have a backup script, called at 12:15 AM daily, it calls a
> shell script, which yours could do, or if it is simple, it can just call the
> one command you need to run.

Are you suggesting to wrap the ruby script in a bash script?
Have not tried that yet.

> .......
> .......
> .......
>
> Launchd is picky about paths, spaced, arguments with leading double dashes,
> and a number of things.  Aside from the most basic one liner scripts. I
> shove my core code logic in a executable file, and then let launchd cal
> that.

Hmm, if this were true, then it would be some plist creation error in
startupitem.

> Since I do not know about stompserver, all I can add is, get it running, and
> see if you can get it running with a standard launchd item.  Watch your
> system.log wen you load and unload. ( tail -f /var/log/system.log )
>
> Watch the system log when you start via daemondo, it can be telling in a
> number of ways.  If you get it working via your own launchd, you can decide
> to just bundle the plist in "files", xinstall it into place, or just ui
> message the user on what to do.

I guess this answers 2 earlier question, as i have been reading this.
Thank you, that makes a lot of sense now.

Another thing seems to be that in my case I am simply writing a Port
to distribute launchd scripts. (the actual software can all be
installed with rubygems package management system). So for the case of
having as many as 4+ plist files, they could be all packaged into 1
Port if they were manually added to /files subdir ? This is quite a
benefit because "startupitem.executable" seems to limit to 1 plist
file per Portfile.

I wonder if the "port load tagname", "port unload tagname" alias will
work for such a manual plist. It is a new convenience that was
recently added to macports.

> I do something like this: ( as a ui message )
>     To install the launchd item, issue the following commands:
>          cd ${prefix}/share/doc/${name}/
>          sudo cp org.pure-ftpd.ftpd.plist.server.sample
> /Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
>            - or -
>          sudo cp org.pure-ftpd.ftpd.plist.basic.sample
> /Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
>            - and then load the launchd item -
>          sudo launchctl load -w
> /Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
>
>          You can now test the server with:
>               ftp localhost
>          You should see a Welcome to ${pretty_name} message.
>
> Which is my opinion, pretty nice, as it echos out a clean message to the
> user to explain just how to get stared.  Often times I `sudo port install
> something`, and am then left with having to `sudo port edit something` just
> to see what the file were set to be made to do.
>
> Sorry I was not more specific help, but this is exactly how I have had to
> troubleshoot ports I am working on.  You may have better luck on the
> MacPorts dev list as well.
> --
> Scott * If you contact me off list replace talklists@ with scott@ *

Thanks again for such replies Scott. Its a valuable insight into how
to go about doing this.


Best regards

dreamcat4
dreamcat4 at gmail.com