We have services to start processes with LoadUserProfile(). Those services calls UnloadUserProfile() if process terminates, then terminates services themselves.
Everything works fine there. Also with multiple services. But if we use same user account by multiple services then randomly a problem occurs. Possibly if one of the service that uses same user account, restarts or stops.
The problem is user profile is unloaded randomly in a (our) service, then the process that is started from the service, has no more access to user profile. For example problems by HKCU-accesses for the loaded user.
Note: Services that i'm talking about are only our services.
Our service(s) calls LoadUserProfile() by starting and UnloadUserProfile() by stopping. As #RbMm pointed that unload is not necessary, but should not be the problem even if we call it ourselves.
Thanks to #RbMm for the ReferenceCounting info. (Which were not documented in LoadUserProfile()-documentation)
To solve my problem i need to understand reference counting. Imagine that a user account profile loaded by 2 processes or services. I will use service here.
I need to learn what will be happend by these states;
1: ServiceX calls LoadUserProfile(), then ServiceY calls LoadUserProfile(), then ServiceX calls UnloadUserProfile(), then ServiceX stops. RefCount?
2: ServiceX calls LoadUserProfile(), then ServiceY calls LoadUserProfile(), then ServiceX calls UnloadUserProfile(), then ServiceX calls UnloadUserProfile() one more time, then ServiceX stops. RefCount?
3: ServiceX calls LoadUserProfile(), then ServiceY calls LoadUserProfile(), then ServiceX stops. RefCount?
4: ServiceX calls LoadUserProfile(), then ServiceY calls LoadUserProfile(), then ServiceX calls LoadUserProfile() one more time, then ServiceX stops. RefCount?
Can anybody explain it?
Related
I've wrote a service, that should start before WinLogon launches LogonUI, but I can't find any solution to ensure it.
My service belongs to MS_WindowsLocalValidation group, that is located before, for instance, SmartCardGroup, which SCardSvr belongs to. I suppose, LogonUI needs some SCard functionality, so it should wait until this service starts, but it is just a guess. The obvious guess is that WinLogon waits for COM infrastructure launches, but I can't add my service to this group, because it uses COM, so it should start before my service too.
The question is: is there a way to ensure, that my service will start completely (will set its state to SERVICE_RUNNING) before LogonUI?
I found, that winlogon waits for a named event Global\\UMSServicesStarted, but during setup only :( Maybe there is something, that winlogon waits always before starting LogonUI?
Maybe there is some service, that winlogon depends explicitly on...
What is the advantage of using threadpool in Hystrix?
Suppose we are calling a third party service ,when we call a service or DB that thread goes into waiting state than what is the use of keep creating thread for each call?
So,I mean how short circuited(Threadpooled) method is batter then normal(non short circuited) method?
Lets say when a remote service(any service) is started to respond slowly, but a typical application(service which is making call to remote service) will still continue to call that remote service. So short circuited(Threadpooled) method helps you build a Defensive system in this particular case.
As calling service does not know if the remote service is healthy or not and new threads are spawned every time a request comes in. This will cause threads on an already struggling server to be used.
We don’t want this to happen as we need these threads for other remote calls or processes running on our server and we also want to avoid CPU utilization spiking up. so this prevents resources from becoming blocked if latency occurs. Also Bounded thread pool also gives some breathing room for downstream services to recover.
For detail : ThreadPool in Hystrix
I am completely new to Spring and Activiti, and made myself a little Project which works just fine. there are 4 service tasks, a REST controller, 1 process, 1 service and 4 methods in this service.
When i call the server endpoint, i start my process and it just goes step by step through my service tasks and calls service.method as defined in the expression ${service.myMethod()}.
BUT, what i really need is a workflow that stops after a servicecall and waits till there is another request sent, similar to a user task waiting for input, the whole process should pause till i send a request to another endpoint.
like myurl:8080/startprocess, and maybe the next day myurl:8080/continueprocess. Maybe even save some data for continued use.
is there a simple predefined way to do this?
Best regards
You can use human tasks for that or use a "signal intermediate catching event" (see activiti´s user guide) after each ativity.
When you do that, the first rest call will start a new process instance that will execute your flow´s activities until it reaches a the signal element. When this happens, the engine saves its current state and returns control to the caller.
In order to make you flow progress, you have to send it a "signal", something you can do with an API call or using the rest API (see item 15.6.2 in the guide)
I have a Windows Service which has several timer jobs in it. In the OnStart method, I am starting all those timers. In effect, it takes a lot of time starting the service from the Services console and most of the time, it reports this:
Windows could not start the 'servicename' service on Local Computer.
The service did not repond to the start or control request in a timely fashion.
I know I could create a timer which encapsulatesthe other timers so I could start them outside the OnStart event. However, I'm looking for other possible solutions as I don't like the idea of having a separate timer which does nothing other than start the other processes.
It isn't generally safe to perform external operations such as web or database calls during OnStart, because you can't predict how long they will take, and an excessively long service startup time can interfere with the system:
The Service Control Manager (SCM) waits until the service reports a status of SERVICE_RUNNING. It is recommended that the service reports this status as quickly as possible, as other components in the system that require interaction with SCM will be blocked during this time. Some functions may require interaction with the SCM either directly or indirectly.
So the proper solution is to move this initialization into a separate thread.
However, if you don't want to do this, you can call RequestAdditionalTime:
The RequestAdditionalTime method is intended to be called by the overridden OnContinue, OnPause, OnStart, or OnStop methods to request additional time for a pending operation, to prevent the Service Control Manager (SCM) from marking the service as not responding.
I've successfully followed the Daemons and Service Guide - Creating XPC Services tutorial, along with the SandboxedFetch sample code and have a working Client / Service setup that is using the new NSXPCConnection class.
What still isn't entirely clear to me is how to properly self-terminate the service application once it has finished its job. I recognize that in many cases, the service is expected to remain alive, but in the use-case I have in mind, the service will be used to only to do some processing that I'd otherwise not perform in the main application. Once that processing is finished, there's no reason for the service application to remain. If the client needs another service at a later date, it can just re-create a new one.
Since the service is a lightweight, non-nibbed, NSApplication, I was trying to self-terminate it by calling invalidate from inside applicationWillTerminate, but that triggers an EXC_BAD_ACCESS exception almost every time. Calling invalidate on the service's [NSXPCListener serviceListener] generates slightly less reliable crashes, but it still crashes.
Calling invalidate from within the client application on its NSXPCConnection also generates an EXC_BAD_ACCESS exception almost every time.
So I'm curious what the correct sequence of steps is to cleanly shutdown the XPC service and then quit the service application. Ideally, the service would self-terminate after it has made its last XPC call to the client.
Attached is a small screenshot of what one of the exception's stacktrace looks like. (Yes, that's a webview that's loading in the service. Once the webview has finished loading, I want the service to self-terminate)
My first reaction is that you should not bother to terminate. When memory pressure occurs and your service is idle, launchd will kill your service. Exiting probably isn't in anyone's best interest because your service will take time to launch again. Don't terminate and you won't have to figure out why your attempt crashes.
But if for some reason you are determined to terminate, don't try so hard. Just do whatever you need to do to clean up (flush buffers, close network connections gracefully so the server doesn't suffer, whatever) and call exit. Although you seem to be using NSApplication, your service is not an application in any sense that the user cares about and there is no compelling reason to act like one in this respect. The host application needs to be able to cope with your service crashing anyway, so your deliberately exiting unceremoniously is just fine.
By the way, using NSApplication in an XPC service probably isn't the best idea because there's no supported way to declare that you want that. This might help explain why it isn't working as well as you'd like, though this paragraph should not be construed as a proper analysis of the crash. :-)