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
prefix?
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">
<dict>
<key>Label</key>
<string>com.me.backup.mysql5</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>/Users/me/bin/mysql_backup</string>
</array>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>0</integer>
<key>Minute</key>
<integer>15</integer>
</dict>
</dict>
</plist>
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:
<key>Disabled</key>
<true/>
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/
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@ *
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.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
