Unable to run with multiple users

[BUYT-1]

EasyEffects Version

8.1.6

What package are you using?

Arch (easyeffects)

Distribution

Arch Linux

Describe the bug

If one user has launched Easy Effects, running easyeffects as another user fails to launch it, outputting QIODevice::write (QLocalSocket): device not open. easyeffects --debug does the same thing. PipeWire is used almost as it is packaged, without much extra configuration.

Expected Behavior

The other user should be able to open Easy Effects.

Debug Log

No response

Additional Information

@cameron-thomson in #4928 found that this happens because Easy Effects uses a single lockfile in QStandardPaths::TempLocation and suggested using QStandardPaths::RuntimeLocation as the location. The other users would not be able to see the lock file then, which may break something in multi-user PipeWire setups like discussed here.

I don't know the internals of PipeWire. Which resource(s) is being locked here? Is it the server itself? I believe the directory can stay as /tmp, but the name of the lockfile should be derived from that resource, whatever it is.

[wwmm]

I don't know the internals of PipeWire. Which resource(s) is being locked here? Is it the server itself?

The reason for the lock is avoiding multiple EasyEffects instances in a single user session. This has never been supported. One instance will conflict with the other.

I believe the directory can stay as /tmp, but the name of the lockfile should be derived from that resource, whatever it is.

I've updated our master branch with QStandardPaths::RuntimeLocation. It should be enough to fix the multiuser case while still blocking multiple single user instances.

[wwmm]

You can use the AUR package to test how things are now. It uses our master branch.

[BUYT-1]

Thanks, it works for me now. Will this also work for setups where the server is shared between multiple users like here?

[wwmm]

Thanks, it works for me now. Will this also work for setups where the server is shared between multiple users like here?

I think it should. Each user will have his own unique QStandardPaths::RuntimeLocation path. So at least that problem should not happen. The server being shared is a little concerning. But it is a use case I have never tested. If the server behaves as if the user had an independent server instance it should be fine. But if the streams and any other node created by an user can be viewed and destroyed by the others there will be conflict.

For example EasyEffects creates a virtual sink and source. If one user has visibility to the virtual devices of other easyeffects instances this will probably be a problem.