xpra icon
Bug tracker and wiki

Opened 10 days ago

Last modified 39 hours ago

#2032 new defect

The spawned X server stays alive when xpra killed before a display number is assigned

Reported by: berserker Owned by: Antoine Martin
Priority: major Milestone: 2.5
Component: server Version: 2.4.x
Keywords: Cc:

Description (last modified by Antoine Martin)

The reason is that the function killing the X server is added to the Xpra exit cleanup list only after the display number is assigned, see
browser/xpra/trunk/src/xpra/scripts/server.py and
browser/xpra/trunk/src/xpra/scripts/server.py.

Change History (8)

comment:1 Changed 9 days ago by Antoine Martin

Description: modified (diff)
Priority: criticalmajor
Status: newassigned

It's not easy to change this, the kill_display function is also used for display upgrades.

I don't see how this bug is critical: don't kill xpra shortly after starting it and this won't be an issue.

comment:2 Changed 9 days ago by berserker

I don't see how this bug is critical

When starting Xpra, sporadically I get the following error:

xpra initialization error:

xpra_Xdummy: did not provide a display number using displayfd

Terminating Xpra does not terminate X server in this case! And you "don't see how this is critical"...

comment:3 Changed 9 days ago by Antoine Martin

xpra_Xdummy: did not provide a display number using displayfd

This can happen if your system is really slow.
You can try to change the default timeout:

XPRA_DISPLAY_FD_TIMEOUT=30 xpra start ...

comment:4 Changed 9 days ago by berserker

This can happen if your system is really slow.

Well, kinda. But the question really is why it lets Xorg to continue running after the error occurs?

Last edited 9 days ago by berserker (previous) (diff)

comment:5 Changed 4 days ago by Antoine Martin

Owner: changed from Antoine Martin to berserker
Status: assignednew

Well, kinda.

what other possibility is there that I am missing?

But the question really is why it lets Xorg to continue running after the error occurs?

Because no-one hit that bug until now?

Fixed for me in r20968. Tested with an unreasonably low timeout value:

XPRA_DISPLAY_FD_TIMEOUT=1 python2 /usr/bin/xpra start --no-daemon -d x11

@berserker: please close if that works for you.

comment:6 Changed 2 days ago by berserker

Owner: changed from berserker to Antoine Martin

what other possibility is there that I am missing?

Nothing. The system is indeed slow and on top of that users have CPU limits. This makes it easy to trigger the timeout if try to start several Xpra servers simultaneously.

please close if that works for you

Ehm... r20968 is not a fix for the bug reported, even if it solves the problem with timeouts (not checked yet).

comment:7 Changed 44 hours ago by Antoine Martin

Owner: changed from Antoine Martin to berserker

Ehm... r20968 is not a fix for the bug reported

It is meant to be.

even if it solves the problem with timeouts (not checked yet).

Timeouts are the only unhandled error path I could find that could cause the cleanups to be skipped.

If you can still reproduce a problem, please post the full output of:

XPRA_ALL_DEBUG=1 xpra start ....

comment:8 in reply to:  7 Changed 39 hours ago by berserker

Owner: changed from berserker to Antoine Martin

Replying to Antoine Martin:

Timeouts are the only unhandled error path I could find that could cause the cleanups to be skipped.

There is also Ctrl+C.

Note: See TracTickets for help on using tickets.