On Mon, Nov 9, 2009 at 1:51 AM, Scott Haneda <talkli...@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 dreamc...@gmail.com _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users