site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com That is not really an Installer question but here are some tips anyway: Here are some Apple Tachnotes that might help you: <http://developer.apple.com/technotes/tn2005/tn2083.html> <http://developer.apple.com/technotes/tn/tn1145.html> You can test it manually by calling something like: See man SystemStarter for details and how to turn on verbose logging. ConsoleMessage "Starting myServer" } StopService () { sudo kill -9 $(ps -ax|grep ./myServer|head -n 1|cut -c 3-5) See comment about sudo above. And kill -9 seem kind of brutal to me. ConsoleMessage "Stopping myServer" } or just do this to avoid duplicate code: StopService StartService } RunService "$1" HTH Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Web: <http://homepage.mac.com/mike_fischer/index.html> Note: I read this list in digest mode! Send me a private copy for faster responses. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... Am 25.09.2006 um 21:02 schrieb "rohit dhamija" <rohit.dhamija@gmail.com>: Dear All, We have developed a sever ( basically a daemon) using Xcode 2.2 for Mac OS 10.4.x ppc/Intel and 10.3.9 which functionally performs well. But I have some issues of server starting specifically when the machine starts/reboots and require your expert comments to resolve this tricky situation. I have developed a script file that is used to start and stop the server. To start the sever automatically, we have included this script file in rc script (i.e. /etc/rc ). The server gets started automatically at start of the machine. Not a good idea as the rc stuff is basically off limits on Mac OS X. Apple might change or overwrite your script or hook anytime. For example when they do a system update. But as per my requirements, the server needs to be connect to network and save some n/w relevant information in its database (e.g its own IP address) But unfortuntately, this does not happens, probably because the rc scripts makes run myserver "even before the network is initialized". A scenerio which makes me sure for this is: "Although my server gets started, but its database contains - 127.0.0.1 IP address instead of its original IP. On the other hand if my restart my server when the machine is fully up, I get the correct n/w information. i.e. i get the correct IP 172.125.14.64 " On 10.4 and up you should probably use launchd, i.e. a LaunchDeamon, to do this right. On earlier systems, which you are targeting, the SystemStarter method (StartupItem) is what you want. (Note that StartupItems are still supported on Tiger.) Take a good look at the Requires and Uses keys in the .plist. If you require that the networking code is up and running you should say so in your .plist and SystemStarter will schedule your StartupItem accordingly. But also be aware that it is very easy on Mac OS X to change the network settings on a running system. It's something I do quite often when visiting clients and hooking into their network for example or when a VPN connection is started or even when testing something. You need to take this into account inside your deamon and not rely on the one network setting it encountered on launch to stay that way. After going through some articles in Apple for starting/stopping the server (http://developer.apple.com/documentation/MacOSX/Conceptual/ BPSystemStartup/Articles/StartupItems.html ) I tried to load the server at startup so that the myserver should start only after the n/w is up. But unfortuantely, now my server doesnot even gets up at the startup. This is too unspecific to help. Is your StartupItem not triggered or is the failure at some later point in time? I've put the following scriptfile inside a uniquely named folder in the /Library/StartupItems folder (which I also created) along with a simple StartupParameters.plist file. Read the section on StartupItems again. Make sure the name of the StartupItem folder matches that of your script. Make sure the name of the .plist is "StartupParameters.plist". Make sure the .plist contains all the necessary keys. $ sudo SystemStarter start "the service you registered in the Provides key of the .plist" However, it never seems to get loaded. That is, when I go into the Process Viewer, my server is never there. Neither do any of its (sparse) debug messages appear in the console. Below is the script file that I place in my folder. . /etc/rc.common StartService () { cd /Applications/MyCompany\ MyProduct/Common\ Files/MyProduct\ Keys \ Server For testing this may be ok. But in real life relying on a fixed path like this is risky. Users tend to move things around. For example I regulary put any 3rd party apps into a subfolder of /Applications. Either use a location not generally visible to users (like /usr or / usr/local) or put your server or its launch script into /Library/ Application Support/MyProduct/. Most people will not move anything around in there and if they do they know they're on their own. sudo ./myServer sudo should not be necessary here since the StartupItems are generally started with root permissions AFAIK. It may even cause the script to fail because there will be no way to authenticate for the script. Remember this all usually happens before the login screen is even shown. And your method of finding the running process seem very risky to me. What if that code findes some other process and kills it? You can't guarantee that your process name will be unique. RestartService () { ConsoleMessage "Restarting myServer" sudo kill -9 $(ps -ax|grep ./myServer|head -n 1|cut -c 3-5) cd /Applications/MyCompany\ MyProduct/Common\ Files/MyProduct\ Keys \ Server sudo ./myServer Did anybody faced similar situation ??? Can you please tell me where can be the possible issue ?? Why is the server not able to load at the startup ? Well, I showed you several possibilities of why this might fail for you. Now you need to test and see where it's actually failing. This email sent to site_archiver@lists.apple.com