Save client settings on SIGUSR1

[newlaurent62]

Hello,

I'm using Jamulus in a RaySession setup (audio session manager) and it can save all applications in one click.

It seems that client settings are not saved on SIGUSR1. Is that right ?

Notes: Ladish works with SIGUSR1 and non-session-manager can work with SIGUSR1 / SIGUSR2 / SIGINT if nsm protocol is not supported.

BR,
Laurent

[corrados]

@pljones I think you are the expert to answer the above question.

[pljones]

The client has no signal handling.

[corrados]

It seems that client settings are not saved on SIGUSR1. Is that right ?

Who defines that settings are saved on SIGUSR1? According to https://en.wikipedia.org/wiki/Signal_(IPC) : "The SIGUSR1 and SIGUSR2 signals are sent to a process to indicate user-defined conditions.". So it is not defined what to do on SIGUSR1.

[newlaurent62]

You are right.

Ladish and non-session-manager are session management protocols. With this session manager, you can open, record the state of a bunch of application, or close them in one click. Useful for complex virtual studio setup.

When the session management is not implemented natively by an application, it can work with signal handling such as SIGUSR1 or SIGUSR2 ... see my first post.

[corrados]

Recently we have implemented that the settings are stored if you use the SIGTERM signal: #70
So with your session manager you could terminate Jamulus (which stores the settings) and then just re-start Jamulus.

[pljones]

Oh, I did that already, did I? So many things happening...

SIGUSR1 / SIGUSR2 are already in use in Jamulus (for controlling the Jam Recorder). Given that "Settings" applies to both client and server, it would be best if any signal chosen worked the same way for both. I'd suggest SIGHUP.

In my head I've a total overhaul of settings management... It also relates to the Server GUI enhancement work.

[newlaurent62]

All the signal handled by the protocol for saving are:

SIGUSR1, SIGUSR2 and SIGINT

It would be nice if you could choose one of them.

[pljones]

The SIGUSR1 and SIGUSR2 signals are sent to a process to indicate user-defined conditions.

These are defined already:

• For Jamulus, SIGUSR1 is to stop/start a new recording
• For Jamulus, SIGUSR2 will be to enable / disable recording

For any controls unrelated to recording, different signals need to be used. Remember that the server has settings as well.

Given that SIGINT is what terminal Control C sends to end a program, I don't think that's a good idea if you want the program to keep running.

So I think SIGHUP is probably the best bet.

[newlaurent62]

OK i will write a wrapper script that when receiving a SIGUSR1 from raysession send a SIGHUP to Jamulus.

[pljones]

Actually, had this been raised (again) at just the right time, it might have won ... #120 (comment) ... There had previously been a claim on SIGUSR1/2 over settings. That's the problem with "user-defined conditions". (At least we're not trying to monitor dBus.)

For "settings" as a topic, I have a list:

• Save / restore settings - can I do it "in flight"? From command line and GUI? (This issue.)
• How do command line options interact with ini-file values? Does it make sense? (Not found the issue for this, though I thought I'd raised one... probably thought 228 would do it. It won't.)
• How does the GUI compare with the command line? Are all options available through both? (Improve interaction between use of inifile and command line parameters (edited) #120)

[pljones]

@corrados
I note in the Changelog:

TODO improve settings management -> move settings class in client/server classes, move actual settings variables

Is this / #120 in progress?

[corrados]

My plan is to clean up the settings. I started creating different classes for client/server. More work to do in that area, soon. Then I want to deal with the problem that if the server GUI is used, some command line arguments are overwritten, which is not a good behavior.

[pljones]

Yep, I had started on the same thing but I'm very happy to drop it :).

[corrados]

See my following comment: #347 (comment)

[newlaurent62]

When using a session manager, there are four actions to handle:

Open Jamulus
Save Jamulus state without quitting (Ideally SIGUSR1)
Quit Jamulus without saving state (Abort) SIGKILL
Quit Jamulus kindly (save state) SIGTERM

We are talking about client settings but this could apply to server settings too.

I use RaySession as session manager available on Linux.

[corrados]

See my comment #347 (comment) and the following discussion.

[corrados]

As in the following comment: #347 (comment) I will close this issue now.