Launchd, daemons and permissions

A short while ago, I had problems getting a service running using launchd. I thought I got everything working:

http://discussions.apple.com/thread.jspa?threadID=2098974&stqc=true


It seems I didn't, and - okay - it has probably got something to do with me not knowing too much about agents and daemons.

The situation is this: I have a service (Ray Media Server) that I would like to keep running at all times. I managed to get a plist file written, and got so far as to have the service running as an agent, which unfortunately means that I have to be logged in for the service to run. That is no good, so I obviously have to make it run as a daemon.

But I can't...

When I move the plist file to /Library/LaunchDaemons it doesn't work. I guess it has something to do with permissions, but I don't know what. I have tried tinkering with ownership and permissions - as of now root:admin owns the plist file and the whole directory (as well as alle files in that directory) the script-file is located in.

The service doesn't start, and nothing is written to my log files.

Any ideas?

Max OS X Server (Xserve), Mac OS X (10.5.5)

Posted on Aug 14, 2009 1:26 AM

Reply
8 replies

Aug 14, 2009 3:49 AM in response to KJK555

The /Library/LaunchDaemons folder is for user daemons, where as the /System/Library/LaunchDaemons is for system daemons. Therefore I would like to use the former path.

The file has actually been created using Lingon (and it works, when placed in /Library/LaunchAgents, so the plist is ok). Lingon puts the file in /Library/LaunchDaemons (which, holds another plist file, which works - that file was installed by an application, though).

I have done a "sudo chown root:wheel" and "sudo chmod 644" on the file, but it didn't solve my problem.

I will try anything, so I have tried moving the file to /System/Library/LaunchDaemons - it made no difference.

It seems to me, that the problem could be with permissions on the application, that is launched. It is a script, that launches a java application. I would just expect root:wheel to have permissions to do practically anything that a regular user is allowed to do...

Oh - and I get no messages in the error log, that I have specified in the plist file...

When a plist file works as an Agent, I would think it was a matter of moving it to /Library/LaunchDaemons, change owner:group to root:wheel, and make sure the permissions were 644. But it doesn't seem to be enough...

Aug 14, 2009 5:55 AM in response to TheRealSync

TheRealSync wrote:
A short while ago, I had problems getting a service running using launchd. I thought I got everything working:

http://discussions.apple.com/thread.jspa?threadID=2098974&stqc=true


It seems I didn't, and - okay - it has probably got something to do with me not knowing too much about agents and daemons.

The situation is this: I have a service (Ray Media Server) that I would like to keep running at all times. I managed to get a plist file written, and got so far as to have the service running as an agent, which unfortunately means that I have to be logged in for the service to run. That is no good, so I obviously have to make it run as a daemon.

But I can't...

When I move the plist file to /Library/LaunchDaemons it doesn't work. I guess it has something to do with permissions,

no it doesn't. all it needs is to be readable. you are knocking on an entirely wrong door. what it most likely does have to do with is that plists placed in /Library/LaunchDaemons are executed before user login over the login window. the system is extremely protective about stuff that can run over the login window for security reasons. depending on what your script does it may be refusing to do it. it's impossible to say more without knowing full details of everything your script does. the console log should contain error messages about your launch daemon which should tell you something. do a search in the console for your launch daemon name (** off .plist on the end when searching).

Aug 14, 2009 10:28 AM in response to TheRealSync

plist Files placed in /Library/LaunchDaemons most likely will have admin as the group instead of
wheel. Like VK said; Permissions is probably not the problem anyway.

Being a JAVA app may be the problem. I don't know whether or not the Java Framework is available
before login or at what point in the boot process it becomes available, maybe someone here will
know the answer to that. If it is not available when Leo reads the /Library/LaunchDaemon file
then it won't load.

I was having trouble with a script (not Java) interfering with my login items recently. I cured the
problem by inserting the Sleep command into my bash script, which gave the login items time to
get fully loaded before this program was run.

cron can also be used to start programs.

Kj

Aug 14, 2009 10:33 AM in response to KJK555

KJK555 wrote:
plist Files placed in /Library/LaunchDaemons most likely will have admin as the group instead of
wheel. Like VK said; Permissions is probably not the problem anyway.

Being a JAVA app may be the problem. I don't know whether or not the Java Framework is available
before login or at what point in the boot process it becomes available, maybe someone here will
know the answer to that.

I don't know either but that's where my strong suspicion would lie. if this is the case there definitely will be a console message saying that something (Java?) is not a trusted process and will be terminated.

then it won't load.

I was having trouble with a script (not Java) interfering with my login items recently. I cured the
problem by inserting the Sleep command into my bash script, which gave the login items time to
get fully loaded before this program was run. cron can also be used to start programs.

Kj


Message was edited by: V.K.

Message was edited by: V.K.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Launchd, daemons and permissions

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.