The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


Q&A: How do I Enforce a Single Instance of my Python Script with AlwaysUp?

How do I enforce a single instance of my Python app with AlwaysUp?
  Hi,

I am trying the 30 day demo to see if AlwaysUp works for my application. I am running a couple of python scripts and so far your application works perfectly. I do however have an issue. It is critical that only one instance of my application runs when I run it from the command line my mutex works as it should.

My code looks like this:

Python code to manage a mutex

I am able to run a second instance from a command line. This will cause some serious misreporting if two applications are running. Is there anything I can do?

Thanks.

— Carl

Hi Carl, thanks for trying AlwaysUp. Thanks also for sending your code, which enabled us to identify the problem quickly. It has to do with how mutex locks work.

Your mutex isn’t visible across sessions

By default, mutexes have “session scope”. That is, they exist only in the login session where they were created. And that has important consequences.

For example, let’s say that Alice logs in to a computer. Obviously, she can start a copy of your Python script just fine. But when Alice attempts to launch a second copy, it fails — exactly as you’ve designed.

Now let’s say that Bill logs into his account on the same computer. Like Alice, he will be able to start only a single copy of your script.

But there will now be two instances of your Python script running on the PC — one for Alice and one for Bill. That’s probably not what you want, right?

In summary, your current single-instance enforcement mechanism will actually allow multiple copies because your application creates a different mutex in each login session.

Now, let’s review why that’s important when running your Python script as a Windows Service.

AlwaysUp runs your application in a different session

To start your Python script at boot, AlwaysUp runs it in the background in the isolated Session 0.

And when you log into your computer, Windows creates a new session for you — Session 1, 2, or 3, etc.

You’re able to “run a second instance from a command line” because the mutex doesn’t do its job across the two sessions.

Use a Global mutex to restrict all instances of your app

Fortunately the fix is simple. Give our mutex a “global scope” so that it applies across all login sessions.

Indeed, all you have to do is prefix the name of your mutex with “Global\” (no quotes). It’s a one-line update to your code, like this:

self.mutexname = app_name + “Global\_mutex_{eaf8379e-5231-412c-92da-a0328eacea9e}”

For additional context, check out Microsoft’s description of the situation in their technical documentation on mutex objects:

 On a server that is running Terminal Services, a named system mutex can have two levels of visibility. If its name begins with the prefix Global\, the mutex is visible in all terminal server sessions. If its name begins with the prefix Local\, the mutex is visible only in the terminal server session where it was created. In that case, a separate mutex with the same name can exist in each of the other terminal server sessions on the server. If you do not specify a prefix when you create a named mutex, it takes the prefix Local\. Within a terminal server session, two mutexes whose names differ only by their prefixes are separate mutexes, and both are visible to all processes in the terminal server session. That is, the prefix names Global\ and Local\ describe the scope of the mutex name relative to terminal server sessions, not relative to processes.

Hopefully that all makes sense now.

Please get in touch if you have any other questions running your Python scripts as Windows Services.

Posted in AlwaysUp | Tagged , , , , , | Leave a comment

Service Protector 9.5 Helps You Bulletproof Your Network Services

Service Protector 9.5: Network Connection Sanity Check

Service Protector 9.5 out!

As usual, we focused on improving the software to help your Windows Services achieve 100% uptime — even in the face of failures. Here are the highlights:

Advanced safeguards for your network-aware Windows Services

Are you responsible for a service that communicates over the network?

Or are you running a TCP/IP server that accepts connections from other devices?

What happens if your service cannot communicate with its clients?

If the result is catastrophe, then you should deploy our new “check network connections” sanity check, to automatically restart your service if it experiences a networking failure.

How the “check network connections” sanity check works

The new sanity check periodically scans your service for network connections, much like Microsoft’s TCPView utility does. And if it doesn’t find any network connections, Service Protector stops and restarts your service — to give it the opportunity to reestablish connectivity.

Moreover, Service Protector can alert you by email whenever the network check fails. The message will include details of what went wrong, like this:

You'll get an email alert when the check fails

How to activate the “check network connections” sanity check

It’s very easy to activate the new sanity check. Indeed, you should be up and running in a couple minutes (or less).

Here are the steps to set it up:

  1. Edit your entry in Service Protector.

  2. Go to the Monitor tab, check the Whenever it fails a periodic sanity check box and click the Set button:

    Set the sanity check
  3. In the Add Sanity Check window, choose Check that your service has active network connections from the list and click Next to continue:

    Choose check network connections
  4. Next, refine what the sanity check should investigate. For example, if your service must always be listening for requests from clients, check the Fail if there are no listening/server connections box:

    Set sanity check options
  5. Click Next to continue.

    At this point, you get to decide how often Service Protector must check your service. Every 5 minutes works for us but you should tune the settings for your unique situation:

    Set the sanity check frequency
  6. Finally, after clicking Next to move on, Service Protector will show a summary of your new sanity check. Confirm the details and click Add to record it:

    Set the sanity check frequency

And that’s it. With the new watchdog in place, Service protector will interrogate your service every few minutes (as directed) and promptly restart it if there are no network connections.

At the end of the day, your customers will thank you for providing a more stable service. But even better, no one will interrupt you at home to ask you to recycle buggy software. 🙂

Get full support for monitoring “Automatic (Delayed Start)” services

Service Protector is pretty aggressive about ensuring that your service is always running. For example, whenever Service Protector finds that your service is idle, it restarts it within a few seconds.

However, in it’s zeal to ensure 100% uptime, Service Protector went too far in one scenario.

Consider a Windows Service with startup type set to “Automatic (Delayed Start)”. Instead of starting it immediately at boot, Windows will launch the service 1-2 minutes after boot. And that brief delay may be a desirable because it increases the likelihood that all the critical infrastructure (e.g. networking and security) will be in place before the service starts.

Unfortunately, earlier versions of Service Protector didn’t respect the “Automatic (Delayed Start)” option. As soon as it saw that the service wasn’t running, Service Protector would start it. In essence, the service would start running a few seconds after boot — before supporting modules were ready. Oops.

Service Protector 9.5 fixes the problem. Now when babysitting a delayed service, Service Protector will give Windows a chance to launch the service before it starts monitoring it.

Bu rest assured — if your delayed service fails to start (or terminates after launch), Service Protector will detect it and promptly take action. That’s because the new relaxations around delayed services only apply in the first few minutes of the boot process.

Other fixes & improvements

  • Revamped the code to improve efficiency when checking the status of a service. The changes are very technical and we won’t get into them here, but the result is a 10-25% speedup in some of our tests.

  • To better serve our customers, we improved internal logging throughout the program. The extra messages give us much better insight into what’s going on when we’re troubleshooting mysterious operating system and permissions issues.

  • Windows shutdown can be frenzied, with components being notified and often exiting in random sequence. Service Protector 9.5 does a better job at shutdown, to eliminate unnecessary restarts and emails as the operating system closes.

As usual, please review the release notes for the full list of features, fixes and improvements included in Service Protector version 9.5.

Upgrading to Service Protector 9.5

If you purchased Service Protector version 8 (after November 2021), you can upgrade to version 9.5 for free. Simply download and install over your existing installation to preserve your existing services and all settings. That way, your registration code will continue to work.

If you bought Service Protector 7 or earlier (before November 2021), you will need to upgrade to use version 9.5.

Please buy upgrades here — at a 50% discount.

See the complete upgrade policy for more details.

Enjoy!

Posted in Service Protector | Tagged , , , , , , | Leave a comment


Get Enhanced Authentication Controls & Improved Security with AlwaysUp Web Service 14.7

AlwaysUp Web Service 14.7: Session Controls & Improved Security

AlwaysUp Web Service version 14.7 was released on October 1 2023.

This time around, our team focused on improving the software in a couple of areas — to give you greater control over authentication and to improve security.

New authentication and session timeout options

Authentication was mandatory in previous versions of AlwaysUp Web Service. You were forced to enter a password before interacting with your AlwaysUp applications in the browser.

But while protecting the web service is the right approach for the vast majority of our customers, we also heard that having to constantly log in was a nuisance. And introducing an additional layer of authentication was unnecessary when access to the web service URL was already restricted by another gating mechanism (such as network isolation or IP filtering).

So, to help customers who weren’t happy with the current system, we introduced the following enhancements.

  1. Authentication is optional.

    You can now avoid logging in to access the web service.

  2. The session timeout is configurable.

    You can now set the web session timeout value to up to 24 hours, to have the web service keep you logged in even when you’ve been idle for a long time.

The new options are available on the Settings page in AlwaysUp Web Service Control Panel:

AlwaysUp Web Service Control Panel: Authentication Settings

Of course, please think carefully before relaxing security in your environment. We recommend sticking with the defaults (password required; session timeout of 30 minutes) unless you have good reasons to change them. Caveat emptor!

Protection against known vulnerabilities

As a web application that might be available on the Internet, it’s important for AlwaysUp Web Service to be as secure as possible. Indeed, it must resist the thousands of malicious actors and bots that are constantly probing network ports, trying to hijack computers.

We apply security updates regularly, to keep AlwaysUp Web Service ahead of the attackers. In this release, we:

  1. Introduced support for TLS 1.3.

    The latest version of the TLS protocol — which strengthens encrypted SSL connections — ensures that your data is always secure in transit.

  2. Dropped support for TLS 1.1 and earlier.

    Unfortunately those older protocols are no longer secure. Even Microsoft started disabling them in September 2023.

And with those improvements in place, AlwaysUp Web Service received an A+ grade from ImmuniWeb’s popular SSL Security test:

ImmuniWeb SSL Security test results

The full report (PDF) is available here.

Additional enhancements

As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp Web Service version 14.7.

Enjoy!

Posted in AlwaysUp Web Service | Tagged , , , , | Leave a comment

Windows Services Startup Types Explained

Windows Services Startup Types Explained

What is a service’s Startup Type? Where do I find it?

A Windows Service is a special application whose lifecycle is managed by the operating system. That is, unlike a “normal” application that relies on a person to start or stop it, Windows itself is responsible for starting, stopping or restarting a service.

To give you some control over how things work, each Windows Service has a startup type property that dictates how Windows should manage it. The options range from “start it as soon as you can” to “don’t run the service at all”. There’s even the ability to start a service when certain conditions are met. But more on those later as we dig into each of the startup types below.

The built-in Services application shows the startup type for each service. You can launch the application by typing “services” into the search bar and clicking its icon:

Start Services from the search bar

The Services window lists all the Windows Services running on your computer. The “Startup Type” column indicates how each service is configured to start:

Services: The Startup Type column

Double-click a row to reveal the details of that service in the Properties window. You’ll see the “Startup type” field about half-way down:

Service properties: The startup type field

If permissions allow, you can change the startup type right there as well. Simply choose a new value from the list and click OK (or Apply) to record your change:

Changing the Startup Type

And now that you know how to find the startup type of any service, let’s review the values available and what each of them means.


Automatic

When a service is set to “Automatic”, Windows will start it as soon as possible whenever the system boots.

Because of that early start, all critical Windows Services — like those supporting networking, security and user management — are set to start automatically. That enables them to come to life quickly, to support key functionality across your computer.

When to set startup type to “Automatic”

Automatic start is best for services that:

  • Implement technical functions that are vital for the operation of your PC;

  • Are needed to support other services or applications;

  • Must run all the time.

Examples of “Automatic” services

Many of the built-in Windows Services are set to start automatically. Here are a few examples:

  • Windows Defender Firewall — helps protect your computer by preventing unauthorized users from gaining access to your computer through the Internet or a network. This service must be ready by the time the network is up.

  • Local Session Manager — a core Windows Service that manages local user sessions. Stopping or disabling this service will result in system instability.

  • Windows Event Log — manages events and event logs for other services. Stopping this service may compromise the security and reliability of the system.


Automatic (Delayed Start)

Windows launches “Automatic (Delayed Start)” services about 1-2 minutes after your computer boots — after Automatic services have started.

You can think of Windows launching services in two rounds at boot. Automatic services go in the first round while “Automatic (Delayed Start)” services are kicked off in the second round.

As such, the “Automatic (Delayed Start)” setting is most useful in lessening the mad rush for resources when your computer starts up.

For example, suppose that there are 20 services all being started at the same time. In reality, they will all be competing for slices of the machine’s precious resources (CPU/RAM/Disk/Network). The inevitable result is that each service will take longer to become available.

If you have a few services that are critical, then you may want to set those few to “Automatic” and set as many of the others as you can to “Automatic (Delayed Start)”. This will ensure that the critical services get the most resources early and become available sooner, while the non-critical services start a bit later (which by definition is OK).

When to set startup type to “Automatic (Delayed Start)”

“Automatic (Delayed Start)” is best for services that:

  • Should start at boot but don’t perform mission-critical activities;

  • Are best started after supporting services are up and running;

  • Should run all the time.

Examples of “Automatic (Delayed Start)” services

On Windows 11, less than a dozen of the built-in Windows Services are set to start delayed. Here are a few examples:

  • Security Center — monitors and reports security health settings on the computer. This service should run all the time but there is no need to start it ASAP because it’s focused on reporting.

  • Update Orchestrator Service — manages Windows Updates. If stopped, your computer will not be able to download and install the latest updates. Since it’s not a critical service, Windows starts it in the second round.

  • Dropbox Update Service — keeps your Dropbox installations up to date. The service is certainly helpful but it doesn’t need to start the instant your PC reboots.


Manual

A “Manual” service isn’t automatically started by Windows at boot. Instead, it will be started on demand — either by a user or by an application.

For the most part, “Manual” services sit idle until they’re needed. And often, they return to an idle state once they’ve performed the work they were summoned to do. As such, they tend to be the most efficient group of services, only running when they need to.

Note that in previous versions of Windows, the vast majority of services were set to “Automatic” and only a handful were “Manual”. But over the years, as Microsoft focused on streamlining the boot process, the situation has fully reversed. Most of the built-in Windows Services are now started on demand!

When to set startup type to “Manual”

The “Manual” startup type is appropriate for services that:

  • Don’t need to run 24/7;

  • Are only used occasionally;

  • Provide uncommon functionality that only some devices (or users) will need;

  • Aim to achieve maximum efficiency, only running when necessary;

Examples of “Manual” services

Many of the built-in Windows Services are set to “Manual”. Here are a few examples:

  • Windows Backup — provides backup and restore capabilities, which are only necessary at defined times.

  • Fax Service — enables you to send and receive faxes. Who uses that anymore? 🙂

  • Microsoft Edge Elevation Service — keeps Microsoft Edge up to date. This service only comes to life a few times per day.


Disabled

Setting the startup type to “Disabled” tells Windows don’t allow the service to start — under any circumstances. You cannot run a disabled service.

If you wish to start a disabled service, you must first change its startup type to another value. Setting to “Manual” usually makes the most sense.

When to set startup type to “Disabled”

You should disable services that:

  • Shouldn’t (or cannot) run;

  • Are responsible for unused functionality;

  • Are insecure and may compromise the system in some fashion.

Examples of “Disabled” services

Here are a few examples of services with startup type set to “Disabled”:

  • Shared PC Account Manager — Manages profiles and accounts on a SharedPC configured device. It’s disabled on our machine because we’re not using the SharedPC feature.

  • OpenSSH Authentication Agent — holds private keys used for public key authentication. Citing security concerns, Microsoft disables this rarely used service in new installations of Windows 10 & 11.

  • Remote Registry — enables remote users to modify registry settings on this computer. Certainly not for everyone!


Intermission: What does “Trigger Start” mean?

Because the remaining startup types all mention “Trigger Start”, we thought this would be a good time to explain what that means. Here goes…

In older versions of Windows, the only startup types available were the ones we’ve already reviewed — Automatic, Automatic (Delayed Start), Manual and Disabled. Each service was assigned one of those values. (Incidentally, most were set to “Automatic”, which made for utter chaos as they all scrambled to start at boot.)

However, in Windows 7 (circa 2009), Microsoft introduced a new capability — the ability to start (or stop) a service when a key operating system event occurs. They called those events triggers and services that react to the events trigger start services.

Putting it all together, a service has “Trigger Start” in its startup type if it has at least one trigger.

But why did Microsoft introduce trigger start services?

Well, by offering trigger start as an option, Microsoft made it easier for Windows Services to avoid starting at boot and running 24/7. For example, if your service works with USB drives, you can configure it to start whenever someone inserts a USB drive. Similarly, a network-monitoring service may choose to run only when your computer signs out of a domain or leaves the network. Options abound, and you can read about the technical details in the Developing Efficient Background Processes for Windows white paper.

So service triggers are great. But there is one major inconvenience…

You can’t view or edit triggers with the Services application

Until Microsoft updates the Services application to manage triggers, you either have to:

  1. rely on the Windows SC command-line program, or

  2. use our free Service Trigger Editor GUI utility, which shows you all the trigger start services on your system:

Service Trigger Editor managing trigger start services

Anyway, back to startup types…


Automatic (Trigger Start)

“Automatic (Trigger Start)” means start the service immediately at boot — and also restart it whenever specific operating system events (triggers) occur.

It’s the same as Automatic, plus with one or more triggers too.

As a result, an “Automatic (Trigger Start)” service can be very efficient. Even though Windows starts it as soon as possible, the service can do its initial work and quickly exit — secure in the knowledge that Windows will fire it up again whenever it’s needed.

When to set startup type to “Automatic (Trigger Start)”

“Automatic (Trigger Start)” start works best for services that:

  • Should to start as soon as possible after boot;

  • Don’t need to run all the time;

  • Can be reactivated by a triggering event.

Examples of “Automatic (Trigger Start)” services

On our Windows 11 computer, only six services are set to “Automatic (Trigger Start)”. Here are a few of them:

  • Server — supports file, print, and named-pipe sharing over the network. As you might expect, the two triggers are network-related:

    Triggers for the Server Windows Service
  • Windows Connection Manager — makes automatic connect/disconnect decisions based on the network connectivity options currently available to the PC and enables management of network connectivity based on Group Policy settings.

  • Group Policy Client — responsible for applying settings configured by administrators for the computer and users through the Group Policy component.


Automatic (Delayed Start, Trigger Start)

An “Automatic (Delayed Start, Trigger Start)” service starts a few minutes after boot — and also in response to a trigger.

As you may have guessed, “Automatic (Delayed Start, Trigger Start)” is similar to Automatic (Trigger Start), except that the service starts 1-2 minutes after boot (instead of ASAP).

When to set startup type to “Automatic (Delayed Start, Trigger Start)”

“Automatic (Delayed Start, Trigger Start)” can apply to services that:

  • Should to start at boot but can wait for a couple of minutes;

  • Don’t need to run all the time;

  • Can be reactivated by a triggering event.

Examples of “Automatic (Delayed Start, Trigger Start)” services

Few of the built-in Windows Services use this startup type. Here are three examples:

  • Microsoft Edge Update Service — keeps your Microsoft software up to date.

  • Software Protection — enables the download, installation and enforcement of digital licenses for Windows and Windows applications.

  • Windows Time — maintains date and time synchronization on all clients and servers in the network. Because it’s all about networking, the service will trigger-start when your computer joins a domain:

    The Windows Time domain service trigger

Manual (Trigger Start)

Windows never starts a “Manual (Trigger Start)” service at boot. It only starts the service in response to a trigger.

This is the most efficient startup type of them all. Windows only starts the service when its needed.

When to set startup type to Manual (Trigger Start)

“Manual (Trigger Start)” is a fine choice for services that:

  • Don’t need to start at boot;

  • Don’t need to run all the time;

  • Can be reactivated by a triggering event.

Examples of Manual (Trigger Start) services

“Manual (Trigger Start)” is the most popular startup type on our Windows 11 computer. That’s a testament to the work that Microsoft has put in to ensure that its services don’t hog resources by running when they don’t need to.

Example services include:

  • BitLocker Drive Encryption Service — provides secure startup for the operating system, as well as full volume encryption for OS, fixed or removable volumes. It only needs to run under special conditions (when a custom event is triggered).

  • Windows Update — enables the detection, download, and installation of updates for Windows and other programs. As you can see, the service will spring to life whenever a policy changes:

    Windows Update service policy triggers
  • Portable Device Enumerator Service — enforces group policy for removable mass-storage devices. It employs a dozen triggers!

    Portable Device Enumerator Service triggers

Windows Service startup types: Summary

To recap, the startup type tells Windows how it should start your service.

Here is what each value communicates to the operating system:

  • Automatic: “Start this service at boot, early in the cycle.”

  • Automatic (Delayed Start): “Start this service at boot, but delay it by a couple of minutes.”

  • Manual: “Don’t start this service at boot.”

  • Disabled: “Don’t start this service at boot, and don’t allow anyone (or any program) to start it either.”

  • Automatic (Trigger Start): “Start this service early in the boot cycle and start/stop it when specific events occur.”

  • Automatic (Delayed Start, Trigger Start): “Start this service a couple of minutes after boot and start/stop it when specific events occur.”

  • Manual (Trigger Start): “Don’t start this service at boot, only start/stop it when specific events occur.”

Posted in Windows Services | Tagged , , , , , , , , , , , | Leave a comment