ArcticaProject / nx-libs

nx-libs
Other
120 stars 39 forks source link

CUPS is broken on OSX starting from El Capitan #737

Open vatral opened 5 years ago

vatral commented 5 years ago

Starting from El Capitan, the CUPS service is not running by default on OSX, and is started as needed. Also, it automatically shuts down after being unused for some time.

As a result, forwarding the print port fails to work correctly.

We're currently looking into this. I will have to look more deeply into how is an application supposed to do this properly, but my current idea is to make NX start cupsd by invoking cupsctl before connecting to the port.

I'm opening the bug in case you're aware of the issue, or have an idea of how it should be fixed.

uli42 commented 5 years ago

This is not an nx-libs bug. I'd rather not integrate cups start into nx-libs. This is clearly the task of the session management software (x2go, qvd etc.).

vatral commented 5 years ago

Okay, so here's what I gathered so far:

CUPS is not running by default anymore on OSX, so it's not listening to the port at all (and there's no socket listener that starts it, it seems. At least on TCP). It also shuts down automatically after a while.

So here is the rough idea I had in mind: I want to add an option to NX to add a configurable command that would be executed on an incoming connection. This then would be provided by QVD. The command in the case of the print port would do whatever is needed to start CUPS.

How does that sound to you? I'd like to coordinate our efforts here, and that sounds like potentially useful functionality.

uli42 commented 5 years ago

On Mon, Dec 17, 2018 at 11:43 PM Vadim Troshchinskiy notifications@github.com wrote:

Okay, so here's what I gathered so far:

CUPS is not running by default anymore on OSX, so it's not listening to the port at all (and there's no socket listener that starts it, it seems. At least on TCP). It also shuts down automatically after a while.

So here is the rough idea I had in mind: I want to add an option to NX to add a configurable command that would be executed on an incoming connection. This then would be provided by QVD. The command in the case of the print port would do whatever is needed to start CUPS.

How does that sound to you? I'd like to coordinate our efforts here, and that sounds like potentially useful functionality.

I am totally fine with that. Maybe we should also add the opposite, too: a configurable command that is executed on disconnect.

But I am wondering (I don't know OSX): How is CUPS used on that system at all? Who is starting the service when a user wants to print?

Uli

Ionic commented 5 years ago

Socket activation is a state of the art technique. Given a known and always socket location (normally passed via env variables) that is created/managed by system software such as systemd or launchd, client applications can just connect to this socket. The server will be spawned automatically by systemd/launchd and data proxied, as well as disabled again after the last client exits.

uli42 commented 5 years ago

So OSX is working like systemd here. What needs to be done to leverage that for x2go?

Am Di., 18. Dez. 2018, 01:20 hat Mihai Moldovan notifications@github.com geschrieben:

Socket activation is a state of the art technique. Given a known and always socket location (normally passed via env variables) that is created/managed by system software such as systemd or launchd, client applications can just connect to this socket. The server will be spawned automatically by systemd/launchd and data proxied, as well as disabled again after the last client exits.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArcticaProject/nx-libs/issues/737#issuecomment-448049302, or mute the thread https://github.com/notifications/unsubscribe-auth/AGBw5D0h6Zvww9aVqeM7zzhH67G5i2BOks5u6DTogaJpZM4YzBJV .

vatral commented 5 years ago

I've not looked much into it yet. We've found it during testing, and it's on the list, but pretty much the entire team is on vacation, so it will take me a while to get to it.

I opened the ticket a bit early to start looking into how to approach it.

Perhaps nothing elaborate is needed then, just swap a redirect to TCP port to a redirect to a socket?

uli42 commented 5 years ago

764 has been removed from the code again because it broke reconnects for some setups. Suggestion is to replace ":" in CUPS urls by %3A