macrumors Pentium

There's info on there about how to write a server process (daemon) using listen() and accept(). I'd suggest also looking into fork(), as you'll need some kind of parallelism (and multi-process with fork() is easier than pthreads).

thread startermacrumors member

By the way, I got many articles but they were little high end I just wanted to have something to the ground level so that I can understand well, more over I am just 2 month old Mac Programmer. Sorry about it !!

thread startermacrumors member

I just want to start a Server program (which is written in Objective-C). To achieve this

- I have to write script (Apple Script or Perl Script) to start the Server Program, where should I put this file?
- Configure plist and put it under /LaunchDaemons folder because it has to work for all users

All system-wide daemons (LaunchDaemons) must be owned by root. Configuration files must not be group- or world-writable.

Click to expand...

Here configuration files means launchd .plist files.

Also I don't know if you can execute an apple script or perl script directly from a launchd .plist even with a she-bang line in the script. You might have to directly executed the relevant interpreter and pass the script as an argument to the interpreter. For example, for an AppleScript, you might need to setup the ProgramArguments array like so:

EDIT: On other thing you could do (if you haven't already) is add StandardOutPath and StandardErrorPath keys with string values being absolute paths to files. Then check those files for error messages.

Any stps I am missing ? Do I need to any permissions or something else ? Because in one of the tutorial I read "Remember to make it executable (PERL file); probably best to change the owner/group to root/wheel and set rwxr--r-- permissions." but I dont understand what it is?

You don't need to run this in /Library/LaunchDaemons, so you shouldn't.

From Apple technical note tn2083:

Quote

If you've decided to implement a background program, you must then determine whether you need an agent or a daemon. The main reason for using a daemon is that you need to share some state between multiple processes in different login sessions. If you don't need this, consider using an agent.

macrumors 65816

While the advice about agents verses daemons is generally good, this is clearly a test setup being done by the OP. If you check his other threads, his ultimate goal server-wise does fit the bill of daemon, it won't work as an agent.

However, the advise of not running as root is valid. You should follow the model of likes of Apache and MySQL. Create a special-purpose, non-root user for the purposes of running your sever. Have all the files owned by this special-purpose user.

A word first about the exit -1. The exit -1 in the perl script is only for this test. You would normally not do this. The script launched by launchd is meant to keep running while your server is running. If the script exits, it means the server exited and needs to be relaunched. But this test script exits very quickly. The exit -1 causes an unsuccessful exit, and stops launchd from relaunching the script over and over rapidly.

The primary reason your script failed to run was because you'd coded an on-demand launchd plist file. But you never specified under what conditions the test script should be run, so it never did. You need to include the KeepAlive key like above. This particular KeepAlive setup also implies RunAtLoad, so launchd will immediately run the test script.

Even if you'd got that right, the running of the script would have failed. At no point did you setup perl to run the script. A .pl extension is not enough. You either need a she-bang line at the top of the script, or to explicitly invoke perl like I've done in the .plist file.

Lastly you use a relative path for file.txt in your test script, but what do you expect the working directory to be? You've got to set the in the .plist file.

EDIT: I seems you have very little Unix experience. Writing a server under Mac OS X without Unix server administration experience is going to be bad. I'd suggest you learn how to install, setup and administer a Unix server package such as Apache or MySQL. In doing so you will learn how a Unix server is meant to behave, and give you a model for creating your own server.

AFAIK, there is no "/perl" executable. There may be a "/usr/bin/perl" executable, as jiminaus showed. Find out using this command in Terminal:

Code:

which perl

Or just follow the given example exactly. Or if you have your own custom-installed version of perl, then use its exact pathname.

And the pathnames "/users/siva" should use the correct case to match the actual directory names. It's a non-issue on a case-insensitive file-system, but you might not always have that. It's better to be exact.

macrumors 65816

In addition to the possible problem of the path to perl that chown33 pointed out, there's also 2 other potential issues I can see.

The line about your .plist file says /System/Library/LaunchDaemons (a no-no), but you're launchctl comamnd refers to /Library/LaunchDaemons. Make sure you have no versions of your .plist file in /System/Library/LaunchDaemons, and that the latest version is in /Library/LaunchDaemons.

To check the ownership and permissions of the .plist (which is critical), what's the output of this command? (copy and paste the output into code tags, don't paraphrase)

Code:

ls -al /Library/LaunchDaemons/

You need to unload the .plist file, before you reload a newer version.

I wouldn't expect that to solve your problem, if you have a problem in regards to ownership and permissions, which I suspect you might have.

BTW You probably don't know about the online manual pages. There's a command called man which will display online manual pages. For example, you can read the manual page for launchctl with the command:

Code:

man launchctl

You can get a list of all the launchd .plist keys and their documentation with the command:

Code:

man launchd.plist

You can get the manual page for the man command itself with:

Code:

man man

Lastly the commands for change permissions and ownership are chmod and chown respectively, you might want to read those manual pages.

macrumors 68040

While the advice about agents verses daemons is generally good, this is clearly a test setup being done by the OP. If you check his other threads, his ultimate goal server-wise does fit the bill of daemon, it won't work as an agent.

Create a special-purpose, non-root user for the purposes of running your sever. Have all the files owned by this special-purpose user.

Click to expand...

Which means it can be run in a "per user" context, which is what I suggested.
There is an interesting talk about launchd by Dave Zarzycki from Apple who wrote launchd at Google tech talk: http://www.youtube.com/watch?v=mLwn_TbBntI

Fair enough. But a daemon and an agent are setup the same way, just in different directories.

Quote

Which means it can be run in a "per user" context, which is what I suggested.
There is an interesting talk about launchd by Dave Zarzycki from Apple who wrote launchd at Google tech talk: http://www.youtube.com/watch?v=mLwn_TbBntI

Click to expand...

Except an agent is only started with a user is logged in, if I'm not mistaken. The scheduled tasks part of the OP's server plans won't run if a user is not logged in.

macrumors 65816

That is the difference between "per session" and "per user" context, "per session" is placed in: ~/Library/LaunchAgents

"per user" in: /Library/LaunchAgents, it will last over login and logout.

Click to expand...

Are you able to test this to be the case? I'm in foreign PC territory right now (I'm at work). My understanding is that a session doesn't start until a user login in. In the context of fast user switching, there can be multiple sessions. Am I wrong?

Also I was thinking the server would need to run as the server user regardless of who is actually logged into the Mac. For that the OP needs to set the UserName and GroupName keys in the .plist file, and they only work when launchd is run as root. My understanding (again I can't test this right now) is that agents are run by the 2nd launchd instance that running as the logged in user, only daemons are run by the instance running as root.

macrumors 68040

Are you able to test this to be the case? I'm in foreign PC territory right now (I'm at work). My understanding is that a session doesn't start until a user login in. In the context of fast user switching, there can be multiple sessions. Am I wrong?

Click to expand...

I'm not saying it should be run in a "per session" context but "per user". If you look at the presentation of launchd in the link this is what is being explained. In a "per session" layer the launch agents come and go with login sessions, in the "per user" layer it stays, which is appropriate if you for example want to run a web server. System-wide is only necessary if you must create a service that needs to operate across multiple accounts on the same computer, it's a "per machine" context.

macrumors 68040

Can't get away with watching youtube at work. I'll watch it after. I think I need because what you're saying in conflicting with my understanding.

Click to expand...

Actually the context seems to be set by the: LimitLoadToSessionType key to for example: Background, Aqua, LoginWindow. But the layer which transcends login sessions was added in Leopard apparently. So the difference between ~/ and / for LaunchAgents is only the access, administrator or user.

MacRumors attracts a broad audience
of both consumers and professionals interested in
the latest technologies and products. We also boast an active community focused on
purchasing decisions and technical aspects of the iPhone, iPod, iPad, and Mac platforms.