You are a bit more advanced in your knowledge of C and other related
code, sorry I was not more help, comments interspersed below...
On Nov 9, 2009, at 4:09 AM, dreamcat four wrote:
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.
Well, then that pretty much points the finger to daemondo as far as I
can tell then.
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.
Yes, I see where you are coming from. I have never used those
commands. I only recently learned they were tied in like that, and
run just a few "servers" that needs restarting. When restarting
something like Apache just feels better to use ./apachectl graceful, I
tend to go with what the rest of the world is doing.
I already have enough explaining to do on other lists as to what
launchd even is :)
But I also have my own more general purpose way to restart services as
well. Probably did reinvent a wheel on that one, though my wheel is
pretty wobbly.
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
I am way out of my league here, but why symblink? Isn't the idea of
MacPorts to get everything into ${prefix}? If there is some path in
your software that is calling out to /var, then I think you need to
reinplace the source, or use a patchfile, to change the path. Or
perhaps talk to the developer to make it a build time argument that
changes the paths for you.
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?
I personally avoid it. I have just ran into issues with it, where it
was harder for me to understand. I am sure this is just my fault.
Looking at the files it makes, I find them difficult to understand
what is going on. Whereas a plist for launchd, could not be easier to
understand what is going on.
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 think it is worth a try, if that gets this working how it should,
and there are no repercussions to other daemondo users, then seems a
bug worth fixing.
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 worky
with a manual plist ? How to put a manual plist in a portfile rather
than using a startupitem declaration?
I do not think that it would work so easily. *I think* `port load`
must call the Portfile in one of its phases, so you may have to alter
that phase to do what you want with your launchd item. I have never
tried this personally.
What I can gather, is at the end of the day, the Portfile is just a
tcl script, so you can do anything you want. MacPorts has built a
nice language helper on top of it, for making things easier, but it is
not to say you can not have your way with that Portfile in any way you
desire.
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.
That just depends on how the app gets started. A launchd item that
calls
/Users/me/bin/myapp is pretty sure to work.
However, a one liner along the lines of
while true; do bunch of stuff here, with >> and > redirection; done;
never worked for me. I have to put that in a interim script, and then
make a simple call in the launchd item.
http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00009.html
And there were a few other threads I was in as well, I think it is
being worked on, but for now, yes, I make a mess and have little
script turds laying around :)
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
Correct, as far as I know. I have seen "files" have a lot of things
in it, certainly more than 4 files for sure.
? 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.
Here is how I have reinvented the wheel, in a cobbled little way:
script called `kickstarter`
It sits in its own dir, and there are *.conf files within it.
There is an include includes all .conf files
If I add a new app that needs some type of my interaction with it, I
make a .conf file. Maybe I have an email server, and It has certain
options to start, stop, restart, test, etc. With ${prefix} changing
the path, and the high chance that there is a copy of the email server
supplied by apple, I want to make sure I am working against the right
binary, and not Apples.
I make postfix.conf
I am sure you are getting the idea:
if main_arg is 'postfix'
if arg is 'restart'
commands I need to restart
msg ='something'
else if arg is stop'
commnds I need to stop the server
msg ='something else'
end if
end if
echo $msg
...
I run a lot of kickstarter postfix reload
That is some basic psuedo code, just how I have gotten by with the
things I need to do. Probably not related to your issue at hand, but
related enough i thought to mention it.
Thanks again for such replies Scott. Its a valuable insight into how
to go about doing this.
You may want to pop onto macports-dev instead, I have a feeling your
questions based on your expertise will be better answered there. You
are after all making a port, which is in part, what that list is for.
I have been making as many ports as I can to contribute, but I am sill
learning.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
