Hi All,
Fedora-KDE-Live-x86_64-34-1.2.iso
$ loginctl show-session 2 -p Type Type=wayland
How do I switch back to Xorg (X11)? I am drawing a blank on DuckDuckGo.
Many thanks, -T
On 13/07/2021 10:04, ToddAndMargo via users wrote:
Hi All,
Fedora-KDE-Live-x86_64-34-1.2.iso
$ loginctl show-session 2 -p Type Type=wayland
How do I switch back to Xorg (X11)? I am drawing a blank on DuckDuckGo.
Many thanks,
On 7/12/21 7:45 PM, Ed Greshko wrote:
On 13/07/2021 10:04, ToddAndMargo via users wrote:
Hi All,
Fedora-KDE-Live-x86_64-34-1.2.iso
$ loginctl show-session 2 -p Type Type=wayland
How do I switch back to Xorg (X11)? I am drawing a blank on DuckDuckGo.
Many thanks,
Hi Ed,
Picture worth 1000 words!
I had to reboot the first time as it froze up
Second time:
$ loginctl show-session 2 -p Type Type=X11
And the mouse is still confined and the clipboard does not work.
$ systemctl status spice-vdagentd ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
From kconsole $ /usr/bin/spice-vdagent
and the mouse is unconfined and the clipboard work, in kconsole as well.
Must better. kconsole is no longer irritating either!
:-)
Now how to autostart spice-vdagentd (in KDE)?
Thank you for all the help!
-T
On 13/07/2021 12:03, ToddAndMargo via users wrote:
$ systemctl status spice-vdagentd ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
From kconsole $ /usr/bin/spice-vdagent
and the mouse is unconfined and the clipboard work, in kconsole as well.
Must better. kconsole is no longer irritating either!
:-)
Now how to autostart spice-vdagentd (in KDE)?
No need to start spice-vdagentd! I think I said that more than once.
You can see from above, and better yet the one with the full output, that spice-vdagentd.service is "enabled" AND "TriggeredBy: ● spice-vdagentd.socket"
Further more, you can see that spice-vdagentd.socket is "listening"
When you run spice-vdagent it connects to the default port/socket. That then "triggers" spice-vdagentd.service.
You question should really be. How do I start /usr/bin/spice-vdagent at login without having to type it or run it after login.
I gave you one way. That is to put /usr/bin/spice-vdagent as a line in your .bashrc file. Assuming, of course, you are using bash as your default shell as defined in /etc/passwd.
The other way is to write a systemd --user unit
Either way works just fine.
On 13/07/2021 12:33, Ed Greshko wrote:
Either way works just fine.
Another thing that I found can be "helpful" with KDE is to edit the /etc/systemd/logind.conf to have one line read
KillUserProcesses=yes
I've done this for sometime now. I don't know, and really don't care to find out, it the situation exists that prompted me to do that. But, what was happening is that when one logged out from the Plasma session some processes would remain running in the background. I think the intention what that if the same user logged in again those processes could be reclaimed to speed up the login. I found that after a time there were a large number of "orphaned" processes. I also had issue with Plasma reconnecting to pulseaudio. I also think that not killing processes was part of the "switch user" feature which has been disabled by default and which I never really tried using.
Killing the user processes on logout fixed things for me.
On 7/12/21 9:42 PM, Ed Greshko wrote:
On 13/07/2021 12:33, Ed Greshko wrote:
Either way works just fine.
Another thing that I found can be "helpful" with KDE is to edit the /etc/systemd/logind.conf to have one line read
KillUserProcesses=yes
I've done this for sometime now. I don't know, and really don't care to find out, it the situation exists that prompted me to do that. But, what was happening is that when one logged out from the Plasma session some processes would remain running in the background. I think the intention what that if the same user logged in again those processes could be reclaimed to speed up the login. I found that after a time there were a large number of "orphaned" processes. I also had issue with Plasma reconnecting to pulseaudio. I also think that not killing processes was part of the "switch user" feature which has been disabled by default and which I never really tried using.
Killing the user processes on logout fixed things for me.
I rebooted
On 13/07/2021 12:47, ToddAndMargo via users wrote:
On 7/12/21 9:42 PM, Ed Greshko wrote:
On 13/07/2021 12:33, Ed Greshko wrote:
Either way works just fine.
Another thing that I found can be "helpful" with KDE is to edit the /etc/systemd/logind.conf to have one line read
KillUserProcesses=yes
I've done this for sometime now. I don't know, and really don't care to find out, it the situation exists that prompted me to do that. But, what was happening is that when one logged out from the Plasma session some processes would remain running in the background. I think the intention what that if the same user logged in again those processes could be reclaimed to speed up the login. I found that after a time there were a large number of "orphaned" processes. I also had issue with Plasma reconnecting to pulseaudio. I also think that not killing processes was part of the "switch user" feature which has been disabled by default and which I never really tried using.
Killing the user processes on logout fixed things for me.
I rebooted
The reboot I'd been requesting was to ensure status entries were "fresh".
What I reference above was for normal operations where one may login/logout/login multiple time in a day.
On 7/12/21 10:27 PM, Ed Greshko wrote:
On 13/07/2021 12:47, ToddAndMargo via users wrote:
On 7/12/21 9:42 PM, Ed Greshko wrote:
On 13/07/2021 12:33, Ed Greshko wrote:
Either way works just fine.
Another thing that I found can be "helpful" with KDE is to edit the /etc/systemd/logind.conf to have one line read
KillUserProcesses=yes
I've done this for sometime now. I don't know, and really don't care to find out, it the situation exists that prompted me to do that. But, what was happening is that when one logged out from the Plasma session some processes would remain running in the background. I think the intention what that if the same user logged in again those processes could be reclaimed to speed up the login. I found that after a time there were a large number of "orphaned" processes. I also had issue with Plasma reconnecting to pulseaudio. I also think that not killing processes was part of the "switch user" feature which has been disabled by default and which I never really tried using.
Killing the user processes on logout fixed things for me.
I rebooted
The reboot I'd been requesting was to ensure status entries were "fresh".
I did that one and later on an additional one because the turkey froze on me.
What I reference above was for normal operations where one may login/logout/login multiple time in a day.
Oh my goodness KDE runs better on Xorg!
On 13/7/21 15:33, ToddAndMargo via users wrote:
On 7/12/21 10:27 PM, Ed Greshko wrote:
On 13/07/2021 12:47, ToddAndMargo via users wrote:
On 7/12/21 9:42 PM, Ed Greshko wrote:
On 13/07/2021 12:33, Ed Greshko wrote:
Either way works just fine.
Another thing that I found can be "helpful" with KDE is to edit the /etc/systemd/logind.conf to have one line read
KillUserProcesses=yes
I've done this for sometime now. I don't know, and really don't care to find out, it the situation exists that prompted me to do that. But, what was happening is that when one logged out from the Plasma session some processes would remain running in the background. I think the intention what that if the same user logged in again those processes could be reclaimed to speed up the login. I found that after a time there were a large number of "orphaned" processes. I also had issue with Plasma reconnecting to pulseaudio. I also think that not killing processes was part of the "switch user" feature which has been disabled by default and which I never really tried using.
Killing the user processes on logout fixed things for me.
I rebooted
The reboot I'd been requesting was to ensure status entries were "fresh".
I did that one and later on an additional one because the turkey froze on me.
What I reference above was for normal operations where one may login/logout/login multiple time in a day.
Oh my goodness KDE runs better on Xorg!
When looking for something else a little while ago I found a thread on the net that was indicating that even in F34 KDE on Wayland was still not a viable entity.
regards, Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/12/21 9:33 PM, Ed Greshko wrote:
On 13/07/2021 12:03, ToddAndMargo via users wrote:
$ systemctl status spice-vdagentd ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
From kconsole $ /usr/bin/spice-vdagent
and the mouse is unconfined and the clipboard work, in kconsole as well.
Must better. kconsole is no longer irritating either!
:-)
Now how to autostart spice-vdagentd (in KDE)?
No need to start spice-vdagentd! I think I said that more than once.
You can see from above, and better yet the one with the full output, that spice-vdagentd.service is "enabled" AND "TriggeredBy: ● spice-vdagentd.socket"
Further more, you can see that spice-vdagentd.socket is "listening"
When you run spice-vdagent it connects to the default port/socket. That then "triggers" spice-vdagentd.service.
So the mouse or the clipboard should trigger it? They don't.
You question should really be. How do I start /usr/bin/spice-vdagent at login without having to type it or run it after login.
I gave you one way. That is to put /usr/bin/spice-vdagent as a line in your .bashrc file.
tried that. Didn't work. Only from kconsole worked
Assuming, of course, you are using bash as your default shell as defined in /etc/passwd.
The other way is to write a systemd --user unit
Either way works just fine.
systemd would be a workaround. But it should work properly on its own and not require my intervention.
For now, I will just trigger it manually.
Thank you! You know you have a gift.
:-)
-T
On 13/07/2021 12:51, ToddAndMargo via users wrote:
On 7/12/21 9:33 PM, Ed Greshko wrote:
On 13/07/2021 12:03, ToddAndMargo via users wrote:
$ systemctl status spice-vdagentd ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
From kconsole $ /usr/bin/spice-vdagent
and the mouse is unconfined and the clipboard work, in kconsole as well.
Must better. kconsole is no longer irritating either!
:-)
Now how to autostart spice-vdagentd (in KDE)?
No need to start spice-vdagentd! I think I said that more than once.
You can see from above, and better yet the one with the full output, that spice-vdagentd.service is "enabled" AND "TriggeredBy: ● spice-vdagentd.socket"
Further more, you can see that spice-vdagentd.socket is "listening"
When you run spice-vdagent it connects to the default port/socket. That then "triggers" spice-vdagentd.service.
So the mouse or the clipboard should trigger it? They don't.
No, they have no connection. Zero, nada, none.
You question should really be. How do I start /usr/bin/spice-vdagent at login without having to type it or run it after login.
I gave you one way. That is to put /usr/bin/spice-vdagent as a line in your .bashrc file.
tried that. Didn't work. Only from kconsole worked
Then you need to check to see why by getting the status of the spice-vdagent.service and spice-vdagent.socket.
Let me illustrate one again with an F34KDE system which is using an systemd --user unit. I'm using this since I didn't put logic in my .bashrc to check the environment in which it is started and this causes misleading log entries.
I will reboot and then first login via ssh.
[egreshko@f34k2 ~]$ uptime 13:12:33 up 1 min, 1 user, load average: 1.19, 0.53, 0.20
[egreshko@f34k2 ~]$ systemctl --no-pager -l status spice-vdagentd.service ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indirect; vendor preset: enabled) Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
[egreshko@f34k2 ~]$ systemctl --no-pager -l status spice-vdagentd.socket ● spice-vdagentd.socket - Activation socket for spice guest agent daemon Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.socket; static) Active: active (listening) since Tue 2021-07-13 13:11:17 CST; 1min 49s ago Triggers: ● spice-vdagentd.service Listen: /run/spice-vdagentd/spice-vdagent-sock (Stream) CGroup: /system.slice/spice-vdagentd.socket
Jul 13 13:11:17 f34k2.greshko.com systemd[1]: Listening on Activation socket for spice guest agent daemon.
[egreshko@f34k2 ~]$ ps -eaf | grep spice egreshko 1856 1825 0 13:13 pts/0 00:00:00 grep --color=auto spice
No spice-vdagentd is running. There is a socket established.
[egreshko@f34k2 ~]$ ll /run/spice-vdagentd/spice-vdagent-sock srw-rw-rw-. 1 root root 0 Jul 13 13:11 /run/spice-vdagentd/spice-vdagent-sock
Now, I will login to Plasma Xorg on the console.
And, again from the ssh session, we now see....
[egreshko@f34k2 ~]$ ps -eaf | grep spice egreshko 2057 1814 0 13:17 ? 00:00:00 /usr/bin/spice-vdagent -x root 2065 1 0 13:17 ? 00:00:00 /usr/sbin/spice-vdagentd
The spice-vdagent was started via a user unit placed as
[egreshko@f34k2 ~]$ ll .config/systemd/user/spice-vdagent.service -rw-r--r--. 1 egreshko egreshko 259 Jul 13 08:28 .config/systemd/user/spice-vdagent.service
The unit contains....
[egreshko@f34k2 ~]$ cat .config/systemd/user/spice-vdagent.service [Unit] Description=TestMe After=plasma-core.target
[Service] ExecStart=/usr/bin/spice-vdagent -x
[Install] WantedBy=plasma-core.target
And after login shows....
[egreshko@f34k2 ~]$ systemctl --no-pager -l --user status spice-vdagent.service ● spice-vdagent.service - TestMe Loaded: loaded (/home/egreshko/.config/systemd/user/spice-vdagent.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2021-07-13 13:17:21 CST; 4min 18s ago Main PID: 2057 (spice-vdagent) Tasks: 3 (limit: 2328) Memory: 3.9M CPU: 56ms CGroup: /user.slice/user-1026.slice/user@1026.service/app.slice/spice-vdagent.service └─2057 /usr/bin/spice-vdagent -x
as well as some other stuff that I need to check at some point but don't seem to have an negative effect.
For completeness
[egreshko@f34k2 ~]$ grep greshko /etc/passwd egreshko:x:1026:65536:Ed Greshko:/home/egreshko:/bin/bash
So, why it doesn't work for you from the .bashrc file is unknown without diagnostic output.
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
-T
# cat /usr/lib/systemd/system/spice-vdagentd.service
[Unit] Description=Agent daemon for Spice guests After=dbus.target Requires=spice-vdagentd.socket
[Service] Type=forking EnvironmentFile=-/etc/sysconfig/spice-vdagentd ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS PIDFile=/run/spice-vdagentd/spice-vdagentd.pid PrivateTmp=true Restart=on-failure
[Install] Also=spice-vdagentd.socket
# cat /usr/lib/systemd/system/spice-vdagentd.socket [Unit] Description=Activation socket for spice guest agent daemon
[Socket] ListenStream=/run/spice-vdagentd/spice-vdagent-sock
$ systemctl status spice-vdagentd.service ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
$ systemctl status spice-vdagentd.socket ● spice-vdagentd.socket - Activation socket for spice guest agent daemon Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.socket; static) Active: active (listening) since Mon 2021-07-12 22:35:53 PDT; 1min 36s> Triggers: ● spice-vdagentd.service Listen: /run/spice-vdagentd/spice-vdagent-sock (Stream) CGroup: /system.slice/spice-vdagentd.socket
On 7/12/21 10:44 PM, ToddAndMargo via users wrote:
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
What on
ListenStream=/run/spice-vdagentd/spice-vdagent-sock
is the socket missing?
-T
# cat /usr/lib/systemd/system/spice-vdagentd.service
[Unit] Description=Agent daemon for Spice guests After=dbus.target Requires=spice-vdagentd.socket
[Service] Type=forking EnvironmentFile=-/etc/sysconfig/spice-vdagentd ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS PIDFile=/run/spice-vdagentd/spice-vdagentd.pid PrivateTmp=true Restart=on-failure
[Install] Also=spice-vdagentd.socket
# cat /usr/lib/systemd/system/spice-vdagentd.socket [Unit] Description=Activation socket for spice guest agent daemon
[Socket] ListenStream=/run/spice-vdagentd/spice-vdagent-sock
$ systemctl status spice-vdagentd.service ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
$ systemctl status spice-vdagentd.socket ● spice-vdagentd.socket - Activation socket for spice guest agent daemon Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.socket; static) Active: active (listening) since Mon 2021-07-12 22:35:53 PDT; 1min 36s> Triggers: ● spice-vdagentd.service Listen: /run/spice-vdagentd/spice-vdagent-sock (Stream) CGroup: /system.slice/spice-vdagentd.socket
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 13/07/2021 13:56, ToddAndMargo via users wrote:
On 7/12/21 10:44 PM, ToddAndMargo via users wrote:
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
What on
ListenStream=/run/spice-vdagentd/spice-vdagent-sock
is the socket missing?
I do not understand the question.
That is the socket that /usr/bin/spice-vdagent binds to when run from .bashrc, the --user systemd unit, or from konsole.
The action of spice-vdagent binding to the socket then triggers the spice-vdagentd (daemon).
On 7/12/21 11:09 PM, Ed Greshko wrote:
On 13/07/2021 13:56, ToddAndMargo via users wrote:
On 7/12/21 10:44 PM, ToddAndMargo via users wrote:
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
What on
ListenStream=/run/spice-vdagentd/spice-vdagent-sock
is the socket missing?
I do not understand the question.
In my host and all my other VM's, spice-vdagentd.service is running far before ~/.bashrc and far before logging in. I happens seconds after the kernel is selected
That is the socket that /usr/bin/spice-vdagent binds to when run from .bashrc, the --user systemd unit, or from konsole.
The action of spice-vdagent binding to the socket then triggers the spice-vdagentd (daemon).
It doesn't though
In KDE, spice-vdagentd.socket is not hearing spice-vdagent-sock to trugger spice-vdagentd.service.
"OR" the spice-vdagent is never happening
On 13/07/2021 14:23, ToddAndMargo via users wrote:
On 7/12/21 11:09 PM, Ed Greshko wrote:
On 13/07/2021 13:56, ToddAndMargo via users wrote:
On 7/12/21 10:44 PM, ToddAndMargo via users wrote:
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
What on
ListenStream=/run/spice-vdagentd/spice-vdagent-sock
is the socket missing?
I do not understand the question.
In my host and all my other VM's, spice-vdagentd.service is running far before ~/.bashrc and far before logging in. I happens seconds after the kernel is selected
That is because some other desktops will do that. KDE doesn't
That is the socket that /usr/bin/spice-vdagent binds to when run from .bashrc, the --user systemd unit, or from konsole.
The action of spice-vdagent binding to the socket then triggers the spice-vdagentd (daemon).
It doesn't though
In KDE, spice-vdagentd.socket is not hearing spice-vdagent-sock to trugger spice-vdagentd.service.
"OR" the spice-vdagent is never happening
OK.... Try this simple test.....
Reboot the KDE system. Then login via an SSH session. Not a graphical session.
You should then see....
egreshko@f34k2 ~]$ uptime 14:31:23 up 0 min, 1 user, load average: 1.73, 0.47, 0.16
[egreshko@f34k2 ~]$ ps -eaf | grep spice
I then send something to the socket and Ctrl-C to end the ncat session.
egreshko 1854 1828 0 14:31 pts/0 00:00:00 grep --color=auto spice [egreshko@f34k2 ~]$ ncat -U /run/spice-vdagentd/spice-vdagent-sock 0.21.0I ENTER SOMETHING ^C
[egreshko@f34k2 ~]$ ps -eaf | grep spice root 1859 1 0 14:32 ? 00:00:00 /usr/sbin/spice-vdagentd
Now the daemon is running, triggered by the ncat communication. And we se....
[egreshko@f34k2 ~]$ systemctl --no-pager -l status spice-vdagentd.service ● spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indirect; vendor preset: enabled) Active: active (running) since Tue 2021-07-13 14:32:07 CST; 39s ago TriggeredBy: ● spice-vdagentd.socket Process: 1858 ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (code=exited, status=0/SUCCESS) Main PID: 1859 (spice-vdagentd) Tasks: 3 (limit: 2328) Memory: 892.0K CPU: 27ms CGroup: /system.slice/spice-vdagentd.service └─1859 /usr/sbin/spice-vdagentd
Jul 13 14:32:07 f34k2.greshko.com systemd[1]: Starting Agent daemon for Spice guests... Jul 13 14:32:07 f34k2.greshko.com systemd[1]: Started Agent daemon for Spice guests. Jul 13 14:32:19 f34k2.greshko.com spice-vdagentd[1859]: unknown message from vdagent: 1313153097, ignoring
Because the daemon doesn't know what to do with "I ENTER SOMETHING.
On 7/12/21 11:36 PM, Ed Greshko wrote:
In my host and all my other VM's, spice-vdagentd.service is running far before ~/.bashrc and far before logging in. I happens seconds after the kernel is selected
That is because some other desktops will do that. KDE doesn't
That is what need to be fixed.
It will take me a while to configure ssh
On 13/07/2021 14:42, ToddAndMargo via users wrote:
On 7/12/21 11:36 PM, Ed Greshko wrote:
In my host and all my other VM's, spice-vdagentd.service is running far before ~/.bashrc and far before logging in. I happens seconds after the kernel is selected
That is because some other desktops will do that. KDE doesn't
That is what need to be fixed.
More of a "Feature" request than anything.
It will take me a while to configure ssh
Takes 2 seconds on the guest.
systemctl --now enable sshd
I think the default KDE firewall setup has port 22 open
On 13/07/2021 13:44, ToddAndMargo via users wrote:
Hi Ed,
I see the set up for the service and the socket.
What I am trying to figure out is why the socket is not being triggered to start the service.
Let me try this again.
Every thing below looks as it should.
At boot time, the spice-vdagentd.service is supposed to be *DEAD*. I showed you that to be the case in my previous post. It shows *DEAD*. That is NORMAL. That is The Way it Should be!
Then when /usr/bin/spice-vdagent is run. (no d at the end) it will connect to the socket /run/spice-vdagentd/spice-vdagent-sock this then *triggers* spice-vdagentd. And that then runs.
I showed all of that in my previous post.
And, I mentioned 2 says to get /usr/bin/spice-vdagent to run on login.
Why it didn't for you, I cannot comment without knowing the status after login.
-T
# cat /usr/lib/systemd/system/spice-vdagentd.service
[Unit] Description=Agent daemon for Spice guests After=dbus.target Requires=spice-vdagentd.socket
[Service] Type=forking EnvironmentFile=-/etc/sysconfig/spice-vdagentd ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS PIDFile=/run/spice-vdagentd/spice-vdagentd.pid PrivateTmp=true Restart=on-failure
[Install] Also=spice-vdagentd.socket
# cat /usr/lib/systemd/system/spice-vdagentd.socket [Unit] Description=Activation socket for spice guest agent daemon
[Socket] ListenStream=/run/spice-vdagentd/spice-vdagent-sock
$ systemctl status spice-vdagentd.service ○ spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indire> Active: inactive (dead) TriggeredBy: ● spice-vdagentd.socket
$ systemctl status spice-vdagentd.socket ● spice-vdagentd.socket - Activation socket for spice guest agent daemon Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.socket; static) Active: active (listening) since Mon 2021-07-12 22:35:53 PDT; 1min 36s> Triggers: ● spice-vdagentd.service Listen: /run/spice-vdagentd/spice-vdagent-sock (Stream) CGroup: /system.slice/spice-vdagentd.socket
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure