daemondo / launchd just being silly on me

Scott Haneda talklists at newgeo.com
Mon Nov 9 20:33:24 PST 2009

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  

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


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  
Scott * If you contact me off list replace talklists@ with scott@ *

More information about the macports-users mailing list