Running Indigo as a system daemon

I have been running Indigo (2.5beta, and now 3) as a system daemon under Mac OS X Server (Leopard) for almost a year now. It works pretty well, so I thought I'll document what I did.

Disclaimer: This is works-for-me-ware. Don't assume that this is officially supported by the Indigo folks. Don't assume that it will work for you until you've tried it. Don't blame me if it doesn't.

Why bother, anyway? Run as a daemon, Indigo can auto-start with the system and run on a Mac without anyone ever having to log in. You can run it as a dedicated user-id (that is not an administrator), which helps with security. It can run headless (say, on that Mac mini in your attic with no display).

Here is what I did: First, as an administrator user, install Indigo (the whole thing, client and server). Using the combined server+client mode, configure the server options the way you like it. Do not ask for automatic server start or restart. Then quit both.

Create a user and group called "indigo". On OS X Server, use Workgroup manager (make a local user and group). On OS X Client, just use the Accounts preference to make a new "normal" user; you will automatically get a group to match. Then change the entire Indigo data directory to that user:

Code: Select all

# as root
cd "/Library/Application Support/Perceptive Automation"
chown -R indigo:indigo "Indigo 4"


Now we'll have to arrange for the Indigo server to get started as a daemon. Put the following file into /Library/LaunchDaemons/com.perceptiveautomation.IndigoServer2.plist, again as root):

Code: Select all

<?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>UserName</key>
   <string>indigo</string>
   <key>GroupName</key>
   <string>indigo</string>
   <key>Label</key>
   <string>com.perceptiveautomation.IndigoServer2</string>
   <key>OnDemand</key>
   <false/>
   <key>ProgramArguments</key>
   <array>
      <string>/Library/Application Support/Perceptive Automation/Indigo 4/IndigoServer.app/Contents/MacOS/IndigoServer</string>
   </array>
</dict>
</plist>


If you changed anything (like the name of the user), edit the file to match.

Then run

Code: Select all

launchctl load /Library/LaunchDaemons/com.perceptiveautomation.IndigoServer2.plist


The server should start up (and stay up). There will be an error message in the system log about inability to talk to the window server; ignore that. The server runs as the user "indigo" (or whatever you called it); if it needs access to something (say, a device), make sure it can. Don't let "indigo" access anything else on your computer, for security's sake.

And that's basically it. Launch the Indigo client and ask to connect to "remote" host localhost (127.0.0.1); the client will open up, and you can work with Indigo as usual. Of course, you can also connect from other computers (if you allowed that). Note that everything you do in the UI is now "remote", so none of the "local only" operations (such as "open log folder") will work. If you let the indigo user log in, you can do local administration that way. (I don't.)

What else doesn't work? AppleScripts that want to put up windows won't work, of course - the server is a daemon, after all. More insidiously, some AppleScript actions that don't obviously do graphics are wobbly; for example, I've found that the "say" command actually speaks the words but then returns an error (so the script stops). Experiment; in the case of "say", just wrap a try block around it and ignore the error. Scripting Indigo itself seems to work (so far).

If you need to do something that requires a combined server to run (e.g. upgrading Indigo), first shut down the server:

Code: Select all

   launchctl unload -w /Library/LaunchDaemons/com.perceptiveautomation.IndigoServer2.plist


Then do your upgrade, launch Indigo in combined mode, let it upgrade the database, save the new copy, quit Indigo, and run the "chown" command above again to make sure the indigo user owns everything. Then turn the server back on:

Code: Select all

   launchctl load -w /Library/LaunchDaemons/com.perceptiveautomation.IndigoServer2.plist


Should the Indigo server crash for some reason, launchd will automatically relaunch it. This also applies if you are telling it to shut down, so don't do that - use the "launchctl unload" command instead.

Let me say in passing that Indigo's architecture seems really well done; the server/client separation works and makes this kind of thing possible. It certainly blows the doors off the usual monolithic applications, who need to bring up all their UI bits just to run as servers, with all the instability that can entail.

Questions? Just ask...

Cheers
-- perry

admin edit: changed Indigo 2 folder path to Indigo 4.

[matt (support)]

Hi Perry,

Thanks for the very useful post. I've flagged it to be sticky.

Regards,
Matt

Can the same method be applied to the Serial Bridge so that it is not dependent on a user loggin in?

I tried but got, the following error:

7/3/08 5:40:26 PM com.perceptiveautomation.SerialBridge[3301] _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

[jay (support)]

Unfortunately, Serial Bridge was not designed to be run as a server (like) process so it requires a connection to the window server, and thus, needs to have an account logged in to run correctly. (This being a really good guess since I don't have access to the code at the moment! )

Regards,
jay

The original post in this thread was for Indigo 3.x running on OS 10.5. Since launchd is still in 10.6 I would assume this scheme will work for Indigo 4.x under OS 10.6. But, has anyone actually done it?

[jay (support)]

I haven't tried. There may be some permission issues with scripts that talk to other applications running under other user accounts though - I think they tightened up access control in Snow Leopard.

In indigo 5
Will Python have the same issues as AppleScript when running in a daemon environment. ?
Or, what I am really asking is will Python function in a daemon environment ?

Will Python have the same issues as AppleScript when running in a daemon environment. ?
Or, what I am really asking is will Python function in a daemon environment ?

Python itself doesn't care about this server business and will work just fine. (In the setup described above, it'll run as the "indigo" user, of course. That affects which files it can read and write, as it should.)

You can still get into trouble if your Python code imports modules that do graphic-like things (like open windows). The rules haven't changed as to what it means to be a server. But you're less likely to run into haphazard issues like AppleScript's "wait, I can't talk if I don't have a screen" issues.

Cheers
-- perry

Any update for 10.7, or should this still work? I have a Mac Mini that I am about to upgrade to Lion and I want to use as an Indigo server. Currently, I have to leave it logged in and that is a security issue I would rather not have to worry about.

[matt (support)]

I haven't tried it, but I believe that plugins will currently not work in daemon mode. We might eventually fix that, but right now we have higher priority features keeping us very busy.

Here is a sort of a work-around.

Set the computer to auto log you on at startup.
Then, create a script (AppleScript, shell, Python, Perl, or whatever - as long as it is executable) that will suspend your session after a short period (10 - 30 seconds).

And in a shell script it is:

sleep 30
/System/Library/CoreServices/"Menu Extras"/User.menu/Contents/Resources/CGSession -suspend

This will work in an AppleScript (BUT... save it as an application, not as script:

delay 30
do shell script "/System/Library/CoreServices/Menu\\ Extras/User.menu/Contents/Resources/CGSession -suspend"

Place the script in your LoginItems list.

The computer will boot, log you in, start Indigo, and then bring up the login screen.

Hey Perry, thanks a ton for this documentation, it was a great help. I figured that I would add to the thread with my own experience.

System Setup:

• Mac OS X Server 10.6.8
• Indigo 6.0.0 B8
• PowerLinc USB Interface #2413U
• Mac Mini 1.66 Core Duo

Notes and Thoughts:

• Do be very careful about permissions on property list files, I added write access for the admin group to make things easier and was no longer able to launch jobs, got this error: "launchctl: Dubious ownership on file"
• Dont try and log into the computer as the indigo user that you just created. The system complains about the lack of a home folder (if you didn't set one in the workgroup manager) There really is no reason to, I wanted to just check if I could launch Indigo from the UI as that user and was not able to. OSX is not happy when there is no home folder, avoid actually logging in as this user.
• There have been some updates to property list syntax, the OnDemand flag has been deprecated in favor of KeepAlive
  

  Code: Select all

  <key>KeepAlive</key>
<true/>

• If you try and use the GUI property list editor that comes with Xcode(?) you will end with with a plist file that is not in the XML format, and seems to throw random complaints about key/value pairs. I have no idea why this is, but I went back to hand coding XML and it works fine.
• You can log standard/error out to log files as options from the plist keys. This is useful for debugging:

  Code: Select all

  <key>StandardOutPath</key>
<string>/var/log/myjob.log</string>
<key>StandardErrorPath</key>
<string>/var/log/myjob.log</string>
<key>Debug</key>
 <true/>

• The console GUI is your friend when trying to debug things, all the stdout from launchctl is visible there, also very helpful.
• The Indigo GUI seems to take a while to register that the USB interface is loaded. I had a slight panic attack when I first was able to remotely connect to the Indigo server, but the GUI showed that the powerlink adapter was ... down? (It was red, didnt become green for a while)
• The apple launchd.plist docs are quite good: http://developer.apple.com/library/mac/ ... nchd.plist
• If something is failing on the command line while you're setting this up, you might have forgot a sudo somewhere. Once again, most of this config is pretty sensitive to user permissions. If something is wrong, check your permissions first!

Anyway, I'm up and running headless now, I'd be glad to answer any more questions if anyone has them.

[matt (support)]

Hi Kevin,

Thanks for posting your notes. I'm curious, are you able to use Indigo plugins in daemon mode? We haven't tried it, but I'd be interested in hearing if it works or not.

Matt,

As a quick test with Device Collection, it does not appear to be working.

• There are no errors in the log, the plugin init phase of server startup looks as usual.
• There are PIDs for the loaded plugins. (in the log window) and the system activity monitor reports them to be running with the same PIDs
• The Indigo GUI plugins menu throws no errors to the log when enabling/disabling any plugins
• When attempting to create a device collection from the device list, the only editable field in the dialog is the name.
• The device collection appears in the list, but no attributes are available. See attached screenshot

Is there a way to turn on a verbose debug mode to get more information?

[matt (support)]

The Model popup in the device dialog after you select Device Collection is empty? Can you take a screen shot of it?