AlwaysUp has been invaluable to our business, which is why I’ve bought several copies for different machines.
Recently I started running into a problem on my production PC. I searched for a bit through your FAQs and blogs but didn’t see this particular problem. Maybe you have a quick workaround?
But sometimes the G: drive disappears after a while, even though AlwaysUp shows Google Drive running.
When that happens, my application goes haywire. Eventually, I’ll have to debug to keep the app from crashing when the G drive is not available, but in the meantime, do you have an answer for what’s happening?
I will appreciate any help you can provide.
— Randy
Hi Randy, thanks for reaching out to report the problem. No one on our team has seen Google Drive failing as you described so we can’t say precisely what going on, sorry.
But we can offer a couple of solutions that should (1) lessen the occurrence of the problem and (2) quickly restore functionality when the problem arises.
Solution #1: Have AlwaysUp restart Google Drive every night
If Drive breaks after it’s been running for some time, the program may have a resource leak.
Perhaps Drive isn’t freeing all the RAM it’s requested. Or it may be holding on to a network port for too long. Or it could be something else. It’s difficult to pinpoint the issue because we don’t have access to the source code (or to decent log files, for that matter).
For mysterious situations like this, we recommend introducing a nightly restart. That is, you should have AlwaysUp automatically restart Google Drive at a set time when no one is likely to be using it.
The theory is that restarting Google Drive will clear out any resource leaks. Afterwards, the program will come up “fresh” and ready to do its work — at least for the next few hours.
To restart Drive nightly:
Edit Google Drive in AlwaysUp (select Application > Edit/View “Google Drive for desktop” from the menu).
In the Edit/View Application window that comes up, switch to the Monitor tab.
Check the Every box, select Day from the drop-down and choose a convenient time to restart Google Drive. 2 AM works for us:
Save your changes.
With that setting in place, AlwaysUp will restart Drive every night at 2 AM. And as a result, no instance of Drive will run for longer than a day. If we’re lucky, no resource leak will grow fast enough to cripple Drive within those 24 hours.
But if we’re not dealing with a resource leak and Drive can stop working at any time, a nightly restart won’t help much. Fortunately, the next solution tackles the problem more directly.
Solution #2: Install a sanity check to detect the failure and automatically restart Google Drive
We built AlwaysUp to handle a range of failures while running an application. For example, AlwaysUp can detect and automatically recycle programs that:
Use too much memory;
Run wild with the CPU;
Get stuck at a crash window;
Become unresponsive to input.
For those cases, you simply specify the restrictions (e.g. the maximum RAM to use) and AlwaysUp will deal with any violations on your behalf.
But none of those built-in capabilities will help with your Google Drive problem. When Drive fails, it’s not related to CPU, RAM or any of the metrics that AlwaysUp tracks. It’s about knowing when your G drive isn’t mapped.
To handle non-standard failures like yours, we must rely on AlwaysUp’s Sanity Check feature. We’ll write a batch file that detects when the G drive isn’t mapped and then show you how to plug that into AlwaysUp.
Download our sanity check to detect when your G drive isn’t available
Here is the batch file we developed for your situation:
@echooff:: This batch file checks if a drive letter is mapped or not.:: It exits with 0 if the drive is mapped and 1 if it isn't.SETgdrive=G
ifexist%gdrive%:\ (
echo The %gdrive% drive is mapped Exiting with 0 to continue running.
exit /b 0
)
echo The %gdrive% drive is NOT mapped. Exiting with 1 to restart.
exit /b 1
As you can see, it simply checks if the G:\ folder exists and returns:
0 if G:\ is accessible
1 if G:\ cannot be accessed
Please download the script and save it in a known location on your computer running Google Drive. We’ll use it in the next step.
Plug the sanity check into AlwaysUp
Since we have a batch file to detect the problem, let’s tell AlwaysUp how to use it:
Edit Google Drive in AlwaysUp (select Application > Edit/View “Google Drive for desktop” from the menu).
In the Edit/View Application window that comes up, switch to the Monitor tab.
Check the Whenever it fails a “sanity check” box and click the … button:
In the Configure Sanity Check window that comes up, enter the full path to the batch file in the Run field and specify how often to perform the sanity check. Every 5 minutes should be enough so that’s what we entered:
Save your changes.
And with that sanity check in place, AlwaysUp will run the batch file every 5 minutes. If the batch file returns 0, indicating that the G drive is available, nothing will happen. AlwaysUp will continue to babysit Google Drive (and schedule the next check for 5 minutes later).
But if the batch file returns 1 — because it couldn’t access the G drive — AlwaysUp will promptly shut down Google Drive and start a new copy. Doing so should restore access to the G drive.
Posted onDecember 17, 2023 (Revised January 4, 2024)
Our team released AlwaysUp version 15 on December 8 — just in time for the holidays. 🙂
This time, we focused on making AlwaysUp better at identifying technical problems and providing excellent support when things don’t go as expected. Here are a few highlights:
AlwaysUp now collects helpful application diagnostics — so you don’t have to
Most customers have AlwaysUp installed and running their application as a Windows Service in a few minutes. But sometimes things get tricky and you need assistance from our excellent support team.
Starting in version 15, AlwaysUp will collect all the information on your behalf. Simply select Advanced > Collect Diagnostic Information to bring up the step-by-step wizard (shown here interrogating OneDrive):
Click Next and in a few seconds AlwaysUp will deliver text describing your setup:
Save the text to a file (or copy it to the clipboard) and include it in an email to our technical support team. Easy peasy!
Find out more about this convenient, time-saving feature on the application diagnostics page.
Introducing advanced monitoring for popular applications: Dropbox, OneDrive and Google Drive
To provide a better experience for those customers, AlwaysUp 15 includes code that works closely with those applications to detect (and shout) when things go awry.
For example, AlwaysUp will now warn you if OneDrive is showing an unrecognized prompt. We bring that to your attention because it might mean that OneDrive is stuck waiting for your input and isn’t synchronizing your files:
We plan to build on this comprehensive detection framework in future releases — to reduce the number of headaches in your life.
Running an unstable application? Configure hourly restarts to keep it “fresh”
If you’re working with an application that can barely stay healthy for 60 minutes, you have our sympathies!
But even more than that, you now have a way to safely restart the application every hour — at the minute of your choosing.
The new “Every Hour” option is available for selection on the Monitor tab:
Other fixes & improvements
Windows shutdown is unpredictable and often chaotic. In fact, applications can be terminated in random order, so you’re never quite sure how things will unfold.
This version of AlwaysUp makes use of technical mechanisms to inform Windows what’s going on at system shutdown. And that can make a significant difference for applications that take a while to exit gracefully.
The Application Advisor — which makes it easy to set up a dozen popular applications as Windows Services — got smarter when installing OneDrive. A new two-minute restart delay tolerates unpredictable automatic updates, while a new shutdown command ensures that OneDrive closes smoothly when exiting.
We fixed a problem where an application with unusual characters in its name couldn’t write records to the Windows Event Logs.
As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 15.
Upgrading to AlwaysUp 15
If you purchased AlwaysUp version 14 (after November 2022), you can upgrade to version 15 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well.
If you bought AlwaysUp version 13 or earlier (before November 2022), you will need to upgrade to use version 15. Consequently, please purchase upgrades here — at a 50% discount.
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:
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:
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.
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:
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:
Edit your entry in Service Protector.
Go to the Monitor tab, check the Whenever it fails a periodic sanity check box and click the Set button:
In the Add Sanity Check window, choose Check that your service has active network connections from the list and click Next to continue:
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:
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:
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:
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.
It is possible to protect AlwaysUp by password to prevent unauthorized change of settings or unauthorized intervention?
— Tomáš
Hi Tomáš, thanks for getting in touch.
I can tell you that safety and security are front and center as we develop AlwaysUp. Indeed, here are a couple of ways that AlwaysUp helps to protect your applications from unauthorized changes.
Only Administrators can run AlwaysUp
First, only users who have admin rights can start AlwaysUp. That’s because AlwaysUp is installed as a User Account Control (UAC) administrative utility that requires elevated rights to run.
No doubt you’ve already noticed the UAC restrictions in play. For example, they greet you with a protective prompt whenever you start AlwaysUp on Windows 11:
If you click “No”, AlwaysUp will not start.
Note that non-administrators see a different prompt. Instead of simply having to acknowledge elevation, those users must enter the user name and password of an administrator to continue:
So that’s the general security in place. Next, we’ll review how you can protect individual applications you’ve deployed with AlwaysUp.
Restrict access to the Windows Services that AlwaysUp creates
For each application you add, AlwaysUp installs a Windows Service to manage it. Indeed, you can see those AlwaysUp-created services in the Services application.
And because they are “true” Windows Services, Microsoft’s robust permissions system extends to the entities created by AlwaysUp. You can manage them like any other service, setting exactly who can start, stop or edit them.
So, to set the permissions for your AlwaysUp application/service:
If your application is running in AlwaysUp, stop it now. You can update permissions only when the service is idle.
Highlight your application and select Application > Advanced > Service Security Settings:
The Service Security Settings window shows all the users and groups with rights over the service that AlwaysUp created. For example, you’ll likely find that anyone in the built-in Administrators group has full control:
Adjust the service’s permissions as you see fit.
For example, to prevent someone from updating or deleting the service:
Click the Add button and add that person to the top panel. We’ve selected “Hazel Smith” on our computer; she currently has full rights to the service (inherited from the Administrators group):
In the lower panel, check the Modify and Delete boxes in the Deny column:
Click OK to record your changes.
With your updated restrictions in place, the users who you have denied access to the service won’t be able to change your application in AlwaysUp.
For example, if Hazel tries to update our OneDrive entry in AlwaysUp, the attempt to save fails with an “Access denied” error:
Hopefully, you will be good to go after adjusting permissions. But a note of caution…
Please be careful when updating service permissions!
You don’t want to lock yourself out.
Pay particular attention when adjusting the rights of groups. Because “Deny” rights take precedence over “Allow” rights, you will strip away your own rights if you block a group that you’re a member of. And once you block your own account, you won’t be able to restore your rights without help.
If you do make a mistake, look to our Service Security Editor program to help you fix the problem. And this article offers a few troubleshooting tips.
(888) 881-CORE
Hi, Core Technologies support team.
