Hudson build fails when a user logs out of RDP session - build

We are using Hudson to build mixed C++/Java projects with an Ant script. It is running in Tomcat 6, on a Win XP virtual machine.
I have noticed recently that when a user logs off the machine (from a remote desktop session), builds that are currently running tend to suddenly fail without an error message.
Has anyone encountered anything similar or have an idea what might be causing this effect? I can post additional information about our setup if needed, I'm just not sure what's relevant in this case.
EDIT: I have tried running the Tomcat service under various users, but this doesn't seem to help. Tried the standard Local System account, as well as the server Administrator and a domain administrator account.

Try adding -Xrs to the Tomcat JVM arguments.
For more information see this bug.

Related

Oracle 19c Client Installation Stuck/freezes error: INFO: Checking whether the IP address of the localhost could be determined. suspecting GP Policy

I am trying to install Oracle Client 19c when i starts the installation its freezes at stage 1, checked logs it hangs on "INFO: Checking whether the IP address of the localhost could be determined...", i refer some article to skip stage mentioned step but it also stuck on stage 7.
My System is in Domain
I tried the installation on recently formatted System and it worked with antivirus.
also tried to disable the Antivirus from my system but faced the same freezing issues. if unjoin the Domain and try it works.
I suspect the issue with any Domain Policy but dont understand the which policy is creating the problem, please suggest the solution.
If you are seeing "Reading from the pipe" message in ...\Inventory\logs OUT files then, login Windows with an admin account and run the services called "Server" and "Workstation".

How do I get past ColdFusion server-specific error code 2?

I had installed ColdFusion 2018 recently and with the installation less than a month old (and my understanding of the technology even less), my Cold Fusion service has stopped working. I have tried a number of things and have referred to a number of articles and out of many such errors where the service is not being accessible, some of them were able to get it resolved. However, some other obscure reason that may be causing this error have been untouched and unknown.
Whenever, I try to restart the service, I get an error as shown below:
Windows could not start the ColdFusion 8 Application Server on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to server-specific code error 2.”
Without much understanding, I started to google it out. Looking into every one of these posts, I tried
Configure JRE and try to relaunch the service by looking at "JAVA_HOME" variable and JVM.config
Run the batch files in every possible combination to find if anything clicks
Check if the present JAVA version works and is compatible with Coldfusion version installed
Fiddling with the "SessionStorage" var in neo-runtime.xml file as some suggested
and few other tricks coupled with a numerous service restart attempts and a few machine reboots as well.
A service that renders Cold Fusion pages should be shut down abruptly. To add to agony, the CF Admin also depends on the service and hence does not work.
Any pointers to any potential solutions?

ChromeOS errors in GCP Logging

I'm seeing errors in StackDriver logging for my Compute instance. The logs are showing repeated issues every hour, creating a lot of noise. I have a Spring Boot API deployed in a container to a VM in Compute Engine using latest stable version of Container OS.
I'm relatively new to GCP and don't understand what is causing this issue, searches have come up empty so far.
Failed to call method: org.chromium.SessionManagerInterface.RetrieveActiveSessions: object_path= /org/chromium/SessionManager: org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.SessionManager was not provided by any .service files
CallMethodAndBlockWithTimeout(...): Domain=dbus, Code=org.freedesktop.DBus.Error.ServiceUnknown, Message=The name org.chromium.SessionManager was not provided by any .service file
Error calling D-Bus proxy call to interface '/org/chromium/SessionManager': The name org.chromium.SessionManager was not provided by any .service files
The same 3 lines are repeating every hour. Anyone aware of what might be causing this or how to fix/suppress these?
I looked into this error, and as per my findings:
The error message that you have been receiving is a manifestation of Chrome to reliably exit shortly after starting up.
The UI’s job (which encompasses Chrome, the session_manager and the window manager) gets shut down by upstart because of it's thrashing, and when the test tries to restart the session_manager, the session_manager cannot communicate it over to the D-Bus.
The crash collection software in Container OS was originally for Chromebooks (The laptop using Chrome browser). So the code typically expects Chrome and some other related software on the system.
However, Container OS is a server OS, and does not have Chrome. So if Chrome is missing, the software will report some errors. They are actually not real failures, just some verbose error messages.
Overall, It is safe to ignore these logs and continue using your VM Instances.
Hope this helps.

How exactly does the WiX 'Service Install' work internally?

I have a problem with a web service that is installed and started with a .msi that is created with the WiX toolset.
The service can be installed and started on all the machines I tested so far (shown as running in the Services Manager) but on some machines it is not reachable (for example via a browser) and not shown in the list of listening ports on that machine (displayed with 'netstat -a').
I am trying to figure out what's going wrong but I am not really familiar with web service development and configuration. It's a third party service, thus I don't know how it works internally.
A good starting point for me would be to find out, what exactly happens when a service is installed and started during the execution of the .msi-file.
Maybe I could try to tackle the problem on a lower level then.
Below is my code in the ServiceInstall-Element:
<ServiceInstall
Id="ServiceID"
Type="ownProcess"
Vital="yes"
Name="ServiceName"
DisplayName="ServiceDisplayName"
Description="Lorem Ipsum"
Start="auto"
Account="LocalSystem"
ErrorControl="normal"
Interactive="no"
Arguments="action=run">
</ServiceInstall>
The argument is important - without it, the service won't start or run.
Maybe someone else encounterd the same or a similar problem and can help me out.
Thanks already in advance - each hint is appreciated.
EDIT I (15.04.18):
As it might be a problem with the specific service, I will add some further information here:
It's a third party software called CryptoLicensing:
http://www.ssware.com/cryptolicensing/cryptolicensing_net.htm
Part of this software is that specific program, that serves as a License Server and does the license registration, for example in a customer's network.
The service can be run as a Windows application or installed and run as a Windows service. In both cases it should be listening on a (pre-)specified port on the installed machine.
Whenever I start the .exe as an application, everything works as intended. The service is reachable (for example with the browser) and can be accessed from other machines in the network.
When the .exe is installed and started as a service, it does not work as intended on every machine. For example if I install and start the service on my laptop, it is shown as running in the Services Manager, but is not reachable on its assigned URL (not even on the localhost) nor is the specific port displayed in the active listening ports, for example with 'netstat -a'.
The service itself starts without any error messages and does not log any errors or exceptions as it seems to be running without any problems.
I contacted the vendor, but sometimes he doesn't reply quickly and he is not very specific in his replies.
Before asking the question I assumed that it was a problem with the Windows user rights and the WiX installer but during the discussion here I had the feeling that it might a problem with the service itself.
I hope this 'new' piece of information helps in isolating and location the problem.
Thanks to everyone who helped so far!
Hopefully not stating the obvious here, but WiX doesn't do much except populate the ServiceInstall table in the MSI file, so this is about why Windows Installer won't start the service. ServiceInstall table:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa371637(v=vs.85).aspx
Also, this isn't really about ServiceInstall - it's probably about the ServiceControl element in your WiX source, but it's not clear whether that's how you're starting it or if you're starting it manually later on. That does make a difference. What is the error message and where are you getting it, and is it a 1920 or 1921 error (in the context of ServiceControl).
The main reason a service will start on one system but not another is missing dependencies. If your service is C++ based (the post doesn't say) then there are probably dependencies on C runtimes, UCRT runtimes, MFC or ATL runtimes and so on.
First: are you sure this service is intended to run as LocalSystem? (MSDN, SO).
Second: did you check the event logs in detail for anything obvious? If the service is good you should find a hint at least. Something to start with. I find that I sometimes miss the actual logs in the event viewer because it is so "crowded". My take on it: empty the log and stop and restart the service.
Something locking / blocking: If the service installs and runs OK I would suspect other factors such as firewalls (hardware & software), security software in general (anti-virus, malware scanners), network configuration issues (proxies, WINS, DNS and all the complexities involved in networking). Is the service trying to reach an UNC path?
Diverse Machines: What are the target machines? Are they virtual, are they physical, are they test machines, are they operative SOE machines in corporate networks? Are they the same OS version and edition?
Further Ideas: It is not quite related, but maybe skim this list of suggestions for debugging from another answer (I am not sure why it was down-voted, I think it is an OK list to inspire debugging ideas): Windows Application Startup Error Exception code: 0xe0434352 (maybe just skim the bolded words for ideas - Recommended).
sc.exe: And finally, perhaps check the sc.exe tool (Service Control) and see if it can provide you with some useful information for debugging.
sc.exe in the context of killing hung services (sample use).
sc.exe from MSDN
Some further links:
Windows Services Frequently Asked Questions (FAQ). Content seems to be up to date - at face value at least. These guys claim to be experts on services. I have no idea who they are.
Essential Tools for Windows Services: SC.EXE
Run Service Control (sc.exe) command on secure port
After almost 20 months we finally (and accidentally) found a solution to the problem! For the few machines, on which the service did not run properly, setting the NoInteractiveServices value in the registry to 0 did the trick. A value of 1 (which is default) means that no service is allowed to run interactively, regardless of whether it has the SERVICE_INTERACTIVE_PROCESS property. More information on Interactive Services.
I am not completely satisfied with the solution, because on all the other machines NoInteractiveServices is set to 1 AND the service runs properly anyway. However, on the machines where the service did not run interactively this solution worked for us. Thus I will accept this as an answer.
If anyone has more information on this issue and can explain why this works, feel free to
add them - I would be very interested!

CruiseControl.NET run as a windows service and as a standalone process behaves differently

I have a project that is being built using CruiseControl.NET. The project contains an 'MSBuild task' that runs the build for the project and also the unit tests. The unit test in turn is just a MSBuild 'exec' task that runs an executable.
The unit test involves some .NET remoting. And when the unit tests are run through the system command prompt, the software's window opens up, tests run and the process exits.
When I force a build through the web dashboard, the build hangs at the point where the unit test starts running. The software's window does not open up, but the executable is running. If the process is killed through the task explorer, the build goes through with a 'Failure' status. This happens when I run ccnet as a windows service.
If I run CCNet directly (not as a windows service) and force a build through the web dashboard, the build and unit tests go through fine as expected. (with the window of the software opening up.)
It looks like there is a deadlock in the case where CCNet is run as a windows service. I am guessing it is related to the standard output/error streams.
Is this is known problem?
What might be the problem going on?
Any suggestions on debugging this?
How can I get around it?
(I am using CCNet version 1.4.4 SP1)
When CCNet is running as a service it is not going to have access to the display, so don't expect to see anything on the screen in this configuration. The first thing I would check is the permissions - make sure the service runs as an account that has permissions to access whatever resources you need. You also have CCNet log files, which you can find via Dashboard.
On a side note, try TeamCity instead of CCNet, its 10 years ahead.
Maybe this answer will help :
delphi windows service can't download file from internet
You should know that when running CCNet as an application (the dosbox) it uses the environment variables and all rights from the logged account. So it may connect to a server, use cached passwords, get registry variables for this account.
BUT when ran as a service, the account is the one you provided : LocalSystem for exampe, where env. varibales are not the same.
So, what you can do is to change the CCNet service account for test. Change it to your user account (with password), and I'm sure it will work better !