daemondo / launchd just being silly on me

[Scott Haneda]

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 <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.

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