Discussion:
Problem with XFCE in Slackware 14.2
Add Reply
Harold Johanssen
2018-11-30 15:35:12 UTC
Reply
Permalink
I have come across a rather insidious and annoying situation in
XFCE, and my hope is that someone here might point out how to fix things
in it.

From my XFCE desktop, I sometimes access a remote desktop (also
running 14.2 with XFCE) with the following command:

ssvnc -cmd -ssh remote-system:0 -passwd $HOME/.vnc/passwd

In essence, this is going to create an SSH tunnel to remote-system, and
then connecting through this tunnel to the desktop in the console at
remote-system. The -passwd option simply takes a password from $HOME/.vnc/
passwd and supplies it to remote-system for authentication. Since the
connection is established through an SSH tunnel, this does not really add
much; it is there just in case attempts are made to connect to this
desktop directly. Not really an option from the external world in my
setup, anyway. But, I digress.

The command above works seamlessly, as long as the connection to
remote-system is completed with public key authentication. With password
authentication, one is prompted for the password, several times. Since I
do use public key authentication, I created an XFCE launcher, so that
when I click on it I access the desktop at remote-system automagically.
Great.

Here's the problem: if and when, for whatever reason, the ssvnc
command above prompts for a password (be it because I forgot to add my
private key to my SSH agent, or because remote-system refuses to do
public key authentication) on clicking on the XFCE launcher, my whole
XFCE desktop freezes. Whatever applications I have running in it keep
running all right, but the desktop stops accepting input from mouse and
keyboard. Applets that I have added to my top panel also freeze - for
instance, I have network and CPU activity applets that, under normal
circumstances, keep displaying activity as changing bars. When the above
happens the just freeze.

The one that seems to be freezing is the XFCE windows manager,
xfwm4. When I kill it by hand, the desktop becomes unfrozen - but, since
I do not have a window manager any longer, all of my applications are
piled up, one on top of another. At this point, my only solution consists
of relaunching X - which, as you can imagine, when I had hundreds of
applications running, can be a painful proposition.

Can anybody suggest a mechanism to recover gracefully from this -
i.e. without having to kill xfwm4? I can still access this system e.g. by
ssh, so I can manage processes in it. Killing the ssvnc command above by
hand won't do anything in this respect. That ssvnc command issues an ssh
command to create the tunnel - killing it by hand also does not do
anything. The problem is clearly in xfwm4, that gets locked up. I tried a
kill -HUP on it, to no avail. A simple kill also does nothing, whereas a
kill -9 just kills it, and it does not get restarted.

Any ideas to try?
Rich
2018-11-30 16:07:08 UTC
Reply
Permalink
Post by Harold Johanssen
Here's the problem: if and when, for whatever reason, the ssvnc
command above prompts for a password (be it because I forgot to add my
private key to my SSH agent, or because remote-system refuses to do
public key authentication) on clicking on the XFCE launcher, my whole
XFCE desktop freezes.
This sounds like a global grab in action. And is likely the ssh agent
attempting to open the "give me your key password" dialog, grabbing the
screen, but then not appearing for some reason.
Post by Harold Johanssen
Can anybody suggest a mechanism to recover gracefully from this -
i.e. without having to kill xfwm4?
1) figure out why that other system sometimes refuses to do key auth
and fix that issue

2) figure out why ssh agent's password prompt is grabbing the screen,
but not appearing for you to type into (if this is the issue)

3) work out some kind of flow where you do not forget to add your keys
to ssh agent

4) ???
Post by Harold Johanssen
The problem is clearly in xfwm4, that gets locked up.
Not if it is some other program performing a global grab. The effect
is "locked up" just as you describe, but is meremly xfwm4 performing
the request it was given.
Post by Harold Johanssen
I tried a kill -HUP on it, to no avail. A simple kill also does
nothing, whereas a kill -9 just kills it, and it does not get
restarted.
After kill -9 removing it, have you simply tried restarting it (xfwm4)
manually? Since killing it does not take down the whole X session,
then provided you either tell it the X display or have the DISPLAY
environment variable set correctly, you should just be able to restart
it manually and be back, mostly, where you left off.
Harold Johanssen
2018-11-30 19:33:57 UTC
Reply
Permalink
Post by Rich
Post by Harold Johanssen
Here's the problem: if and when, for whatever reason, the ssvnc
command above prompts for a password (be it because I forgot to add my
private key to my SSH agent, or because remote-system refuses to do
public key authentication) on clicking on the XFCE launcher, my whole
XFCE desktop freezes.
This sounds like a global grab in action. And is likely the ssh agent
attempting to open the "give me your key password" dialog, grabbing the
screen, but then not appearing for some reason.
I killed the ssh agent as well. No cigar.
Post by Rich
Post by Harold Johanssen
Can anybody suggest a mechanism to recover gracefully from this -
i.e. without having to kill xfwm4?
1) figure out why that other system sometimes refuses to do key auth and
fix that issue
That I figured out. In the latest instance, it was a mistake I
made: I changed the permissions in my home directory in that system, so
that members of my group had rw access to it. With such permissions, the
ssh daemon refused to honor public key authentication.
Post by Rich
2) figure out why ssh agent's password prompt is grabbing the screen,
but not appearing for you to type into (if this is the issue)
Well, that's the problem: I get prompts when invoking the ssvnc
command from the CLI, but not when clicking on the corresponding launcher.
Post by Rich
3) work out some kind of flow where you do not forget to add your keys
to ssh agent
Notice that in the case the prompted me to ask for help this was
not the issue - the ssh agent was up and running, and the relevant ssh
private key had been added to it. The problem was that the remote refused
to do public key authentication, because of the permission issue
described above.
Post by Rich
4) ???
Indeed.
Post by Rich
Post by Harold Johanssen
The problem is clearly in xfwm4, that gets locked up.
Not if it is some other program performing a global grab. The effect is
"locked up" just as you describe, but is meremly xfwm4 performing the
request it was given.
OK.
Post by Rich
Post by Harold Johanssen
I tried a kill -HUP on it, to no avail. A simple kill also does
nothing, whereas a kill -9 just kills it, and it does not get
restarted.
After kill -9 removing it, have you simply tried restarting it (xfwm4)
manually?
I did - but I suspect I did incorrectly. With the system in that
locked-up state, the output from ps awux | egrep xfw was something like

xfwm4 --display :0.0 --sm-client-id 24367cdc9-dd20-4c2e-ac61-
c3f802b78bed

After kill -9 this, I started it again typing in exactly the same line as
above (the hex string was of course different, but you know what I mean.)
This did not restore my session though.
Post by Rich
Since killing it does not take down the whole X session, then
provided you either tell it the X display or have the DISPLAY
environment variable set correctly, you should just be able to restart
it manually and be back, mostly, where you left off.
Rich
2018-11-30 19:46:48 UTC
Reply
Permalink
Post by Harold Johanssen
Post by Rich
Post by Harold Johanssen
Here's the problem: if and when, for whatever reason, the ssvnc
command above prompts for a password (be it because I forgot to add my
private key to my SSH agent, or because remote-system refuses to do
public key authentication) on clicking on the XFCE launcher, my whole
XFCE desktop freezes.
This sounds like a global grab in action. And is likely the ssh agent
attempting to open the "give me your key password" dialog, grabbing the
screen, but then not appearing for some reason.
I killed the ssh agent as well. No cigar.
The thing that would be performing the "grab" would be the pin entry
app, not the agent itself.
Post by Harold Johanssen
Post by Rich
Post by Harold Johanssen
Can anybody suggest a mechanism to recover gracefully from this -
i.e. without having to kill xfwm4?
1) figure out why that other system sometimes refuses to do key auth and
fix that issue
That I figured out. In the latest instance, it was a mistake I
made: I changed the permissions in my home directory in that system, so
that members of my group had rw access to it. With such permissions, the
ssh daemon refused to honor public key authentication.
Ah, ok, so there is one fix there.
Post by Harold Johanssen
Post by Rich
2) figure out why ssh agent's password prompt is grabbing the screen,
but not appearing for you to type into (if this is the issue)
Well, that's the problem: I get prompts when invoking the
ssvnc command from the CLI, but not when clicking on the
corresponding launcher.
Hmm, maybe the xfce launcher does a brief grab, but before it releases
it, something about the pin entry app gets things borked.

Can you change the launcher so it launches a shell script that starts a
terminal that then starts the login process. That might avoid the grab
(but would leave you with a stray terminal unless you have the startup
script exit it when the full connection is up.
Post by Harold Johanssen
Post by Rich
Post by Harold Johanssen
The problem is clearly in xfwm4, that gets locked up.
Not if it is some other program performing a global grab. The
effect is "locked up" just as you describe, but is meremly xfwm4
performing the request it was given.
OK.
Post by Rich
Post by Harold Johanssen
I tried a kill -HUP on it, to no avail. A simple kill also does
nothing, whereas a kill -9 just kills it, and it does not get
restarted.
After kill -9 removing it, have you simply tried restarting it (xfwm4)
manually?
I did - but I suspect I did incorrectly. With the system in that
locked-up state, the output from ps awux | egrep xfw was something like
xfwm4 --display :0.0 --sm-client-id 24367cdc9-dd20-4c2e-ac61-
c3f802b78bed
After kill -9 this, I started it again typing in exactly the same line as
above (the hex string was of course different, but you know what I mean.)
This did not restore my session though.
Interesting. Then it (xfwm4) has some additional connection to the
rest of the xfce setup that makes restarting it not work, or it has to
be started from some other specific task (so it's stdin/stdout/stderr
are connected to the other task). Note I don't use xfce (or any of the
other "desktop environments") so I can't say how it is supposed to be
launched.

In my case, I could kill -9, then relaunch, fvwm2, and I'd be back
(almost) where I was. Windows would move back from virtual desktops
and need to be put back, but I'd be back up and running with a window
manager.

Hmm, here's another thought, when you 'launch' from the launcher, does
the remote task put itself into the background or does it remain as a
foreground task from the launcher's point of view. I.e., this would be
the difference between using "&" and not on a CLI command. Without,
the CLI waits for the command to finish, with you get a prompt back
right away.

Maybe the launcher takes a 'grab', launches the process, and expects
the process to put itself into the background and return from the
'exec' it (the launcher) performed before the launcher releases the
grab.

Maybe the password prompt interfeares with the 'go into background'
aspect, and you get the appearance of a hang in that situation. So
maybe launching via a shell script that backgrounds the task and
returns to the launcher might fix the hang. This is, however, just a
guess on my part.
Harold Johanssen
2018-11-30 20:32:35 UTC
Reply
Permalink
Interesting. Then it (xfwm4) has some additional connection to the rest
of the xfce setup that makes restarting it not work, or it has to be
started from some other specific task (so it's stdin/stdout/stderr are
connected to the other task). Note I don't use xfce (or any of the
other "desktop environments") so I can't say how it is supposed to be
launched.
Thanks for your feedback. The easiest workaround is just to
launch my VNC command from a terminal - that way, xfwm4 won't lock up.
But the mystery as to why xfwm4 is locking up remains. And it is a major
lockup - I tried with

xfwm4 --display :0.0 --replace --sm-client-id 24367cdc9-dd20-4c2e-
ac61-c3f802b78bed

and after spinning for a few seconds, this command exits claiming that
the existing xfwm4 instance refuses to be replaced. Quite frankly, if
xfwm4 can be so drastically locked up because of a separate, non-XFCE
command, I am inclined to believe that this a bug in xfwm4.

Loading...