Coding service applications

There are differences in the ways code for traditional daemons and code for Windows services is written. Some of the rules for coding daemons can cause problems if you apply them to writing code for Windows services.

The following list describes things to avoid when writing code for Windows service applications:

• Do not use fork() and have the parent use exit(). The intent is to make the shell function as though the command is done, and ensure that the child is not a process group leader. If the parent process uses exit(), psxrun.exe treats the program as having exited, and the Windows Service Control Manager will report that the service was never successfully started.
• Do not call setsid() to create a new session. The call will fail. The psxrun.exe program ensures that the service process is a session leader.
• Do not access network drives mounted on drive letters. Network drives are typically mounted on drive letters when a user logs on to the console. They are unmounted when that user logs out. Furthermore, a service program cannot depend on a given network drive being mounted on a given drive letter, and if a service uses net.exe to mount a network drive, the drive letter it uses will become unavailable to interactive users. This can cause winlogon.exe to display error messages.

  The best way to access network drives is through the /net directory. This does not require a drive letter and you do not have to mount the network drive.

The following list describes things you should do when writing code for Windows service applications:

• Use hard-coded, absolute path names, such as /tmp, /bin/sh, or /usr/spool. You might need to change some path names to correspond to locations in the Interix subsystem, however.
• Design your services to exit when they receive the SIGTERM signal. If necessary, you can catch the SIGTERM signal, clean up, and shut down. Since there can be interactions with the Service Control Manager, it is unwise to spend more than a few seconds cleaning up.

The Interix Software Development Kit (SDK) contains the same daemon() interface that is found on Berkeley Software Distribution (BSD) systems. The daemon() application programming interface (API) uses fork() and setsid() mentioned above.

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at webmaster@systemmanager.forsenergy.ru to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.