How do I get rid of extra runtimes?

Perl
1

Hi,

“state shell” complains I have too many runtimes, but I cannot find more than one runtime on my system. I actually don’t want to have more than one runtime. Is there a way to find what and where my runtimes are? How would I delete the extra runtime?

This is the error message I get:

C:\Users\root>state shell
Heads up! You've reached your runtime limit for <redacted>-org.
You can upgrade your plan or enroll in a free trial by visiting:
https://platform.activestate.com/upgrade/?org=<redacted>.

You are using 2 out of 1 available runtimes.

Opening shell for project <redacted>/Perl-5.36.0-Windows, located at C:\Users\root\Perl-5.36.0-Windows.
This shell is operating inside a virtual environment.
For editors and other tooling use the executables at: c:\Perl\exec.

✔ Project "<redacted>/Perl-5.36.0-Windows" Has Been Activated

Some background information:

  • I’m not new to ActivePerl and Windows admin, but I’m new to this “state” and “runtime” scheme.
  • There are two users on this PC, one for daily use, and one admin account with full permissions for system management.
  • I experimented a lot with these two users and “state”, going through several rounds of state-remote-installer.exe and state clean uninstall --all until I had Perl configured the way I wanted, owned by the admin account but accessible to both the daily and admin accounts. I’m guessing that one of these rounds left a pointer to a runtime that doesn’t really exist anymore, and that’s the problem.
  • I don’t intend to use “state” much, and I certainly don’t need to experiment with different runtimes. I may add a package from time to time, but that’s it. I use Perl for my personal needs; system management and photo library management.

Thanks for any help you can provide!

Martin

3

I see it every time I launch a shell (“state shell”), which I understand is the first thing I should do to before issuing other “state” commands. But perhaps I’m mistaken about this last statement.

Even if I don’t launch a shell, I also get the warning every time I run “state install”, “state pull”, etc.

I don’t get the warning when I run “state show”, “state use show”, “state projects”, or even “state info DateTime”.

4

Hello,

The runtimes are the average projects we have seen running for your organization and refresh that data each day, if you recently switched wait to see if you are still getting it tomorrow.

Assuming you have only set up activeState projects to run on this one system, you can use ps aux | grep activestate to try and get an idea of which other projects or instances you have running and can then stop those.

If you installed on more than one system (or it’s a public project and others my be using it) that could also be causing the warning.

Sorry for the confusion.

(i do wonder if the two different users could be contributing to the issue)

5

Hi Nicole,

Sorry for not replying sooner, I was away on vacation for several days. I can therefore safely say I haven’t used any state command (or anything else for that matter) in 5 days.

Unfortunately, I got the same warning message today when I ran “state pull” (it says my activestate.yaml is already up to date, but that’s beside the point). I rebooted, and got the same response.

This is on Windows 10 Pro. I used the Task Manager to search for ActiveState processes, and found state-svc.exe, from C:\Users\root\AppData\Local\ActiveState\StateTool\release\bin. I assume this is normal. In any case, I terminated this task and tried “state pull” again; I got the same warning.

I checked, and the other user didn’t have a state-svc task running. The other user doesn’t even have state installed anymore.
I didn’t install anything on any other system, and nobody else is using the project.

Is there a log file somewhere that would provide information on why state believes there’s more than one instance running?

I don’t mind uninstalling and reinstalling everything, if that has a reasonable chance of fixing the problem.

Thanks!

6

I have the same issue.

AciveState state has only ever been installed for one user on my computer. Over a few days prior to yesterday I removed a project and installed another several times, and ended up with none installed. Yesterday, whilst installing a new project (the only one associated with my account) I saw the heads up message ‘You are using 2 out of 1 available runtimes.’

Today, opening a Command Prompt in the project folder (containing the .yaml files), then running ‘state use’ or ‘state shell’ gives the heads up message ‘You are using 2 out of 1 available runtimes.’

I will check whether this is still the case in 24 hours or more.

I have one project for one user on Windows. As long as I can continue with that, I shall ignore the message. If I am prevented from continuing without upgrading, then (after 11 years of using ActiveState) I shall simply go elsewhere.

Until ActiveState assist further with resolving why I am seeing ‘can’t load dll’ during the compile phase when running a script (see Unusable Perl 5.36 build - compilation failures due to various dll files not loading), I have zero ActiveState projects in use.

7

So sorry it’s saying 2 when it ought to be one! Although it’s an annoying error it won’t actually block you, so if it’s only showing 1 state-svc.exe you should be just fine to ignore it and keep going. I’ll check in on our side to see if our daily re-calculations are running correctly or if there are any bugs.

8

You are correct it’s only a warning and won’t actually block you, it’s a kind of clean up reminder / warning so people do not hit a hard limit by installing and keeping active too many runtimes.

9

Thanks Nicole.

Let me know if you’d like copies of log files or anything like that. I’ll be happy to help.

10

Hi,
I just discovered there are two organizations in my account, gamin-mb and gamin-mb-org. Could this explain why state believes I have more than one runtime?
I don’t remember creating a second organization, should I remove one of the two?
Thanks

11

The -org one is an artefact of an older process to create new user organizations that we have since removed. The other one will be your permanent personal workspace/organization.
I notice that the warning is now saying you have 1 runtime, but it’s still warning that 1 < 1, which it isn’t.

If you want to remove the artefact organization, move your project to your permanent personal workspace, and send an email to support@activestate.com.

12

I notice that the warning is now saying you have 1 runtime, but it’s still warning that 1 < 1, which it isn’t.

At first, I thought you were talking about warnings appearing on my system, and wondered how you could know that. So I checked, and indeed, I no longer get the warning that I am using 2 runtimes when running commands such as ‘state pull’. So that issue seems to be fixed, even though I haven’t made any modification to my system.

But I think you were referring to the runtime usage listed on my organization page (gamin-mb-org) and, as you mentioned, it says I have “1 Concurrent Runtimes” and “This organization exceeds the usage limit of 1 concurrent runtimes for Free tier subscriptions”. Weird.

If you want to remove the artefact organization, move your project to your permanent personal workspace, and send an email to support@activestate.com

Okay. I read the documentation on how to move projects between organizations. It seems simple enough, but I wouldn’t have time right now to deal with potential permission issues or whatnot, so I’ll do it in a couple of weeks.

Thanks for your help!

13

How do I get rid of non-existing projects?

To remove the artefact organization, I moved my project to my permanent personal workspace using the instructions here: Moving your project :: ActiveState Platform Documentation.
Then, on my Windows installation, I had no valid project left (state pull said “The requested project Perl-5.36.0-Windows does not exist under gamin-mb-org”), so I checked out the moved project with state checkout gamin-mb/Perl-5.36.0-Windows --runtime-path c:/Perl. Now I have two projects, one of which (in gamin-mb-org) doesn’t exist:

  Name                                                            Organization
──────────────────────────────────────────────────────
  Perl-5.36.0-Windows                                             gamin-mb
   ├─ Local Checkout → C:\Users\root\Perl-5.36.0-Windows\Perl-5.36.0-Windows
   └─ Executables → c:\Perl\exec
  Perl-5.36.0-Windows                                             gamin-mb-org
   ├─ Local Checkout → C:\Users\root\Perl-5.36.0-Windows
   └─ Executables → c:\Perl\exec

I had so many installation and configuration issues, I’m tempted to uninstall everything related to ActiveState from my computer (while keeping my project on the platform) and reinstall from scratch. Would the following do this?

uninstall Komodo (using standard Windows tools)
state clean uninstall
manually remove all references to ActiveState from system and user PATH variables
state-remote-installer.exe
state auth
state checkout gamin-mb/Perl-5.36.0-Windows --runtime-path c:/Perl
manually add C:\Perl\bin to the system PATH
install Komodo with Komodo-IDE-12.0.1-91869.msi

Thanks!

14

Run a “state clean cache” to make sure you don’t have a cached copy of the runtimes. However, it looks like you reused the same folder for the runtimes of two different projects from two separate orgs, and clean cache will remove that folder.

To remove a project from the projects report, remove the project folder. Even after a cache clean, the project folder is preserved.

Perl/bin is not what you need on PATH. Those are non-relocated because that’s a relocatable folder. The Perl/exec folder needs to be your first entry on PATH. The old bin folder and the old site/bin folder might be needed for compatibility with old code, and in some cases you might need to add the usr/lib folder as a workaround.

15

Wow, that’s very useful information, thanks!

My installation is for a home computer with more than one user, and I had tried “state checkout” for each user, which was not the way to go, until I discovered “state checkout --runtime-path”, but I couldn’t find information on how to make C:\Perl available to all users. Your post is the first bit of information I have to make this setup work properly, so please allow me to ask a few more questions…

  1. What do you mean by “relocatable folder”?
    I know about relocatable object libraries, but the executables under Perl/bin work fine for me.
    In fact, Perl/exec isn’t even in the PATH of any user on my system. What’s the difference between the files in the exec folder and those n the bin folder?

  2. When is “AppData\Local\activestate\cache\bin” necessary? Can I get rid of it?
    Given that I want only one runtime on this system, to be installed with “state checkout --runtime-path” and shared by all users, I’m trying to keep my system clean.

  3. Is the following the correct way to clean my system and start from scratch? (all done from the admin account except where noted)
    state clean uninstall for each user on the system
    delete AppData\Local\activestate for each user (in case state clean uninstall didn’t do it)
    manually remove all references to ActiveState from system and user PATH variables
    state-remote-installer.exe
    state auth
    state checkout gamin-mb/Perl-5.36.0-Windows --runtime-path C:/Perl
    state clean cache (to remove cached runtimes, because the only one I want is in C:\Perl)
    manually add these to the system PATH (in that order): C:\Perl\site\bin;C:\Perl\usr\bin;C:\Perl\exex

  4. Is Komodo v12 sufficiently independent from the “state” command that I don’t need to worry about it when uninstalling/reinstalling Perl? (other than configuring the correct path for Perl in Komodo)

Thanks again. I know I’m asking a lot of detailed questions, but I’ve never had such a hard time installing Perl (and I’ve been doing it since Perl 4 :stuck_out_tongue_winking_eye:). I’m sure this documentation will be useful to someone else.

16

Just adding C:\Perl\exec is usually sufficient. However, instead I choose to add C:\Perl\bin; C:\Perl\site\bin and C:\Perl\usr\bin. The reason being that using C:\Perl\exec\perl.exe results in 2 perl.exe tasks per script, one for each of C:\Perl\exec\perl.exe and C:\Perl\bin\perl.exe, so any script that checks if there is an instance already running would have to filter out the additional C:\Perl\exec\perl.exe instances. That is avoided by running the script using C:\Perl\bin\perl.exe.

From the Activestate documentation:

What does the exec\perl.exe file in my project do?

Where do I add my Perl project in my PATH variable? (Windows only)

17

Starting from the bottom up:

4: Komodo is independent, so yes the configuration should be all you need to manage. Assuming that you are keeping tabs, though and know that Komodo has been both discontinued and open sourced.

3: Basically, that’s correct. You don’t necessarily need a copy of the State Tool for every user, but you probably want to keep at least one user who has the State Tool for doing updates.
What’s wrong is the PATH order. The exec folder should be at the very top of your PATH so that it has priority over all others. If not, then you’re priorizing the load of non-relocated files over ones that provide relocation information inline as you run them.

2: The folders under AppData are used by runtimes in virtual environments and by the State Tool itself. The runtimes will be under cache, and the state clean cache command will take out the parts that the State Tool itself is not using.

1: Perls are not relocatable. When they are compiled they carry pointers that link the parts together. Normally if a Perl is moved all those embedded pointers no longer line up and the Perl ceases to work.
There have been a few different strategies employed over the years to work around this fact for when Perls are installed as precompiled binaries, and even some clever ways to create Perls that can be relocated. The State Tool uses a different strategy from what the old MSI installers used.
In the old strategy, the internal pointers are overwritten permanently, meaning that the files cannot ever be moved again. The State Tool process instead depends on wrappers (in the exec folder) that set the required variables instead of overwriting. If you don’t run the wrapper, then you must not only have the PATH set correctly but must have certain dlls installed differently than how they are provided by the State Tool. It’s generally easier to just run the wrappers.

18

Great! And yes, I’m aware Komodo is now open sourced; that’s the one I’m using (v12).

That’s my intention: only the “admin” user should use the State Tool.
Actually, my having multiple instances of the State Tool is what created this thread…

Thanks for clarifying that. I thought Perl/exec replaced only Perl/bin, and I’m used to site/bin and usr/bin containing local versions of executables that are meant to override (or add to) generic/public versions. That’s why I had site and usr before exec.

Cool. I don’t plan to use virtual environments, only state checkout gamin-mb/Perl-5.36.0-Windows --runtime-path C:/Perl. So, after successful installation with that command, I will run state clean cache.

This whole paragraph was useful to understand the new need for wrappers.

By “embedded pointers”, do you mean the stuff to make XS work? Not just environment variables, right?

What do you mean by “if a Perl is moved”? Moved to another directory after installation, copied to another computer after installation, virtual environments? I’m trying to understand the use case, here.
If it matters, I used pp -M PAR with ActivePerl 5.26 to create 2 precompiled scripts for 3 other computers we use at home, and I hope to do the same with Perl 5.36. I know this is very sensitive to DLLs and locations.

Thanks a lot!

19

Oh thanks!
I searched for installation documentation and had found only the CLI docs. I don’t know how I didn’t notice the FAQ.

If the extra instance of Perl serves only to set up PATH and search variables, I understand how useful it can be to support virtual environments and multiple versions, but it seems a bit inefficient when all you need is a Perl interpreter to run scripts that are changed only from time to time by a single person. But I do appreciate the need for the ActiveState Platform to standardize how binaries are installed and supported.

20

The old way with permanent relocation makes the Perl subject to “The Rule of One”. There can be only one Perl on the system if you set it up that way, and if you forget that when you try to upgrade you’re in for a world of pain.
The State Tool exists in part to change that, so that it’s easy to switch Perls on the fly, and do development work against several versions if needed, and wrappers are far more flexible for that than binary file editors. The idea isn’t new. PerlBrew has been doing it similarly for a while, and we’ve gone a few steps further.

The embedded pointers are everything from how config_heavy is set up to strings inside the dlls or sofiles. While it’s possible to manually change all of it if you have the tools, for anyone who isn’t deep into how the Perl core operates the task is far too much to ask.

pp isn’t a compiler. It’s a packer which creates self-extracting archives, and that is a very different thing. Lots of operating systems will shut down packer files because they work on the same principles as several classes of malware, rather than how a true compiled binary behaves. Yes, placement of the dlls is important if your wrapped file needs a Perl dll.

Two notes -
We don’t attempt to be compatible with Par Packer. Given how Par works, my understanding is that the only way to be really sure you can use it is to compile your own Perl from source code locally on the system where you plan to build files with Par, and then compile the Par Packer module on that system from source code as well. Old style ActivePerls were not compatible with PAR, because the Perl building PAR was almost never exactly the same version as the one running it. Strawberry Perls were a bit more likely to have success with PAR, but it kind of has to be built at the same time as Perl even for Strawberry.

Par Packer also doesn’t remove the onus for having a license to run. A packed file containing ActiveState Perl components needs a runtime license, just a much as a non packed script running on ActiveState Perl.

21

Thanks for the explanation and advice.
I think I have enough to get rid of the extra stuff on my system (essentially to delete and reinstall), so I’ll describe below what I plan to do, and I’ll mark it as a solution once I’ve tested it. I’ll edit the post if I or you find something wrong with it, and then move on.

I will eventually try pp because it’s very useful to me and because it worked for me on multiple computers with ActivePerl 5.26. I’ll report on that much later in a different thread.

Thanks again for your patience and support; I really appreciate it, especially since I’m on a Free Tier subscription.

So here we go, my take on how to clean and reinstall a runtime of ActivePerl 5.36 in a fixed location for multiple users on a Windows 10 PC:

  1. Make sure your Perl project is ready on the ActiveState Platform, because you’ll restart from there.
    (Check the documentation for state push if you’re not sure.)
  2. Run state clean uninstall from each user account on the system (at least for every user that may have had the State Tool installed).
  3. Manually delete AppData\Local\activestate for each user (in case state clean uninstall didn’t do it).
  4. Manually remove all references to ActiveState from system and user PATH variables.
  5. Run state-remote-installer.exe from one user account, presumably an admin account that will be used to keep State and Perl up to date. The rest of this procedure must be done from this account.
  6. state auth
  7. state checkout <your ActiveState organization name>/Perl-5.36.0-Windows --runtime-path C:/Perl
    Feel free to substitute your real project name and the path where you want to install Perl.
  8. state clean cache (to remove cached runtimes, because this procedure is to install only one Perl, shared by multiple users, in C:\Perl).
  9. Manually add C:\Perl\exec to the system PATH.
    Adjust according to your Perl installation folder if necessary.
    See FAQ :: ActiveState Platform Documentation for more details

A note on PATH:
I and at least one other user successfully ran ActivePerl with other folders than Perl\exec in the PATH. There might be valid reasons to do that, but it’s not recommended, probably not supported, and it may fail at some point.