daemondo / launchd just being silly on me

Scott Haneda talklists at newgeo.com
Sun Nov 8 17:51:24 PST 2009

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,

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  

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.

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.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd 
<plist version="1.0">

To start that I run
	`sudo launcctl load -w /Library/LaunchDaemons/com.me.backup.mysql5

the -w will remove any disabled flags that may have been there. This  
would run, past a reboot, until I run

`sudo launcctl unload -w /Library/LaunchDaemons/com.me.backup.mysql5`  
which will add in:


com.me.backup.mysql5 will then never run, even past a reboot with  
unload -w.

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.

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 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/ 
             - or -
           sudo cp org.pure-ftpd.ftpd.plist.basic.sample /Library/ 
             - and then load the launchd item -
           sudo launchctl load -w /Library/LaunchDaemons/org.pure- 

           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@ *

On Nov 8, 2009, at 11:39 AM, dreamcat four wrote:

> Hi,
> I've got the following:
> $ gem install stompserver
> Portfile:
> startupitem.create		yes
> startupitem.name		rb-stompserver
> startupitem.logevents	yes
> startupitem.logfile		/var/log/stompserver.log
> startupitem.pidfile		auto /var/log/stompserver.pid
> # startupitem.executable  "ruby
> ${prefix}/lib/ruby/gems/1.8/bin/stompserver --working_dir=/var"
> # startupitem.executable  "/opt/local/bin/ruby
> ${prefix}/lib/ruby/gems/1.8/bin/stompserver --working_dir=/var"
> # startupitem.executable  "/opt/local/bin/ruby
> ${prefix}/lib/ruby/gems/1.8/bin/stompserver --working_dir /var"
> startupitem.executable  "${prefix}/lib/ruby/gems/1.8/bin/stompserver
> --working_dir /var"
> which creates the attached plist file. But for the life of me it just
> won't start.
> $ sudo port uninstall rb-stompserver && sudo port clean --dist
> rb-stompserver && sudo port install stompserver
> $ sudo port load rb-stompserver
> $ cat /var/log/stompserver.log:
> 2009-11-08 19:22:39 rb-stompserver: Unable to launch process
> /opt/local/lib/ruby/gems/1.8/bin/stompserver --working_dir /var.
> 2009-11-08 19:23:09 rb-stompserver: error while starting
> 2009-11-08 19:23:09 rb-stompserver: Starting process
> 2009-11-08 19:23:09 rb-stompserver: Unable to launch process
> /opt/local/lib/ruby/gems/1.8/bin/stompserver --working_dir /var.
> 2009-11-08 19:23:39 rb-stompserver: error while starting
> 2009-11-08 19:23:39 rb-stompserver: Starting process
> 2009-11-08 19:23:39 rb-stompserver: Unable to launch process
> /opt/local/lib/ruby/gems/1.8/bin/stompserver --working_dir /var.
> 2009-11-08 19:24:09 rb-stompserver: error while starting
> 2009-11-08 19:24:09 rb-stompserver: Starting process
> 2009-11-08 19:24:09 rb-stompserver: Unable to launch process
> /opt/local/lib/ruby/gems/1.8/bin/stompserver --working_dir /var.
> You get the picture.
> Such error message corresponds to forking execvp() call in the  
> Daemondo C code:
> http://svn.macosforge.org/repository/macports/branches/images-and-archives/base/src/programs/daemondo/main.c
> main.c, line 514:
> pid_t
> Exec(const char* const argv[], int sync)
> {
>    if (!argv || !argv[0] || !*argv[0])
>        return -1;
>    pid_t pid = fork();
>    switch (pid)
>    {
>    case 0:
>        // In the child process
>        {
>            // Child process has no stdin, but shares stdout and  
> stderr with us
>            // Is that the right behavior?
>            int nullfd = 0;
>            if ((nullfd = open("/dev/null", O_RDONLY)) == -1)
>                _exit(1);
>            dup2(nullfd, STDIN_FILENO);
>            // Launch the child
>            execvp(argv[0], (char* const*)argv); // <------------- xml
> params are put here from the plist
>            // We get here only if the exec fails.
>            LogMessage("Unable to launch process %s.\n", argv[0]); //
> <-----------  execvp() fails ???
>            _exit(1);
>        }
>        break;
> But it just doesn't make any sense to me. I can see no reason why the
> ruby script should fall through and error out here. Have tried
> prefixing with / without ruby binary eg 'ruby <script>'. Tried
> swapping out the '=' param for a space. Made sure there were no quote
> marks nor any other special shell manipulation. The same command of
> course will run in a terminal. Nothing seems to change : (
> Please help.

More information about the macports-users mailing list