CR-1848 OPENDJ-983 On Windows, unexpected error message while running start-ds -V/-F/-s on an instance not configured

Fix for OPENDJ-617. Resolve race condition in Windows Services when stopping the server.

Fix OPENDJ-161 - Update windows executables

Fix for issue #4554 - Potential problems using Windows Service during startup. The fix consists on waiting in the service code to the start-ds.bat call to finish (the re-entrant one). This avoids having a race condition problem locking the file (as can happen today). There is a new environment variable that can be configured (OPENDS_WINDOWS_SERVICE_STARTDS_WAIT). The default value is 300000 milliseconds (5 minutes). This is the maximum time in milliseconds the service code will wait for the server to start before checking directly its status. Also update setup.bat and uninstall.bat to return an error code when called in CLI mode.

Fix for issue 4084 (Windows Service doesn't detect start-ds failure) Improve the code of windows service to poll the status of the server (whether is running or not). Improve some of the messages associated with the events that are sent to the windows service log. Improve the code that is in charge of starting the service (and the server) to help identify cases where the server startup is correctly launched but the startup itself fails (because for instance a port of the server is already in use).

Fix for issue 3566 (Increase the timeout of the windows service and consider making it configurable). The fix increases the number of tries used to figure out if the server is started or not. This is required in particular after reboot since the system can be really loaded. The user can modify the default tries value (100 tries with an interval of 5 seconds between tries) by setting the value of the OPENDS_WINDOWS_SERVICE_START_NTRIES environment variable (it must be a SYSTEM environment variable in order to be taken into account).

Fix for issue 3461 (winlauncher should not inherit handlers from parent process) The fix consists in setting the inheritance flag of tderr/stdout/stdin of the parent process to FALSE before creating the child process.

Fix for issue 1603 (quickInstall fails to register service on vista) With the new user access control of Vista, even if we are administrators we are not allowed to do certain operations (such as writing in the service registry) in some circumstances. For instance if we launch net start <service_name> from a normal command prompt this will fail systematically. In order to be able to execute these "privileged" operations we have different alternatives: Execute the binary that will do the operations using the "Run as Administrator" option in Vista (or launching them from a command prompt that has been started using that same option). Add a manifest to the binary informing that the binary requires administrator privileges. The first alternative is one of the workarounds for the bug, however it does not apply to the case of the Java Web Start Installer. The second alternative is in what consists the bug fix. A new binary has been created. This binary has a manifest informing that it requires administrator privileges. This binary will be used in Vista as a wrapper to call operations that require administrator privileges (modifying the registry in windows-services.bat command line and calling "net start" and "net stop"). If the user is running the setup, the status-panel using the "Run as Administrator" option or is using the command lines from a command prompt launched with that option the behavior in Vista does not change with the behavior in previous versions of Windows. If the UAC is enabled and the user is not using the "Run as Administrator" options, (s)he will be prompted for confirmation each time the registry is modified and the server is started or stopped as a service. The wrapper is called on any of the individual operations. An alternative would be to call the wrapper when we launch the setup or the status-panel but this generates some issues: 1. This does not work (directly) with the Java Web Start installer. 2. This would force users that are not administrators to provide administrator credentials even to install/run an OpenDS that does not require to do privileged operations (an OpenDS that does not run as a service).

Fixed a problem where OpenDS couldn't be installed on Windows in a directory with a space in it's path. There was also a similar, but more benign problem with log messages generated from start-ds.bat and stop-ds.bat.

This checkin includes a few changes, but the only real problem that I saw was here: - debug("Deleting the service '%s'."); + debug("Deleting the service '%s'.", serviceName); Which was causing the process to core on uninstall. So I went through the other debug messages, and made a few more changes that most likely wouldn't have caused problems. For instance, - debug("doStartApplication: spawn failed. Sent command:"); - debug(command); + debug("doStartApplication: spawn failed. Sent command: '%s'", command); Technically, command could include a format directive (e.g. %s) in which case we'd have the same problem as debug("Deleting the service '%s'."), but this is unlikely. There are also a few other debug messages that I added to track down the real problem, and I've left them in.

Updating Windows service related code and executables. This fixes a problem with stopping the server on Windows, and also adds a lot of debug logging to the service code, so we can track problems down in the future

Fix a number of issues with David's approval: 1. A char array was set to NULL wrongly which caused a core in the windows services code. This problem appeared almost systematically when the install path was long. 2. The windows services code got into an infinite loop when the server could not be started. 3. The windows services code was missing to unlock a file after testing if it could lock it. 4. Create specific loggers for Setup, Uninstall and StatusPanel applications. This avoids having duplicated and not very user friendly log lines on the output of these applications. 5. When we cannot launch the graphical applications store the stack trace we get in the log file associated with the application and inform the user about the existence of this file in the same message where we tell that we are falling back to the CLI mode. 6. Fix a refresh problem in the status panel. Now when the number of entries of the database increase the contents of the panel are automatically updated. 7. Modify the name of the Age of Oldest Missing Changes as mentioned by Brian. 8. Redirect some logging/debugging lines of the windows services to a file called windows-service in the logs directory.

Update the binaries for windows services to take into account the new location of the start-ds.bat and stop-ds.bat scripts.

Fix for issue 528 (Windows Service Definition for Automatic Startup). The following changes are targeted to be able to run OpenDS as a windows service. The idea is to be able to run OpenDS to run as a service and to be able also to disable this feature. The setup has been updated to run OpenDS as a service in windows (which is the standard behavior in this platform). The uninstall has also been updated to remove all references to OpenDS in the Registry and in the list of services once OpenDS has been uninstalled. A new executable (opends_service.exe) has been added to be able to perform all the tasks that require native code (registering/unregistering the service, sending events to the event log, etc.). Most of the code required by this executable is in the file service.c. The README file has been updated and a Makefile file provided to generate all the executables. A new command line has been added: windowsservice.bat. The usage of this command line is the following one: This utility may be used to configure OpenDS as a Windows service. Usage: windowsservice {options} where {options} include: -e or --enableService Enables OpenDS as a Windows service. -d or --disableService Disables OpenDS as a Windows service and stops the server -s or --serviceState Provides information about the state of OpenDS as a Windows service. -H or --help Display this usage information. The class associated with this command line (ConfigureWindowsService) uses opends_service.exe. ConfigureWindowsService is basically a wrapper that allows to have the messages displayed to the user in the Java code (and so to minimize what is done by the native code). Some changes have been made in the start-ds(.bat) and stop-ds(.bat) scripts by extending what the --checkStartability (in DirectoryServer class) and --checkStoppability (in StopDS class) do. I think that it is a good idea to have all the parsing of the arguments into the java code (specially considering the limitations of the .bat files). So I have moved most of the parsing to the java code so that the is the java code that provides a return code to the scripts to tell them what to do (start the server in detach mode, stop the server using a system call, stop the server using protocol, etc.). In the particular case of how start-ds.bat and stop-ds.bat have been updated to manage the case where the server must be started using the system call 'net start <service_name>' and 'net stop <service_name>'. --checkstoppability and --checkstartability tell whether the server must be stopped/started directly with a system call (or stopped using LDAP protocol) or using the Windows Service system. If it is the latter the bat files use two new auxiliary classes (StopWindowsService and StartWindowsService). These classes figure out the service name associated with the OpenDS instance and call net stop (or net start) using that service name. When net start/net stop are called start-ds.bat (or stop-ds.bat) are called. The Windows Services have been configured to call start-ds.bat and stop-ds.bat with some particular options (--windowsNetStart and --windowsNetStop) to identify the case where we must start/stop the server directly (and so not having an infinite recursive loop of calls to net start/net stop). In order to have the same user experience when the server is configured to run as a service and when is not the tool class WaitForDelete has also been updated to write its output to a file. This has been done because piping from the standard output to a file in the context of a Windows Service call does not seem to work properly. So now WaitForDelete has a new option --outputFile. setup --cli on windows has a new option '-n' or '-noWindowsService' to allow not to enable the windows service. When run in interactive mode and this options is not specified the user will systematically be asked whether to enable the windows service or not.

Fix for Issues #1025 and #1248 ('stop-ds.bat should be able to stop server even if LDAP port' and 'cannot stop server through status panel'). The goal of these changes is to be able to have exactly the same user interface in Windows and Unix to stop the server. In windows we force the user to provide LDAP credentials even if the command is going to be run locally. The goal is to allow to stop the server using only system credentials (as we do in UNIX) when the user does not provide arguments when calling stop-ds.bat. In order to do this I have written some native code. This native code is called when we start the server to: 1. Launch the java process and get the associated PID. 2. Create a server.pid file as we do for UNIX systems to store the PID of the process. The native code that stops the server reads the PID file contents and tries to stop the process associated with the PID. In order to allow the users to be able to build the product with independence of the platform, the binaries will be included with the source code. The code used to generate these binaries will also be provided. I have generated 1 executable called winlauncher.exe. The binaries will be committed in the source tree under lib (with activation.jar and mail.jar). They will also be installed under <server root>\lib. The native code is in the files winlauncher.c and winlauncher.h. These files are placed under the new directory build-tools/src/windows. I have tried to keep the native code simple and leave as much logic as I could into the batch files (for instance everything related to the discovery of the java binaries) so that the administrators can play with them. A README file has been also been included to explain how to generate the binaries. Extras: When we call start-ds from the command line, the server will not stop when the command prompt window is closed (unless start-ds was called to run in not-detached mode). The next step is to register DS as a service to avoid the server to be stopped when the user logs out. When we call setup (with no arguments) or the statuspanel the generated process (and windows) will no longer get killed when the command prompt window is killed. When the user double-clicks on the setup.bat or the statuspanel.bat files, the command prompt window only appears briefly. Today when we do this a command prompt window stays open until we close setup or the status panel window.