What session managers do people prefer?

What other apps and distros do you use to round out your studio?

Moderators: MattKingUSA, khz

tramp
Established Member
Posts: 2328
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 450 times

Re: What session managers do people prefer?

Post by tramp »

nils wrote: Sun Aug 28, 2022 9:40 am The original reasoning was that accepting cli arguments can introduce a conflict. You start a program with a --cli command like "start in rack mode" but then switch it, once it is running, to patchbay mode. Now the session closes and starts again later with --rack . Now what?
While that is a good argument, it didn't outperform the args pro CLI args.
There are enough extra work needed by a developer to implement NSM support, so for example avoid to allow the user to quit. For args like the one you give the example for, there could be made the same advice.
But, on the other hand, for example guitarix could make heavy usage of cli args, (And non of them is a "start in degub mode" one).
Here are the ones I really miss under NSM.

Code: Select all

  -n, --name=NAME                                                instance name (default gx_head)
  -D, --disable-multi-client                                     run guitarix as single client

  -I, --idle-timeout=SECONDS                                     starved idle thread probe (default: disabled)
  -C, --no-convolver-overload                                    disable overload on convolver missed deadline
  -W, --no-watchdog-warning                                      do not pop-up warning for bypassed overload condition
  -X, --xrun-overload                                            JACK xrun (default: false)
  -S, --sporadic=SECONDS                                         allow single overload events per interval (default: disabled)
  -N, --nogui                                                    start without GUI
  -p, --rpcport=PORT                                             start a JSON-RPC server listening on port PORT
  -H, --rpchost=HOSTNAME                                         set hostname to connect to
  -G, --onlygui                                                  start only GUI
  -L, --liveplaygui                                              start with Live Play GUI
  -E, --hideonquit                                               only hide GUI instead quit engine
  -M, --mute                                                     start with engine muted
  -b, --bank=BANK:PRESET (A:0-Z:9)                               set bank and preset to load at startup
  -t, --tuner_tet=tuner temperament (12, 19, 24, 31, 41, 53)     set tuner temperament at startup
  -F, --reference_pitch=tuner reference pitch (225 - 453)        set tuner reference pitch at startup
  --tuner-midi-feedback                                          send tuner midi feedback
On the road again.
folderol
Established Member
Posts: 2066
Joined: Mon Sep 28, 2015 8:06 pm
Location: Here, of course!
Has thanked: 223 times
Been thanked: 398 times
Contact:

Re: What session managers do people prefer?

Post by folderol »

Following on from that, in Yoshimi every possible command is available from the CLI so it can be run with no GUI at all.
It has also evolved it own session management structure, such that you load and run a complete multi-instance performance with a single command.
Beyond that most of the structure can be changed with MIDI CCs and NRPNs - including loading the first 25 stored state files.
The Yoshimi guy {apparently now an 'elderly'}
HarryR
Established Member
Posts: 30
Joined: Thu Dec 22, 2016 2:10 pm
Been thanked: 2 times

Re: What session managers do people prefer?

Post by HarryR »

nils wrote: Sun Aug 28, 2022 9:40 am > I never understand why NSM wont support CLI args.

The original reasoning was that accepting cli arguments can introduce a conflict. You start a program with a --cli command like "start in rack mode" but then switch it, once it is running, to patchbay mode. Now the session closes and starts again later with --rack . Now what? Traditionally command line arguments have higher priority than saved state (e.g. ardours safe mode starting with all plugins deactivated).
This makes the session unreliable.
I think there are a variety of pros/cons regarding NSM and CLI args.
They are all depending on what the user thinks a session is.

For me (I repeat myself) the session behavior I want is:

o Starting everything I need in a correct and reliable way
o The apps have to be started with "parameters" (the way I like it)
o No "session" data (the way NSM handles it) exist, so I can ignore them completely.

In conclusion "Ray Session" is my preference.
nils wrote: Sun Aug 28, 2022 9:40 am The example image in this thread earlier shows exactly the group of people who complain about that: Developers, starting in --debug mode.
Which example image do you mean ?

Best regards
Harry
User avatar
LAM
Established Member
Posts: 992
Joined: Thu Oct 08, 2020 3:16 pm
Has thanked: 140 times
Been thanked: 348 times

Re: What session managers do people prefer?

Post by LAM »

HarryR wrote: Mon Aug 29, 2022 11:20 am
nils wrote: Sun Aug 28, 2022 9:40 am The example image in this thread earlier shows exactly the group of people who complain about that: Developers, starting in --debug mode.
Which example image do you mean ?

Best regards
Harry
Probably this?
Image

To be clear, Mixxx is a non NSM app, I start it with the --developer argument because it's the only way to expose the internal ALSA MIDI port, necessary to run midi_for_light script, used for sending MIDI data out to visualizers/lights.

in mix, nobody can hear your screen

User avatar
Largos
Established Member
Posts: 609
Joined: Mon Oct 05, 2020 12:21 pm
Has thanked: 70 times
Been thanked: 178 times

Re: What session managers do people prefer?

Post by Largos »

HarryR wrote: Wed Aug 24, 2022 3:51 pm
LAM wrote: Wed Aug 24, 2022 3:14 pm
HarryR wrote: Wed Aug 24, 2022 2:57 pm I tried both, but what the hell, it is not possible to start applications with parameters (because the nsm protocol does not provide it !?).
In RaySession I can start applications with parameters (set in arguments field).

For what NSM compatible application you need parameters?
Bildschirmfoto_2022-08-24_17-53-12.png

Runs "standalone" without complications
Parameter is the stored carla-session-file

May be a carla problem .. I'm not satisfied :(

When you open carla in Ray Session and then save it, it creates a carla preset file (carxp extension) in the session folder. As these files are text files, you can copy paste everything from your older carla session file over the top of the new one. Re-open the Ray Session file and it will be there.

The other way to do it is copy paste the carxp file into the ray-session session folder. You would then need to change the name of the carxp file. For a continuos rack session called mysynth.carxp you change it to Carla-Rack.mysynth.carxp Then in the raysession.xml file, in between the <Clients> tags add the following line of code.

Code: Select all

<client id="mysynth" prefix_mode="1" name="Carla-Rack" launched="1" executable="carla-rack" gui_visible="1" template_origin="Carla-Rack"/>
The different types of carla session (single, multi-client) have their own prefixes and syntax in the xml file but you can open up blank examples to see what they do.
User avatar
LAM
Established Member
Posts: 992
Joined: Thu Oct 08, 2020 3:16 pm
Has thanked: 140 times
Been thanked: 348 times

Re: What session managers do people prefer?

Post by LAM »

Largos wrote: Mon Aug 29, 2022 3:09 pm When you open carla in Ray Session and then save it, it creates a carla preset file (carxp extension) in the session folder. As these files are text files, you can copy paste everything from your older carla session file over the top of the new one. Re-open the Ray Session file and it will be there.

The other way to do it is copy paste the carxp file into the ray-session session folder. You would then need to change the name of the carxp file. For a continuos rack session called mysynth.carxp you change it to Carla-Rack.mysynth.carxp Then in the raysession.xml file, in between the <Clients> tags add the following line of code.

Code: Select all

<client id="mysynth" prefix_mode="1" name="Carla-Rack" launched="1" executable="carla-rack" gui_visible="1" template_origin="Carla-Rack"/>
The different types of carla session (single, multi-client) have their own prefixes and syntax in the xml file but you can open up blank examples to see what they do.
That's a good advice, as mentioned earlier by @houston4444.

However, is not clear to me if @HarryR was expecting to have a session with:

a Carla instance able to load (arbitrary) external carxp files (non NSM); What I thought

or

a Carla instance with a specific setup contained in a carxp file (NSM).

in mix, nobody can hear your screen

User avatar
milkii
Established Member
Posts: 477
Joined: Tue Jan 05, 2016 9:08 am
Location: Edinburgh
Has thanked: 92 times
Been thanked: 91 times
Contact:

Re: What session managers do people prefer?

Post by milkii »

For arguments, just use nsm-proxy, no?

I thought, before, that the "oh hell allowing arguments would make tracking the state of the system in relation to programming/behaviour/troubleshooting a nightmare" argument was good. Is that claim more an opinionated take?
Last edited by milkii on Wed Aug 31, 2022 10:09 am, edited 2 times in total.

they/them ta / libreav.org / wiki.thingsandstuff.org/Audio and related pages / gh

nils
Established Member
Posts: 536
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: What session managers do people prefer?

Post by nils »

I want to stress the point that I was repeating in my own words what Jonathan "male", the original NSM author said as reason. Hence "original reasoning". Here is the original mail where I asked that question myself:
https://www.mail-archive.com/non@lists. ... 00446.html

My own point of view is that it is preferable that command line arguments should not be used for real NSM clients and that any configuration is made from within the program (e.g. the GUI) and saved either globally (e.g. in ~/.config) or in the session. If this is not implemented in the program the best way for the user is that this will get programmed in. It is work for the programmer, but rigid and strict session management is a good reason to do it.

That said I do not think that users are stupid and a clearly labeled and explained option for commandline arguments for NSM clients will _not_ hurt anything in reality. In this case the command line argument must be exclusive and there must be no way to override this state from within the program itself and there must be no way to edit the command line arguments ever, after adding the client to the session. This is the other side of the coin of Jonathans argument and equally true.
grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Sun Aug 28, 2022 8:20 am

@tramp, actually I agree with you.
What I say is that I understand the reasons why NSM doesn't accept arguments, but I am not agree to be so strict.

1.) you need them very very rarely -> maybe, but when you need them you need them.

That's why RaySession accepts them, with discouragements, because some people will wrongly think this is the way to load a file. But indeed, it works.

It would be very trivial to implement.

Mmmh, not sure, of course start the process with arguments is easy, one problem is that new-nsm promise session compatibility with original nsm. It requires a new session file (old NSM can't read session.nsm with a different line form than name:executable:id).

As someone who mostly takes the time to report issues for NSM clients*, this less strict approach is a concern. Devs who uses RaySession could think they could provide arguments when supporting NSM, it works in RaySession so...
You win a little, you could loose a lot with this approach imho. Looking at how many bug reports I do for NSM clients recently and over the years, this is already madness. This will only become worse when (core) developers are not taken the NSM API strictly imo. It can gets to a point when one (read me) has to conclude that session management just don't work. Or to quote @GMaq 'when is enough, enough?' ;)

RaySession less strict approach can be found in other areas as well if I'm right. It SIGKILLs clients after 2 seconds it seems, while common understanding on Unix/Linux is that SIGKILL should in general be a last resort, if it should be used at all. If I'm right, RaySession is able to cancel session operations in the middle (saw a mention about it somewhere)? No idea how that could work reliable, but I might have some misunderstanding here. Scripting options are implemented on the server side? Not sure if that's the right thing to do when taking reliability into account. But this is mostly something only RaySession users should care for or not (use whatever works for you), this doesn't affect 'non-RaySession-users' too much (SIGKILL thing could make that problems in clients will be ignored instead of being fixed = more bugs in NSM clients.)

Note I only used Raysession for a quick test, the positive thing is that it feels very snappy, something you wouldn't expect from a Python application maybe. It also closes sessions very fast, could be the disputable SIGKILL thing, if not, then it seems to does something (which I don't understand) better then nsmd, which suffers from a problem when closing some sessions, which can take > 60 sec (extreme example, nsmd fork SIGKILLs after 30 sec) to close a session cleanly. So I certainly can imagine some people prefer RaySession (I didn't even test the patchbay), but this less strict approach is a concern (for me at least), when dealing with the NSM clients side of things. Could be that I'm over concerned of course, but that's easier to say when you don't care to report issues.

Anyone else who prefers the NTK gui? 8)

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

Devs who uses RaySession could think they could provide arguments when supporting NSM, it works in RaySession so..

It is true, but not supporting arguments can be a very annoying missing feature too, for many reasons. That said, in RaySession's GUI, the fact NSM protocol doesn't supports arguments is clearly written.

It SIGKILLs clients after 2 seconds it seems

Nooo, it would be a nightmare !!! Two seconds after the SIGTERM signal has been sent to the client, the STOP button becomes red, and if user clicks on this stop button, SIGKILL is sent. Send SIGKILL automatically after 2 seconds would create JACK problems, especially at session close.

RaySession is able to cancel session operations in the middle

Yes. You can cancel the session while opening or saving it. This thing is very annoying with original NSM, when you start a session, and a client fails to load (and also fails to stop), the impossibility to cancel the session is very boring. Even without client problems, note that sometimes the user open the session by mistake, it is nice to can abort this operation directly.

the positive thing is that it feels very snappy, something you wouldn't expect from a Python application maybe.

Wooowh ! A positive thing ;)
A lot of optimization has been done for a fast startup, but it concerns more the patchbay than the session management. Python is slow, sure, but the user could feel it slow only when code is parsing a very big list (for example).

It also closes sessions very fast

I really don't see what could make the session close faster, I think it is just a feeling, client status are displayed at least 300ms to be seen by user, so, you see all status changing and never really wait (that is just a supposition).

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

houston4444 wrote: Mon Mar 27, 2023 4:48 pm

Devs who uses RaySession could think they could provide arguments when supporting NSM, it works in RaySession so..

It is true, but not supporting arguments can be a very annoying missing feature too, for many reasons. That said, in RaySession's GUI, the fact NSM protocol doesn't supports arguments is clearly written.

You're right probably not written officially in the API.

But devs can provide those option in the GUI right? Take seq192 as example, it can provide a option to turn on/off jack-transport and restore it. There is no need for supporting arguments for NSM clients. (or maybe as debug/developer mode, but then it should be clear all over.)

With your approach, you might end up with clients supported by RaySession (which supports arguments), but not by original NSM. In the case of Seq192, jack-transport is a core feature and deliberately failing to support it when under NSM (hypothetically), would cause quite a problem in the NSM ecosystem (and then it should be 'blacklisted' as NSM capable application probably).

It SIGKILLs clients after 2 seconds it seems

Nooo, it would be a nightmare !!! Two seconds after the SIGTERM signal has been sent to the client, the STOP button becomes red, and if user clicks on this stop button, SIGKILL is sent. Send SIGKILL automatically after 2 seconds would create JACK problems, especially at session close.

Ok, then I've little clue why some sessions close fluently in RaySession and not in nsmd, maybe the test session remake was not equal enough. You don't use any delays or so between the SIGTERM signals? I assumed Raysession would use SIGKILL as workaround. Saw some mentioning of it in the code.

RaySession is able to cancel session operations in the middle

Yes. You can cancel the session while opening or saving it. This thing is very annoying with original NSM, when you start a session, and a client fails to load (and also fails to stop), the impossibility to cancel the session is very boring. Even without client problems, note that sometimes the user open the session by mistake, it is nice to can abort this operation directly.

Hm ok, so RaySession only use it to abort 'open session'? But if a client fails to stop (by SIGTERM), you've to SIGKILL it right? Hm looks to me as a quite complex task to abort it during loading, not sure if it's worth it, but you've experience with it.

the positive thing is that it feels very snappy, something you wouldn't expect from a Python application maybe.

Wooowh ! A positive thing ;)
A lot of optimization has been done for a fast startup, but it concerns more the patchbay than the session management. Python is slow, sure, but the user could feel it slow only when code is parsing a very big list (for example).

Now we're at it, another positive thing is the patch you provided to nsmd I think, which let the server reply to sender. It seems to open new possibilities (or has opened another can of worms, who knows ;) ) I just never understood why you didn't provide the patch or any patch to the original non-session-manager "I'm open for patches if it fixes things and not causes new bugs", is a quote I can remember from the original author. I can remember I discussed this with you. You said nsmd had issues, but there never appeared a patch, which was available apparently.

In hindsight, I think it's also a positive thing that you've created a own project at least, with it's own name, binary names etc.

Honesty I don't see what you're doing with the session folder, why you didn't follow NSMs approach with client IDs. You're making a client folder dependent on/ linked to a session name/folder? mysession.seq192. Probably me, but I'm completely missing the point here. Why?

edit: when I rename the session to mysession_rename, the client folders name is still mysession.seq192. In the list of clients, same clients have the same name. The id, or number is only displayed in the patchbay. (There is also a bug, mysession is still listed under recent sessions, if you click it, you get a empty session. When I then open mysession_rename, all clients have status 'error'. Not sure if there are errors, clients are loaded and logs doesn't give a error. If I then duplicate it, everything seems normal).

*.xml, if you don't take the original session format, why xml and not json or yaml, text based at least which can be handled by bash?

Sure some positives, but in general I don't think I'll become a fan of the design of Raysession, sorry. :)

edit: Ok found some time to test some more and also test the patchbay. The way you can show/hide a NSM client using the patchbay is pretty neat I think (small detail: shouldn't it be single click vs double click?). It's a bit similar to what BespokeSynth is doing and that seems to work really well. In fact I think BespokeSynth might replace NSM partly for some workflows, as it provides integrated Ableton Link support and it shows (me) that a modular approach (not really bound to a traditional DAW) can work with VST/LV2 plugins. Having NSM support in BespokeSynth would give you the best of both worlds of course.

houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

But devs can provide those option in the GUI right?

Yes, in most cases. Here, seq192 has no options dialog, it could probably of course. There is also the possibility that clients have no GUI, for example think to jackpatch, if we want to add an option to not manage hardware connections, or saving multiple config depending of the used sound interface, or used computer, it would be overrated to make a GUI for this.

Here, for seq192, I think it should use jack transport by default, even if I personally use it without.

I assumed RaySession would use SIGKILL as workaround. Saw some mentioning of it in the code.

You are right, it kills clients at session close if they are still running after 30s, I think that after 30s, we can suspect the client has a real problem.

I just never understood why you didn't provide the patch or any patch to the original non-session-manager

I think you talk about this: https://github.com/jackaudio/new-sessio ... er/pull/21

I made this once new-session-manager was existing, not before, the idea was to adapt RaySession to the NSM API, but if adapt a program means reproduce the same bugs, it was a little weird. First, work on a such bugfix without any answer from the original author would have mean lose time, next, you perfectly knows what happened after, he insulted every one, me first, and the new-sm authors, he never apologized. Anyway, I did not feel like working on a deep sleep project.

Honesty I don't see what you're doing with the session folder, why you didn't follow NSMs approach with client IDs.

All of theses are parameters, prefix for client files can be SessionName, ClientName or custom prefix. The reason for use session_name is the display name for ardour session and window, or any other DAWs. The reason to not use NSM client IDs (with nXXXX), is that I find them very ugly, and generally unneeded. Note that now, add an executable will use ClientName.ClientId for files and jack client name. It is true that most client templates don't take advantage to use SessionName, they will be changed.

edit: when I rename the session to mysession_rename, the client...

Ok, this is a bug, I probably didn't think to renamed sessions while implementing recent sessions, I will investigate. If you meet other bugs, you can now post issues, I just unblock you.

*.xml, if you don't take the original session format, why xml and not json or yaml, text based at least which can be handled by bash?

I was a beginner dev when I started the soft, I didn't know yaml, and for xml vs json, I don't remember, but this choice is not a problem. I think that handle json with bash is not very safe.

The way you can show/hide a NSM client using the patchbay is pretty neat I think (small detail: shouldn't it be single click vs double click?)

No, simple click is used to move boxes.

I have to try Bespoke.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

Might be nice to be able to 'announce' the patchbay as standalone (Patchance) to other NSM servers as well. In a more modular way and use it as (part of a) session manager GUI (only for connections and show/hide for example).

houston4444 wrote: Tue Mar 28, 2023 8:43 pm

Ok, this is a bug, I probably didn't think to renamed sessions while implementing recent sessions, I will investigate. If you meet other bugs, you can now post issues, I just unblock you.

Ah unblocked. Yeah that was a firm message, but look where we are now: I can't use seq192 with jack-transport in original NSM. :? It had to be debated, nobody did it all though more people where concerned, at the end I posted a firm message to make sure the debate started, but the discussion based on arguments never came... The rest is history... Anyway, I don't want to redo the discussion and using a less firm message was maybe wiser in hindsight, I'll give you that.
But no, some might think reporting bugs is my pet-project, but it's quite the contrary. Most bugreports are a investment to prevent having to report the next bug/issue when it's already too late (and believing in the fact that if everyone does it, we'll not be hit by the same bug over and over again), but I'm not sure that is working for me... I recently tried to understand nsmd somewhat better out of interest (still like the idea/design) and reported what I noticed/learned (seemed to be fair) for archiving purposes and whoever wants to do something with it, now or in the future, but no not something I enjoy. I also was interested if Raysession has the same issue as nsmd (some sessions which takes a unreasonable long time to close, but still didn't figure out what RaySession does better here...). In meantime I've a suckless Curses like GUI prototype under my fingers (that's my personal pet-project I guess), so I'm not seeing me switching to RaySession for various reasons, but yeah I see such a patchbay certainly working (more or less similar to bespoke maybe), all though it's quite different from what I tend to believe in, a more suckless simple stupid modular road (quite the contrary of a integrated patchbay). And yes, NSM clients which support arguments will hit my current workflow. That's why I thought it would be wise to mention it here at least. The idea that things like this can change and hit a already fragile environment in terms of compatibility and reliability on the client side, along with other reasons which are not too hard to guess, are not a real invitation for me to invest too much energy in this environment anymore with bugreporting and such tbh. Thanks to the modular DAW/synth Bespoke I might even become a plugin believer, if such environments are easier to handle, all though I also saw a crash counter... Ouch. Best of both worlds will still be the ideal of course.

grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: What session managers do people prefer?

Post by grammo »

grammo wrote: Wed Mar 29, 2023 12:15 am

In meantime I've a suckless Curses like GUI prototype under my fingers

To be more precise, after the fork I decided to be less dependent on others and pure out of interest and as a(nother) attempt to learn some programming myself in a field where my interest is, I did quite some prototyping with modular solutions, more or less trying to see if modular solutions for adding extra functionality to a session manager as suggested by Jonathan, could work (and simple modular tools are good for a newbie programmer). E.g. adding more NSM functionality doesn't mean you've to add anything to the Non-Session-Manager Gui itself (granted the patch for forked nsmd by Houston444 helps quite a bit with this).
Besides fiddling with Curses like applications (which GUIs are not really suited to add arguments in, bit the same as the original non-session-manager gui), this also means that I'm currently launching NSM clients from dmenu* with a launcher. With such a approach I see passing arguments to NSM clients also as a regression, at least I don't see how I could make this work as easily as I have it now. I'm sure it could work, but it will add quite some extra complexity I think which one rather avoids. No plans to release anything anywhere soon, nor later, but probably good to share these thoughts anyway now, because such a workflow could be well suited for use with something like NSM of course and should at least taken into consideration (very seriously) imo.

  • without NSM_URL set early in the environment, cause then pid management, which I think/learned session management should rely on as less as possible, is less reliable (in theory at least).
houston4444
Established Member
Posts: 78
Joined: Mon Apr 02, 2018 6:53 pm
Has thanked: 3 times
Been thanked: 25 times

Re: What session managers do people prefer?

Post by houston4444 »

Might be nice to be able to 'announce' the patchbay as standalone (Patchance) to other NSM servers as well

I considered this solution before to develop the patchbay (patchbay as NSM client), but there are big disadvantages:

  • The patchbay is not available when no session is loaded
  • Impossible to make relations between JACK clients and NSM clients (it should be possible now with ':monitor:' capability).

look where we are now: I can't use seq192 with jack-transport in original NSM.

What is ironic here, is that (I am pretty sure) jean-emmanuel would not have added NSM support to seq192 if RaySession didn't accept arguments. For its use, accept arguments is not a feature, it is just a base condition.

without NSM_URL set early in the environment, cause then pid management, which I think/learned session management should rely on as less as possible, is less reliable (in theory at least).

I did not understand this sentence

Locked