NSM announce pid

[grammoboy2]

It's interesting that you created a terminal application that works with NSM, I didn't realize that it was possible.

But it also raises a question, which pid should you announce with. The NSM server launches the NSM client and needs to manage it's pid (SIGTERM). In the case of adljack, the announced pid differs from the pid of the process which is started and controlled by the NSM server.
Houston4444/RaySession#16 (comment)

Do I understand it correctly that the NSM server actually starts a terminal, not adljack directly? And shouldn't adljack announce with the pid of that terminal process and so the NSM server can kill that terminal process when stopping adljack?

I think the announced pid of adljack should be the same as the process that is started by the NSM server, otherwise we can't be 100% certain that the server is killing the right pid, if it uses the by adljack announced pid. At least, that is how I understand it.

https://mywiki.wooledge.org/ProcessManagement?highlight=%28processes%29#PIDs_and_parents

[grammoboy2]

If I could build adljack, I could try messing with the code and see if I can get a other pid, see how it works under NSM, but neither git nor the adljack package in Arch Linux builds for me.

Could be that you're interested in this question as well of course, you'll be more familiar with the code.

[luzpaz]

Any more progress here ?

[grammoboy2]

Not yet. Will look into it soon, all though I'm not sure if I've the expertise to do so. What I want to try is to get the pid of the terminal process and pass that to the NSM server instead.

May I ask why you're asking this? Any help is welcome. ;)

[luzpaz]

Just curious, and that it would be cool to get more interoperability

[grammoboy2]

Ok, I did a little experiment. In nsm.h, getpid() is used, it's the pid of adljack, which is then send to the NSM server.
https://github.com/jpcima/adljack/blob/master/thirdparty/nonlib/nsm.h#L243

When getppid() is used instead, it's the pid of the terminal which gets send to the NSM server. This is the process which is started by the NSM server and which the NSM server would ideally expect.

When getppid() is used, everything seems to works fine. Launching, stopping (SIGTERM) from the NSM server and also when using 'q' in adljack.

I'm not a unix process management expert, but getppid() might be the better choice for a NSM client which is started in a terminal (which might not be the ideal for a NSM client anyway, but ok). The NSM server is the manager of the terminal process, not the adljack process, which is important, quote bashguide:

"If the parent process manages its child process, it can be absolutely certain that, even if the child process dies, no other new process can accidentally recycle the child process's PID until the parent process has waited for that PID and noticed the child died. This gives the parent process the guarantee that the PID it has for the child process will ALWAYS point to that child process, whether it is alive or a "zombie". Nobody else has that guarantee. "
https://mywiki.wooledge.org/ProcessManagement?highlight=%28processes%29

So in general, ideally the NSM server wants the pid of the process it started itself. Which it normally gets from a NSM client (unless someone sets NSM_URL itself), but not in the case of adljack and applications that uses a similar 'launch in terminal method'.

ps -aef:
user 175816 30627 0 20:36 pts/1 00:00:00 xterm -e adljack
user 175817 175816 15 20:36 pts/8 00:00:07 adljack

pstree:
nsmd(30627)─┬─xterm(175816)───adljack(175817)─┬─{adljack}(175818)

So the NSM server is the parent of 'xterm -e adljack' (parent 30627), but not of adljack (parent 175816) itself if I'm right.

So the xterm process is the parent of adljack. What will happen if the parent dies, but the child not?

"Now, lets come back to the question (we left open in the last section) about the consequences when parent process gets killed while child is still alive. Well in this case, the child obviously becomes orphan but is adopted by the init process. So, init process becomes the new parent of those child processes whose parents are terminated."
https://www.thegeekstuff.com/2013/07/linux-process-life-cycle/

Adljack can't live without xterm, so it dies when xterm dies?

Again, I'm not a unix expert, but given the fact that ideally the NSM server wants to be the owner of the process of the NSM client, to be able to stop the NSM client safely with SIGTERM, getppid() might be the better method in the case of adljack which is started in a terminal. Needs confirmation by someone who is actually a unix process management expert.

https://www.man7.org/linux/man-pages/man2/getpid.2.html

cc @Houston4444

[grammoboy2]

Adljack can't live without xterm, so it dies when xterm dies?

Xterm sends SIGHUP I assume, so Adljack should catch SIGHUP (and SIGINT?) probably then.

adljack/sources/common.cc

Line 581 in dc46297

void handle_signals()

[grammoboy2]

I found a comment which describes what happens in a well understandable way:
https://unix.stackexchange.com/a/436578

So as I understand it, the NSM server launches adljack, adljack uses execvp to eexecute itself into a xterm program or similar, replacing the process image and so keeping the same parent (NSM server). So the NSM server is the parent of the xterm process now. When xterm dies, it sends SIGHUP to it's children (adljack).

So yes, I think adljack should use getppid (to send the right pid to the NSM server) and handle SIGHUP the way it would handle SIGTERM in the context of NSM session management.

In the currently available NSM servers, adljack will probably work just fine, but I can imagine a NSM server wants to be sure it is the parent of the process it needs to kill by SIGTERM (or even SIGKILL optionally as last resort). Then the above described way is a better way to handle this for NSM clients that relaunches itself in a terminal, like adljack does IMO.