Hi,

in short:
  1. I support this feature as I've already run into this issue sometimes during testing 😉
  2. I support easiest possible solution when detecting and solving the collision. I mean, just inform the user that collision happened and quit. Let the user solves it on his own. It is not yast responsibility to decide which instance should be preferred, highlight an already running instance window or something similar. Yast is admin tool and admin should have enough power and knowledge to solve it by already available admin tools.
Michal
From: josef Reidinger <jreidinger@suse.cz>
Sent: Tuesday, August 17, 2021 21:08
To: yast-devel@lists.opensuse.org <yast-devel@lists.opensuse.org>
Subject: Re: Preventing from running the same module twice
 
On Tue, 17 Aug 2021 17:25:54 +0200
Lukas Ocilka <lukas.ocilka@suse.com> wrote:

> Hi,
>
> While checking and refining some older bugs and feature request with
> David and Ancor, we came across an interesting one:
>
>   *Prevent the same YaST module from running twice at the same time*
>
> We've been discussing the topic back and forth, identified some
> use-cases in which it would make sense, a few technical solutions and
> even more obstacles, but we decided it would make sense to ask for
> opinions at YaST Devel first.
>
> Why to prevent from running the same twice?
>
> - Some may click too fast and run two or more at the same time -> here
>   you instantly see more modules starting
> - Some may start a YaST module, then do something else, overlook the
>   first one, start another, ... then hard to say which one wins at the
>   end and what would be the changes --> is that likely?
> - Two admins could run the same module without knowing about each other
>   --> this may happen in remote session at COVID times 
>
> How to prevent from running them more times?

Hi,
my usual advise is to check how others do it.

>
> - Logging the PID, storing it at some file (module/client name),
>   checking at startup (more PIDs in case of more sessions of the same?)

This is libzypp way. I think even we hit it, if multiple yast modules are run and it uses packager backend, that zypp lock is locked.
I think also libzypp face some issues with it like read only lock or non related stuff for lock ( like libzypp running on different chroot ).
I expect similar cases can happen with yast as already mentioned in possible problems.

> - Either at YaST startup scripts (easier) or YaST core (some might skip
>   using a startup script, is that likely?)

I vote for y2start ruby script. it already has unit tests and other ways to start yast is not supported, so it is already high level enough with test coverage, but without support to overcome it.

> - Showing a message (another special client) and offering some options,
>   e.g., kill the other session, exiting

yeah, libzypp way and also allow to overwrite it with some global variable if you really want to. But beside libzypp we have
more interesting challenge. What if more modules are run and they work on similar data? From my mind e.g. network is used at multiple modules
or bootloader. If you run bootloader and kdump and write kdump and then bootloader, it will overwrite kdump data.

> - Offering a read-only mode (quite hard) for the second session

I worry, that it will be really hard as lot of code is not ready for it. Like e.g. what if some software is missing ( installed in second second meanwhile? ) or what if second session writes partially some data ( so in progress of write ).

> - Another idea was to bring the UI to the front (only possible with Qt)
>   instead of starting a new one

It does not solve issue with multiple remote admins or combination of qt and ncurses. So for me the solution that solves really just part of issue.

>
> Some possible problems
>
> - Some admins really just run YaST to see the current configuration, so
>   preventing from running something twice might not be an option

global variable can be solution for them, but it does not help always see above for various race condition that can happen.

> - Some YaST modules can be called from within another ones, e.g.,
>   Repositories from the Packager, what to do with that?

hard one and not just about UI, but also working on same data as I write above.

> - Some YaST modules can be called as a user; what if the user differs?

Easy solution, if it is user specific, then use user specific pid lock file and for root global one ( I mean euid here ).

>
> Quite some unknowns as you may see :) Is that worth it? Is there a
> simpler solution? Would that fit?

My proposal is really trivial, no files, no exiting. Just add check if in process list ( like `ps aux` ) is already yast with any module. And if there is already another running yast module warn user that collision can happen and if (s-)he wants to continue. So no rocket science, just inform user ( and log it). And if there will be complains about this behavior for whatever use case then add option to disable such popup to /etc/sysconfig/yast2 .

>
> Links
> - https://bugzilla.suse.com/show_bug.cgi?id=959866
> - https://jira.suse.com/browse/SLE-2999 (internal)
>
> Thanks for your opinions
> Lukas
>

Josef