Re: Change suspend type from kde menu
Il 12/01/2024 22:51, Valerio Vanni ha scritto: As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) I found another issue: kaffeine also records DVB channels. So, if I stop play but it's recording, module cannot be removed. In method I find a "toggle instant record", but it doesn't help because it changes between on and off. If it's not recording and I "toggle", then it starts recording and grabs device. It doesn't seem simple to tell *if* it's recording.
Re: Change suspend type from kde menu
Il 14/01/2024 05:04, Max Nikulin ha scritto: lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. tags.so belongs to baloo-kf5, but "balooctl --status" says that it's disabled.
Re: Change suspend type from kde menu
On 13/01/2024 22:37, Valerio Vanni wrote: Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled. Which package does tags.so belong to in your case? I believe you that file indexer is disabled, but some components may still be called for reasons unclear for me. Maybe they do something useful. Leaking of file descriptors to child processes is not uncommon issue. Ideally both sides should take measures to avoid it, but to mitigate it is enough that any party handle file descriptors with care. However it is just my guess, maybe actual cause of the issue with tags.so is completely different. P.S. Years ago KDE developers decided to remove controls that allowed to disable file indexer. Otherwise nobody would use it since previous version caused enough troubles. Fortunately that times have gone.
Re: Change suspend type from kde menu
Il 13/01/2024 16:20, Max Nikulin ha scritto: And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved. In my system baloo is disabled.
Re: Change suspend type from kde menu
On 13/01/2024 04:39, Valerio Vanni wrote: Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop It seems implementation of MPRIS in kaffeine differs from what other KDE components expect. E.g. media control buttons does not appear on the lock screen. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. And this is one with a --lastchannel launch: lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lsof for the same process may be more informative, but currently it does not matter. Perhaps, opening devices in /dev/dvb, kaffeine does not set the O_CLOEXEC flag for open(2) (or does not call fcntl with FD_CLOEXEC). As a result, file descriptors leak to spawned processes. I suggest to reach a community more close to kaffeine (or maybe baloo) developers and ask if it could be improved.
Re: Change suspend type from kde menu
Il 12/01/2024 21:15, Franco Martelli ha scritto: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) Yes, it's what I'm going to try :-) Force module unloading cannot work, it requires a specific option in kernel config that I've never enabled. You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. The module does not support suspend / resume at all. If you boot the system, *don't* open kaffeine or anything, suspend and resume, module is already in an unworkable state.
Re: Change suspend type from kde menu
Il 12/01/2024 17:24, Max Nikulin ha scritto: On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. I'll try. It could make the script simpler. If I launch kaffeine without --lastchannel, it should work. That way I'd have to open tv interface by hand when I start kaffeine. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior. This is a file descriptors list of kioslave process, with a plain launch: lrwx-- 1 valerio valerio 64 12 gen 20.53 0 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 1 -> /dev/pts/1 lrwx-- 1 valerio valerio 64 12 gen 20.53 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.53 2 -> /dev/pts/1 lr-x-- 1 valerio valerio 64 12 gen 20.53 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.53 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.53 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.53 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.53 4 -> 'socket:[10323613]' And this is one with a --lastchannel launch: lr-x-- 1 valerio valerio 64 12 gen 20.52 0 -> 'pipe:[9256505]' lrwx-- 1 valerio valerio 64 12 gen 20.52 1 -> 'socket:[71658]' lrwx-- 1 valerio valerio 64 12 gen 20.52 19 -> '/memfd:pulseaudio (deleted)' lrwx-- 1 valerio valerio 64 12 gen 20.52 2 -> 'socket:[71658]' lr-x-- 1 valerio valerio 64 12 gen 20.52 25 -> /run/user/1000/dvbpipe.m2t l-wx-- 1 valerio valerio 64 12 gen 20.52 26 -> /run/user/1000/dvbpipe.m2t lrwx-- 1 valerio valerio 64 12 gen 20.52 3 -> 'anon_inode:[eventfd]' lr-x-- 1 valerio valerio 64 12 gen 20.52 31 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 12 gen 20.52 36 -> 'pipe:[9253331]' l-wx-- 1 valerio valerio 64 12 gen 20.52 37 -> 'pipe:[9253331]' lrwx-- 1 valerio valerio 64 12 gen 20.52 4 -> 'socket:[9247546]' lr-x-- 1 valerio valerio 64 12 gen 20.52 48 -> anon_inode:inotify lrwx-- 1 valerio valerio 64 12 gen 20.52 54 -> '/memfd:pulseaudio (deleted)' But perhaps it says nothing new.
Re: Change suspend type from kde menu
On 12/01/24 at 15:38, Valerio Vanni wrote: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button. I saw that in another post you have find the dbus object and method to stop/play Kaffeine: > Tried, it works on DVB play. > > dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop As Max replied to that post saying that you could avoid to kill Kaffeine now you can try to: - stop Kaffeine - rmmod the module (what happens if you force unloading: -f option) - suspend - resume - modprobe the module - play Kaffeine but I bet you've already realized that :) You can also try to not remove the module and check if stop Kaffeine, suspend/resume, play Kaffeine is enough. -- Franco Martelli
Re: Change suspend type from kde menu
On 12/01/2024 21:36, Valerio Vanni wrote: Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop The question is if this action can be a replacement for killing kaffeine before unloading the dvb kernel module. What is baloo's tags.so doing with /dev/dvb devices accordingly to lsof report? I still had a hope that there is a workarond against its annoying behavior.
Re: Change suspend type from kde menu
Il 12/01/2024 15:03, Franco Martelli ha scritto: On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Service org.mpris.kaffeine: Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? Yes, it has play/stop button.
Re: Change suspend type from kde menu
Il 12/01/2024 12:08, Valerio Vanni ha scritto: Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. Tried, it works on DVB play. dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Stop dbus-send --print-reply --dest=org.mpris.kaffeine /Player org.freedesktop.MediaPlayer.Play
Re: Change suspend type from kde menu
On 11/01/24 at 15:10, Valerio Vanni wrote: Yes, I tried, but I didn't see any "stop". There is a .Quit, but for this I already have "kill" command and I have to start it again. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / Out of curiosity could you post the output of the following command: ~$ busctl --user tree | grep mpris Don't forget to run Kaffeine first. Another question, can Kaffeine stop the video? Do you have a "Stop" button to click over? -- Franco Martelli
Re: Change suspend type from kde menu
Il 12/01/2024 03:52, Max Nikulin ha scritto: I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method - - - I saw that, but I think it's for media player component of kaffeine. With that, you could stop the play of an audio or video file. Do you think it can also act on DVB channels? I can give it a try. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Baloo is already disabled. Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From its stop, not from its start. There are two main cases: plain kaffeine and lastchannel one. I open kaffeine without options, I play a DVB channel. kioslave process is active, but has no lock on /dev/dvb/* I stop play and I can immediately remove module. Even if that kioslave process is active. I open kaffeine with --lastchannel, and kioslave process already has a lock on /dev/dvb/* I stop play and cannot remove module, it's locked from kioslave. When some minute has passed, kioslave disappears and I can remove module. Now I see another case: even during channel play, some time kioslave process disappears. At that point, if I stop play, I can remove module.
Re: Change suspend type from kde menu
On 11/01/2024 22:45, Valerio Vanni wrote: Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. busctl --user introspect org.mpris.kaffeine /Player # ... .Stop method- -- I have no idea if MPRIS API spec prescribes to implement /org/mpris/MediaPlayer2 or /Player /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket lsof, unlike ps, reports a kind of access, e.g. CWD why some file is opened. So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. Have you checked if the tags.so process opens some devices under /dev/dvb? An idea is that this process seizes its read attempts after some timeout. I would not expect it from an indexing framework. From my point of view it should read only regular files, otherwise it is a bug. I do not know which way file tags are implemented in KDE (a hidden file inside a directory or some DB in the user home directory), so it hard to reason why baloo holds something in /dev Maybe it is something with "recently used" (~/.local/share/recently-used.xbel), but I am unsure if kaffeine intentionally notifies desktop environment or it calls a method that is not appropriate in the context of /dev/ Finally I am confused. If tags.so processes die after some interval of time, does it mean that the kernel module can be unloaded even when kaffeine is started with --lastchannel and enough time has passed since its start? From another message: I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found" I can confirm it. Actually I was asking about "$kafdis XDG_CURRENT_DESKTOP=KDE", but Thunderbird broke formatting around. It has hidden notion of cited text and it affects wrapping in the case of flowed text format. E.g. "> some text" typed directly does not become a part of citation, it is necessary to paste "copy text" from clipboard using [Ctrl+Shift+O]. On the other hand "this line contains cited text" state may persist for lines having no text. Sometimes it happens during adding text between cited lines. I have not steps to reproduce suitable for bug report yet.
Re: Change suspend type from kde menu
Il 11/01/2024 16:25, Max Nikulin ha scritto: On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. It's what I think too. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy I don't have MediaPlayer2 there. /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. It seems to always die, I've never had an error during rmmod.
Re: Change suspend type from kde menu
Il 11/01/2024 15:21, Valerio Vanni ha scritto: Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I see that I must leave XDG_RUNTIME_DIR, if I remove it I get an error "Failed to connect to bus: No medium found"
Re: Change suspend type from kde menu
On 11/01/2024 21:10, Valerio Vanni wrote: There is a .Quit, but for this I already have "kill" command and I have to start it again. Applications might handle D-Bus messages more gracefully than SIGINT or SIGTERM signals. However in the case of kaffeine it is unlikely that some data may be lost. valerio@newton:~$ busctl --user introspect org.mpris.kaffeine / I assume that "org/mpris/MediaPlayer2" after "/" was lost during copy org.freedesktop.MediaPlayer interface - - - .Identity method - s - .MprisVersion method - (qq) - .Quit method - - - Looks quite useless. Does ".Stop" appear when kaffeine is playing some channel? lsof | grep /dev/dvb shows 10315 ? S 0:00 /lib/x86_64-linux-gnu/libexec/kf5/kioslave5 /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket So it is baloo (former nepomuk) search framework. A crazy idea is to add /dev to the list of directories that should not be indexed. I would try to disable baloo completely to see if behavior in respect to rmmmod changes. I am surprised that it dies immediately if you kill kaffeine. Actually I run out of ideas. It seems you have a working solution and further polishing is optional. On 10/01/2024 01:32, Valerio Vanni wrote: So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice. By mistake, I tried something like (missed --user) setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --slice=app.slice -- \ xterm and I wrongly decided that systemd *user* session rejects D-Bus messages basing on some process attributes, e.g. looking into /proc/PID/sessionid (set by pam_loginuid) and comparing it with logind state (loginctl list-sessions). The user is not added to any groups with higher privileges. Fortunately proper command works and no tricks are required besides setting the path where D-Bus socket should be found.
Re: Change suspend type from kde menu
Il 11/01/2024 04:57, Max Nikulin ha scritto: On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? It's all left there from when I used setpriv to launch directly kaffeine, before I decided to use systemd-run. I'll try to remove it, now I checked and they are all listed in systemd user environment. I find it not really safe to use $kafdis without quotes. Yes, neither I liked to catch that string. But I considered it a temporary solution.
Re: Change suspend type from kde menu
Il 11/01/2024 05:10, Max Nikulin ha scritto:
On 10/01/2024 01:59, Valerio Vanni wrote:
Il 06/01/2024 17:38, Max Nikulin ha scritto:
I would expect something like "Stop" either from /Player or from
org.mpris.kaffeine.
I too expected something similar: stop and play (play for resume)
Have you tried "tree" and "introspect" for org.mpris.kaffeine (not
org.kde.kaffeine)? It works for mpv:
Yes, I tried, but I didn't see any "stop". There is a .Quit, but for
this I already have "kill" command and I have to start it again.
valerio@newton:~$ busctl --user introspect org.mpris.kaffeine /
NAMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.Identity method- s-
.MprisVersion method- (qq) -
.Quit method- --
busctl --user call org.mpris.MediaPlayer2.mpv \
/org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \
Stop
For this we don't need to look here:
"rmmod: ERROR: Module cx23885 is in use" seems enough to see that
kernel module cannot be removed.
I am surprised by it. You have shown that kaffeine closes the device, so
it should be possible to remove the kernel module:
Started with --lastchannel
Video stopped:
lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128
lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0
lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0
no more /dev/dvb/, but still unable to remove module cx23885
My hypotheses:
- there are more kaffeine processes (ps xuwf)
No, it has only one.
- some external process is holding the device, e.g. pulseaudio or
pipeware sound server. Tools that might help to find it: lsof or fuser
(unsure concerning proper options)
- Some other IPC exposed by the driver and used by kaffeine.
- I have not idea if it is possible to create direct connection between
the dvb device and the video card so that data pass without intermediate
interaction with kaffeine.
fuser -a /dev/dvb/adapter0/demux0 shows nothing
lsof | grep /dev/dvb shows
10315 ?S 0:00
/lib/x86_64-linux-gnu/libexec/kf5/kioslave5
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/tags.so tags
local:/run/user/1000/kaffeinerCGcGi.1.kioworker.socket
But after some minutes this process disappeared, and I could rmmod.
Perhaps with --lastchannel it's slower to release it?
Re: Change suspend type from kde menu
Il 11/01/2024 04:48, Max Nikulin ha scritto: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). I agree. If cx23885 module could handle suspend/resume, we wouldn't need all this mess. Since we are talking about this module, I quote from another of your messages: P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device? The module is autoloaded when system boots. But if I (after having moved away the script from /usr/lib/systemd/system-sleep/) rmmod systemctl-suspend resume pc the module is not loaded. When I used pm-suspend, remove and reload was managed from the line SUSPEND_MODULES="cx23885" in /etc/pm/config.d/modules And now from rmmod and modprobe in my script. By itself... no load. The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. To watch television, kaffeine seems very good to me.
Re: Change suspend type from kde menu
On 10/01/2024 01:59, Valerio Vanni wrote: Il 06/01/2024 17:38, Max Nikulin ha scritto: I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) Have you tried "tree" and "introspect" for org.mpris.kaffeine (not org.kde.kaffeine)? It works for mpv: busctl --user call org.mpris.MediaPlayer2.mpv \ /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player \ Stop For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. I am surprised by it. You have shown that kaffeine closes the device, so it should be possible to remove the kernel module: Started with --lastchannel Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 My hypotheses: - there are more kaffeine processes (ps xuwf) - some external process is holding the device, e.g. pulseaudio or pipeware sound server. Tools that might help to find it: lsof or fuser (unsure concerning proper options) - Some other IPC exposed by the driver and used by kaffeine. - I have not idea if it is possible to create direct connection between the dvb device and the video card so that data pass without intermediate interaction with kaffeine.
Re: Change suspend type from kde menu
On 10/01/2024 04:43, Valerio Vanni wrote: Il 07/01/2024 06:44, Max Nikulin ha scritto: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" > $kafdis XDG_CURRENT_DESKTOP=KDE \ ---^^^ Do you really need it? I find it not really safe to use $kafdis without quotes. The pattern in grep is rather loose one, it may capture several variables and some of variables may have spaces in their values. On the other hand the current pattern should capture WAYLAND_DISPLAY. The point is that kaffeine inherits environment from systemd user session. I have all necessary variables set in systemctl --user show-environment My command works for me without explicit environment tricks. systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 P.S. You have explicit modprobe cx23885. Does it mean that this module is not autoloaded when udev discovers the device?
Re: Change suspend type from kde menu
On 11/01/2024 02:32, Valerio Vanni wrote: Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. It is independent ideas: - Do not deal with user processes in system context (like /usr/lib/systemd/system-sleep/ scripts) - Try to release dvb tuner device, so module can be unloaded. I believe, it is a bug in the cx23885 module that it can not handle suspend/resume (and probably hibernate/thaw). The following is related to avoiding "setpriv" in system context and listening for D-Bus events in user session scope: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" suspend: signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep^^^ boolean true resume: signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false ---^ A tiny python script may be more convenient than dbus-monitor and similar tools. Killing and starting kaffeine in response to these signals may be a workaround if the application does not allow to release the device. Not stopping playback and not releasing the device in response to the PrepareForSleep signal, from my point of view, is a bug in kaffeine. I have no idea if vlc (broken hardware acceleration in bookworm) or another application may be an alternative for you. Stopping playback through D-Bus by a custom script might be performed either from PrepareForSleep D-Bus signal listener or from a system-sleep script. I will respond to another message.
Re: Change suspend type from kde menu
Il 08/01/2024 04:29, Max Nikulin ha scritto: On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: So your idea would be stopping and starting channel play by dbus messages? I'm looking again with introspect, and I don't see anything like "stop" in kaffeine. $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools. It seems too complex for me.
Re: Change suspend type from kde menu
Il 07/01/2024 06:44, Max Nikulin ha scritto: It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well. It works :-) setpriv --reuid="$kafuid" --regid="$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ systemd-run --user --slice=app.slice /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Even during resume it goes into right slice.
Re: Change suspend type from kde menu
Il 06/01/2024 17:38, Max Nikulin ha scritto: On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I too expected something similar: stop and play (play for resume) If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. For this we don't need to look here: "rmmod: ERROR: Module cx23885 is in use" seems enough to see that kernel module cannot be removed. Compare opened file descriptors when video is playing and when it is stopped. Started with --lastchannel Video playing: lr-x-- 1 valerio valerio 64 9 gen 19.47 0 -> /dev/null lrwx-- 1 valerio valerio 64 9 gen 19.47 34 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.47 35 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.47 40 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 41 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 42 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 43 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.47 44 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.47 55 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 56 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 57 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 59 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.47 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.47 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.51 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.51 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.51 9 -> /dev/dri/card0 no more /dev/dvb/, but still unable to remove module cx23885 Started without --lastchannel Video playing: lrwx-- 1 valerio valerio 64 9 gen 19.56 37 -> /dev/dvb/adapter0/frontend0 lr-x-- 1 valerio valerio 64 9 gen 19.56 43 -> /dev/dvb/adapter0/dvr0 lr-x-- 1 valerio valerio 64 9 gen 19.56 47 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 49 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 50 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 51 -> /dev/dvb/adapter0/demux0 lr-x-- 1 valerio valerio 64 9 gen 19.56 52 -> /dev/dvb/adapter0/demux0 lrwx-- 1 valerio valerio 64 9 gen 19.56 58 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 59 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 60 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 Video stopped: lrwx-- 1 valerio valerio 64 9 gen 19.56 6 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 62 -> /dev/dri/renderD128 lrwx-- 1 valerio valerio 64 9 gen 19.56 7 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 8 -> /dev/dri/card0 lrwx-- 1 valerio valerio 64 9 gen 19.56 9 -> /dev/dri/card0 It all seems like before, but this time module can be removed.
Re: Change suspend type from kde menu
Il 06/01/2024 16:19, Max Nikulin ha scritto: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. I confirm, it's under system.slice. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. I don't see authentication requests, but it still stays under system.slice.
Re: Change suspend type from kde menu
On 07/01/2024 12:44, Max Nikulin wrote: setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm Instead of tricks with setting proper context for a process executed system-wide, I would consider a process running in user sessions and listening for D-Bus events: $ dbus-monitor --system "type='signal',interface='org.freedesktop.login1.Manager',member='PrepareForSleep'" dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.1080" (uid=1000 pid=48803 comm="dbus-monitor --system type='signal',interface='org") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping. signal time=1704679328.754948 sender=org.freedesktop.DBus -> destination=:1.1080 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1080" signal time=1704679441.870349 sender=:1.6 -> destination=(null destination) serial=3187 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean true signal time=1704679448.065409 sender=:1.6 -> destination=(null destination) serial=3233 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep boolean false A tiny python script may be more convenient than dbus-monitor and similar tools.
Re: Change suspend type from kde menu
On 06/01/2024 22:19, Max Nikulin wrote: On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. setpriv --reuid 1000 --regid 1000 --init-groups --reset-env -- \ env XDG_RUNTIME_DIR="/run/user/1000" \ systemd-run --user --slice=app.slice -- \ xterm I have realized that earlier I forgot to add --user to systemd-run. To my surprise, it does not work if I set BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" instead of XDG_RUNTIME_DIR. I expected that the former is required for systemd-run. This command works from a root shell prompt, I hope it should work during resume as well.
Re: Change suspend type from kde menu
On 06/01/2024 00:07, Valerio Vanni wrote: Now I'm looking: services are ├─/MainApplication ├─/Player ├─/Television ├─/TrackList └─/org └─/org/kde └─/org/kde/kaffeine I tried to introspect the more likely, MainApplication and Television .RemoveProgram method u - - Do you have any idea what it should do? I would expect something like "Stop" either from /Player or from org.mpris.kaffeine. I have not tried MPRIS D-Bus interface in action though. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. What should I find here? If no file descriptor is resolved to /dev/ (or maybe /sys) then likely the kernel module may be removed without killing the application. Compare opened file descriptors when video is playing and when it is stopped.
Re: Change suspend type from kde menu
On 06/01/2024 19:44, Valerio Vanni wrote: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 I have not figured out how to do it, but systemd-run should not use --uid since this way it makes the application a part of system.slice. Instead the application should be in app.slice that is a child of user@1000.service. Inspect output of systemd-cgls. So systemd-run should talk to the systemd --user instance. I have tried to set XDG_RUNTIME_DIR="/run/user/1000" BUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" in setpriv ... env, but systemd requires authentication. It seems neither su nor sudo add process to the user context (proper cgroup, XDG session), so attempts to talk to the systemd user session through D-Bus fail. I tried command from a ssh session root@... Behavior may be different from suspend/resume tasks since the session is associated with a pty.
Re: Change suspend type from kde menu
Il 06/01/2024 01:04, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke I tried the options when I tried systemd-run, but it didn't work. I only added them, but now I see that you have to choose: or them or setpriv. Now it's: systemd-run --unit=kaffeine-resumed --uid="$kafuid" --gid="$kafgid" \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 Outcome is the same. The only difference is that a line is added to syslog about unit creation: Started kaffeine-resumed.service - /usr/bin/env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel.
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 11:37:41PM +0100, Valerio Vanni wrote: > This way works, I don't know if it has security flaws. > > systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid > "$kafgid" --init-groups --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 > systemd-run(1) appears to have its own --uid and --gid options. If you can live without supplementary groups and the variables that are set by --reset-env, you can probably drop the setpriv part and just use systemd-run's --uid and --gid. On the other hand, if it ain't broke
Re: Change suspend type from kde menu
Il 05/01/2024 21:47, Valerio Vanni ha scritto: Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine. This way works, I don't know if it has security flaws. systemd-run --unit=kaffeine-resumed setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /dev/null 2>&1 All is launched from systemd-run. I choosed kaffeine-resumed as unit name, but if you don't put any a casual name one is created. So systemd-suspend.service unit is free and can close.
Re: Change suspend type from kde menu
Il 05/01/2024 21:24, Valerio Vanni ha scritto: For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. If I use "su" method instead of "setpriv" one, kaffeine doesn't go into systemd-suspend.service unit, and neither to user@1000.service one. Instead, it goes to session-c2.scope. And works. And systemd-suspend.service is finished and deactivated at the moment of resume. It seems that systemd-suspend.service wants to end as soon as possible, but it cannot because it has kaffeine inside. So it waits 90 seconds, and then terminates kaffeine.
Re: Change suspend type from kde menu
Il 05/01/2024 20:47, Franco Martelli ha scritto: On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & If I add that final &, kaffeine doesn't start at all. For what I've seen, the issue is that kaffeine is started in another unit, systemd-suspend.service instead of user@1000.service. systemd-suspend.service is deactivated after 90 seconds from resume, and kaffeine is shut down some msec before. And I found now that whole script cannot continue after this "takeover": final "rm" commands are not run. - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend.
Re: Change suspend type from kde menu
On 05/01/24 at 20:01, Greg Wooledge wrote: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. Could it be that he doesn't run Kaffeine in the background? ... /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 & ^ Cheers, -- Franco Martelli
Re: Change suspend type from kde menu
Il 05/01/2024 20:10, Valerio Vanni ha scritto: My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand If I remove --reset-env and set HOME, kaffeine starts. It seems that issue was to find file in home directory. But still in systemd-suspend.service unit. If, in a root shell, I launch setpriv --reuid 1000 --regid 1000 --init-groups \ env XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 HOME=/home/valerio XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 kaffeine starts in user@1000.service. Also with --reset-env. It's only during resume that it gets into systemd-suspend.service.
Re: Change suspend type from kde menu
Il 05/01/2024 20:01, Greg Wooledge ha scritto: On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later. If you see my latest message, it goes in a different unit and is shut down at the end of resume. Perhaps I could try to remove --reset-env and set some parameter by hand
Re: Change suspend type from kde menu
On Fri, Jan 05, 2024 at 05:52:43PM +0100, Valerio Vanni wrote: > setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups > --reset-env \ > env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis > XDG_CURRENT_DESKTOP=KDE \ > /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 > - > Uid, gid and display are saved and restored, so it can works also for other > users and x servers. > But with setpriv kaffeine was complaining it couldn't find .config/, > database etc and so it wasn't able to start. It seems that was ignorming > original user's home and tried to access root home. > > Adding the parameter --reset-env seems to fix, kaffeine restarts. > But, after some minutes, it closes. I don't understand why. My first guess would be that you also need $HOME to be set, or perhaps the current working directory, or both. --reset-env sets HOME, SHELL, USER, LOGNAME and PATH. That seems like a reasonable addition. I have no idea why it crashes later.
Re: Change suspend type from kde menu
Il 05/01/2024 17:52, Valerio Vanni ha scritto: Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute I looked better: it lasts 90 seconds. Not from kaffeine launch, from PC resume. If I try to set a delay inside the script, so that kaffeine launches after 80 seconds, it starts and then after 10 seconds it's closed. If I set the delay after 90 seconds, it doesn't start at all. I tried to redirect output to a file /usr/bin/kaffeine --lastchannel > /home/valerio/kaffeine_log_resumed 2>&1 The file is created and gets data, but nothing is added at the moment of termination. In syslog I found these lines at that moment: - 2024-01-05T19:39:20.40+01:00 newton kded5[14911]: Service ":1.299" unregistered 2024-01-05T19:39:20.491999+01:00 newton ksmserver[16627]: org.kde.kmix: Could not get icon for "audio-card-analog-pci" 2024-01-05T19:39:20.494975+01:00 newton kwin_x11[14912]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 18596, resource id: 134217740, major code: 15 (QueryTree), minor code: 0 2024-01-05T19:39:20.501014+01:00 newton systemd[1]: systemd-suspend.service: Deactivated successfully. 2024-01-05T19:39:20.501146+01:00 newton systemd[1]: Finished systemd-suspend.service - System Suspend. 2024-01-05T19:39:20.501227+01:00 newton systemd[1]: systemd-suspend.service: Consumed 1min 10.023s CPU time. 2024-01-05T19:39:20.501296+01:00 newton systemd[1]: Stopped target sleep.target - Sleep. 2024-01-05T19:39:20.501404+01:00 newton systemd[1]: Reached target suspend.target - Suspend. 2024-01-05T19:39:20.501662+01:00 newton systemd[1]: Stopped target suspend.target - Suspend. 2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]: [1704479960.5049] manager: sleep: wake requested (sleeping: yes enabled: yes) 2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]: [sleep-monitor-systemd] system is resuming -- It seems that something of resume process is ending 90 seconds after resume. And Service ":1.299" that gets unregistered is just kaffeine. And now I see a difference between kaffeine launched by hand and resumed one: busctl --user | grep kaffeine with manual start -- :1.30544374 kaffeinevalerio :1.305user@1000.service - - :1.30644374 kaffeinevalerio :1.306user@1000.service - - :1.30744374 kaffeinevalerio :1.307user@1000.service - - org.kde.kaffeine 44374 kaffeinevalerio :1.305user@1000.service - - org.mpris.kaffeine44374 kaffeinevalerio :1.305user@1000.service - - -- after resume -- 1.31245857 kaffeinevalerio :1.312systemd-suspend.service - - :1.31345857 kaffeinevalerio :1.313systemd-suspend.service - - :1.31445857 kaffeinevalerio :1.314systemd-suspend.service - - org.kde.kaffeine 45857 kaffeinevalerio :1.312systemd-suspend.service - - org.mpris.kaffeine45857 kaffeinevalerio :1.312systemd-suspend.service - - --
Re: Change suspend type from kde menu
Il 04/01/2024 17:11, Max Nikulin ha scritto:
On 04/01/2024 22:21, Valerio Vanni wrote:
Il 04/01/2024 15:48, Max Nikulin ha scritto:
Is it really necessary to kill kaffeine or it is enough to pause or
to stop playing? It might be possible using a D-Bus query.
[...]
If it's started normally, it's enough to stop playing
But how would you try to request it to stop?
I would play with "busctl --user", "busctl --user tree SERVICE", "busctl
--user introspect SERVICE OBJECT" to figure out if suitable methods are
available.
I never used busctl.
Now I'm looking: services are
├─/MainApplication
├─/Player
├─/Television
├─/TrackList
└─/org
└─/org/kde
└─/org/kde/kaffeine
I tried to introspect the more likely, MainApplication and Television
/MainApplication
AMETYPE SIGNATURE RESULT/VALUE
FL>
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method- s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method- s -
.Ping method- - -
org.freedesktop.DBus.Properties interface - - -
.Getmethodssv -
.GetAll methods a{sv} -
.Setmethodssv - -
.PropertiesChanged signalsa{sv}as - -
org.qtproject.Qt.QApplication interface - - -
.aboutQtmethod- - -
.autoSipEnabled method- b -
.closeAllWindowsmethod- - -
.setAutoSipEnabled methodb - -
.setStyleSheet methods - -
lines 1-17
/Television
AMETYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - --
.Introspect method- s-
org.freedesktop.DBus.Peer interface - --
.GetMachineId method- s-
.Ping method- --
org.freedesktop.DBus.Properties interface - --
.Getmethodssv-
.GetAll methods a{sv}-
.Setmethodssv --
.PropertiesChanged signalsa{sv}as --
org.freedesktop.MediaPlayer interface - --
.DigitPressed methodi --
.ListProgramSchedulemethod- a(uib) -
.PlayChannelmethods --
.PlayLastChannelmethod- --
.RemoveProgram methodu --
If it's started with "-lastchannel" no, you have to close it.
But then you have also to request it to play again.
Is there an action that releases the device? "ls -l /proc/PID/fd" to check.
What should I find here?
Ideally kaffeine should implement the Inhibit interface and should close
devices on suspend or on user session switch.
Ideally...
Re: Change suspend type from kde menu
Il 04/01/2024 16:27, Greg Wooledge ha scritto: On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: Il 03/01/2024 17:41, Greg Wooledge ha scritto: The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html Thank you. Now I'm trying this way: - #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kafpid=$(pgrep kaffeine) kafuid=$(stat -c "%u" /proc/$kafpid) kafgid=$(stat -c "%g" /proc/$kafpid) kafdis=$(cat /proc/$kafpid/environ | tr '\0' '\n' | grep DISPLAY) echo $kafuid > /temp/kafuid.txt echo $kafgid > /temp/kafgid.txt echo $kafdis > /temp/kafdis.txt kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) kafuid=$(cat /temp/kafuid.txt) kafgid=$(cat /temp/kafgid.txt) kafdis=$(cat /temp/kafdis.txt) if [[ $kaffeine_killed == "" ]]; then setpriv --reuid "$kafuid" --regid "$kafgid" --init-groups --reset-env \ env XDG_RUNTIME_DIR=/run/user/"$kafuid" $kafdis XDG_CURRENT_DESKTOP=KDE \ /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 fi rm -f /temp/kafstate.txt rm -f /temp/kafuid.txt rm -f /temp/kafgid.txt rm -f /temp/kafdis.txt ;; esac - Uid, gid and display are saved and restored, so it can works also for other users and x servers. But with setpriv kaffeine was complaining it couldn't find .config/, database etc and so it wasn't able to start. It seems that was ignorming original user's home and tried to access root home. Adding the parameter --reset-env seems to fix, kaffeine restarts. But, after some minutes, it closes. I don't understand why. -Kaffeine launched by hand stays up -Kaffeine restored with "su" method stays up -Kaffeine restored with "setpriv" method lasts only some minute
Re: Change suspend type from kde menu
On 04/01/2024 22:21, Valerio Vanni wrote: Il 04/01/2024 15:48, Max Nikulin ha scritto: Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. [...] If it's started normally, it's enough to stop playing But how would you try to request it to stop? I would play with "busctl --user", "busctl --user tree SERVICE", "busctl --user introspect SERVICE OBJECT" to figure out if suitable methods are available. If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again. Is there an action that releases the device? "ls -l /proc/PID/fd" to check. Ideally kaffeine should implement the Inhibit interface and should close devices on suspend or on user session switch.
Re: Change suspend type from kde menu
On Thu, Jan 04, 2024 at 03:07:59PM +0100, Valerio Vanni wrote: > Il 03/01/2024 17:41, Greg Wooledge ha scritto: > > The su command is not an ideal choice for this, in fact. The setpriv(1) > > command is better suited for running programs as other user accounts, > > without doing crazy PAM stuff like su does. > > Can you explain better? http://jdebp.info/FGA/dont-abuse-su-for-dropping-privileges.html
Re: Change suspend type from kde menu
Il 04/01/2024 15:48, Max Nikulin ha scritto: On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed. I choosed to kill it because it seemed easier. If it's started normally, it's enough to stop playing But how would you try to request it to stop? If it's started with "-lastchannel" no, you have to close it. But then you have also to request it to play again.
Re: Change suspend type from kde menu
On 04/01/2024 21:03, Valerio Vanni wrote: kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 Is it really necessary to kill kaffeine or it is enough to pause or to stop playing? It might be possible using a D-Bus query. My expectation is that the device should be closed.
Re: Change suspend type from kde menu
Il 03/01/2024 17:41, Greg Wooledge ha scritto: The UID of 1000 will have to be verified, as well as the YOURUSER. UID 1000 is what Debian uses for the initial user account that's created during installation, but if for some reason that's not the account who's currently logged in, then obviously this won't work. In my case it's ok The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. Can you explain better? It also has the advantage of not needing a username -- it can work with just the UID. uid=1000 gid=1000 setpriv --reuid "$uid" --regid "$gid" --init-groups \ env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \ keffeine >/dev/null 2>&1 & In a (used like a) single user system like this, I know both username and uid. In a multi-user one, you have to find them. And it doesn't seem simple.
Re: Change suspend type from kde menu
Il 03/01/2024 23:52, Valerio Vanni ha scritto: Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. Now I've done this, to relaunch only if it was running: -- #!/bin/bash case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending kaffeine_killed=$(/usr/bin/killall kaffeine 2>&1) echo $kaffeine_killed > /temp/kafstate.txt /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 kaffeine_killed=$(cat /temp/kafstate.txt) if [[ $kaffeine_killed == "" ]]; then /usr/bin/su valerio -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine --lastchannel >/dev/null 2>&1 &' fi rm -f /temp/kafstate.txt ;; esac --
Re: Change suspend type from kde menu
Il 03/01/2024 17:18, Franco Martelli ha scritto: On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: I had an idea to do a relaunch, but it's not always running. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. I'll do :-)
Re: Change suspend type from kde menu
Am 03.01.2024 um 17:41 schrieb Greg Wooledge:
...
Bear in mind that this entire approach is a bit of a hack, with some
baked-in assumptions about who's logged in on which DISPLAY. If this
works for you, then that's great.
Manually restarting whatever application was affected would be simpler,
but...
But some people might need to extend
this to check for the actual logged-in account, rather than assuming it's
the primary user. (Left as an exercise, because unfortunately there is
no good way to do that, as far as I know anyway.)
I would start with something like
w | awk -e '$3==":0" { print $1 }'
A cleaner approach would be to record what was killed in the pre-suspend
phase and recreate that post wakeup, in my opinion.
Cheers,
Arno
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
Re: Change suspend type from kde menu
On Wed, Jan 03, 2024 at 05:18:19PM +0100, Franco Martelli wrote: > /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000 > DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &' > In place of YOURUSER you've to put your username, if you doubt the command > "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and > DISPLAY have the same value that I set, use the command "echo $variableName" > to verify. The UID of 1000 will have to be verified, as well as the YOURUSER. UID 1000 is what Debian uses for the initial user account that's created during installation, but if for some reason that's not the account who's currently logged in, then obviously this won't work. The su command is not an ideal choice for this, in fact. The setpriv(1) command is better suited for running programs as other user accounts, without doing crazy PAM stuff like su does. It also has the advantage of not needing a username -- it can work with just the UID. uid=1000 gid=1000 setpriv --reuid "$uid" --regid "$gid" --init-groups \ env XDG_RUNTIME_DIR=/run/user/"$uid" DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE \ keffeine >/dev/null 2>&1 & Bear in mind that this entire approach is a bit of a hack, with some baked-in assumptions about who's logged in on which DISPLAY. If this works for you, then that's great. But some people might need to extend this to check for the actual logged-in account, rather than assuming it's the primary user. (Left as an exercise, because unfortunately there is no good way to do that, as far as I know anyway.)
Re: Change suspend type from kde menu
On 02/01/24 at 19:15, Valerio Vanni wrote: This way, I don't have to remember to close kaffeine before suspend. If you have Kaffeine always running on your system you can try this script: #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending /usr/bin/killall kaffeine /usr/bin/sleep 2 /usr/sbin/rmmod cx23885 ;; post) #code execution AFTER resuming /usr/sbin/modprobe cx23885 /usr/bin/sleep 3 /usr/bin/su YOURUSER -c 'XDG_RUNTIME_DIR=/run/user/1000 DISPLAY=:0 XDG_CURRENT_DESKTOP=KDE /usr/bin/kaffeine >/dev/null 2>&1 &' /usr/bin/sleep 1 ;; esac exit 0 In place of YOURUSER you've to put your username, if you doubt the command "whoami" will tell you. Check if XDG_RUNTIME_DIR, XDG_CURRENT_DESKTOP and DISPLAY have the same value that I set, use the command "echo $variableName" to verify. In the end don't put your script in /usr/sbin or /usr/bin use /usr/local/bin or /usr/local/sbin instead. Cheers -- Franco Martelli
Re: Change suspend type from kde menu
Il 28/12/2023 23:17, Valerio Vanni ha scritto: I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 Now I've made a little change: #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/tv-sleep exit 0 and tv-sleep does: #!/bin/bash /usr/bin/killall kaffeine sleep 2 /usr/sbin/rmmod cx23885 This way, I don't have to remember to close kaffeine before suspend. At this point, there's a couple of improvements from pm-suspend method. One is this, the other is that pm-suspend required sudo.
Re: Change suspend type from kde menu
Il 29/12/2023 02:53, Max Nikulin ha scritto: systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case. It seems to me something that should be done from an application. For example, in my case kaffeine could: stop dvb stream, unload module, and inverse actions after resume. But it wouldn't help: it would work only if kaffeine is open. This kernel module is unable to be suspended and resumed regardless of applications.
Re: Change suspend type from kde menu
On 29/12/2023 08:26, Valerio Vanni wrote: Il 29/12/2023 00:12, Charles Curley ha scritto: That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. systemd-sleep(8) does not mention /etc/systemd/system-sleep/ I am a bit puzzled by the following: https://www.freedesktop.org/software/systemd/man/latest/systemd-sleep.html Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to react to system suspend/hibernation and resume, they should rather use the Inhibitor interface. https://www.freedesktop.org/wiki/Software/systemd/inhibit/ From my point of view dealing with D-Bus just to unload a kernel module is inconvenient. It is not an application that is started before suspend and should be running after resume. I am curious what is the recommended way for this particular use case.
Re: Change suspend type from kde menu
Il 29/12/2023 00:12, Charles Curley ha scritto: On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". This way it doesn't work. I don't have an /etc/systemd/system-sleep directory. I created it by hand, but scripts inside are ignored.
Re: Change suspend type from kde menu
On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni wrote: > /usr/lib/systemd/system-sleep/dvb-suspend.sh That may work, but by putting the script in /usr/lib/systemd, you run the risk of it being clobbered on the next update to systemd. Better to put it in /etc/systemd/system-sleep/. Files in /etc/systemd over-ride their analogs in /usr/lib/systemd, so it should continue to work. You may need to do a "systemctl daemon-reload". -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Change suspend type from kde menu
Il 28/12/2023 15:48, Franco Martelli ha scritto: Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh I found that pm-suspend works because it unloads and reloades that module In "/etc/pm/config.d/modules" there is --- SUSPEND_MODULES="cx23885" --- Now I've replicated this on systemd side with this script similar to yours: /usr/lib/systemd/system-sleep/dvb-suspend.sh --- #!/bin/bash [ "$1" = "post" ] && exec /usr/sbin/modprobe cx23885 [ "$1" = "pre" ] && exec /usr/sbin/rmmod cx23885 exit 0 --- This way it works, both with "systemctl suspend" and from kde menu.
Re: Change suspend type from kde menu
On 27/12/23 at 21:54, Valerio Vanni wrote: Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. My system, if I don't restart Picom, freeze after a resume from suspend. To fix it I've placed this shell script in "/usr/lib/systemd/system-sleep/" directory ~$ cat /usr/lib/systemd/system-sleep/00_sleep.sh #!/bin/sh # Run from systemd-suspend.service to place under /usr/lib/systemd/system-sleep/ PATH=/sbin:/usr/sbin:/bin:/usr/bin case "$1" in pre) #code execution BEFORE sleeping/hibernating/suspending ;; post) #code execution AFTER resuming /usr/bin/sleep 5 /usr/bin/touch /home/frank/.config/picom.conf /usr/bin/sleep 1 ;; esac exit 0 So I think you've to do the same once you'll have a system that suspend to RAM properly. kind regards -- Franco Martelli
Re: Change suspend type from kde menu
On 28/12/2023 03:54, Valerio Vanni wrote: -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running. I have never tried to tune suspend systemd settings, but I would try to create a single-shot service with "ExecStart=rmmod cx23885" that is "WantedBy" and "Before" suspend.target. Perhaps it is possible to find more details related to suspend.target and hibernate.target.
Re: Change suspend type from kde menu
Il 25/12/2023 04:25, Valerio Vanni ha scritto: Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that It seems that kde uses "systemctl suspend": if I use it from shell, result is bad as if I suspend from menu. The defective kernel module cx23885: it doesn't support suspend and resume. It's a module for a DVB-T PCIe card. If I'm using kaffeine to watch DVB-T channels, I have to close it before suspending. If I leave it opened, kernel module comes up in a broken state. Closing and opening again kaffeine doesn't help, I have to -close kaffeine -rmmod cx23885 -modprobe cx23885 -open kaffeine This happens suspending with pm-suspend. Using systemctl, kernel module is broken after every suspend, even if kaffeine is not running.
Change suspend type from kde menu
Is there any way to change the way system is suspended from kde menu and from power saving in kde settings? I mean changing the command issued. I don't know exactly what the default command is, probably systemctl. /usr/sbin/pm-suspend works better with kernel modules, and I'd like to use that
