Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265238 > unrolled thread

Change suspend type from kde menu

Back to article view | Back to linux.debian.user

Contents

  Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-25 04:40 +0100
    Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-27 22:00 +0100
      Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2023-12-28 02:50 +0100
      Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2023-12-28 15:50 +0100
        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-28 23:20 +0100
          Re: Change suspend type from kde menu Charles Curley <charlescurley@charlescurley.com> - 2023-12-29 00:20 +0100
            Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-29 02:30 +0100
              Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2023-12-29 03:00 +0100
                Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2023-12-29 23:00 +0100
          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-02 19:20 +0100
            Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-03 17:20 +0100
              Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-03 17:50 +0100
                Re: Change suspend type from kde menu Arno Lehmann <al@its-lehmann.de> - 2024-01-03 18:40 +0100
                Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 15:10 +0100
                  Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-04 16:30 +0100
                    Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 18:00 +0100
                      Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:00 +0100
                      Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-05 20:10 +0100
                        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:20 +0100
                          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 20:40 +0100
                        Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-05 20:50 +0100
                          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 21:30 +0100
                            Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 21:50 +0100
                              Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 23:40 +0100
                                Re: Change suspend type from kde menu Greg Wooledge <greg@wooledge.org> - 2024-01-06 01:10 +0100
                                  Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-06 13:50 +0100
                                    Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-06 16:30 +0100
                                      Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-07 06:50 +0100
                                        Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:40 +0100
                                          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-10 20:40 +0100
                                            Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 04:50 +0100
                                              Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 14:50 +0100
                                        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 22:50 +0100
                                          Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 05:00 +0100
                                            Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 15:30 +0100
                                              Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 16:40 +0100
                                      Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 19:40 +0100
              Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 00:00 +0100
                Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 15:10 +0100
                  Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-04 15:50 +0100
                    Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-04 16:30 +0100
                      Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-04 17:20 +0100
                        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-05 18:10 +0100
                          Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-06 17:40 +0100
                            Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-09 20:00 +0100
                              Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 05:20 +0100
                                Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 15:20 +0100
                                  Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-11 16:30 +0100
                                    Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-11 16:50 +0100
                                      Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-12 04:00 +0100
                                        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 12:10 +0100
                                          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 15:40 +0100
                                            Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-12 17:30 +0100
                                              Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 22:40 +0100
                                                Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-13 16:30 +0100
                                                  Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-13 16:40 +0100
                                                    Re: Change suspend type from kde menu Max Nikulin <manikulin@gmail.com> - 2024-01-14 05:10 +0100
                                                      Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-15 14:40 +0100
                                  Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-12 15:10 +0100
                                    Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 15:40 +0100
                                      Re: Change suspend type from kde menu Franco Martelli <martellif67@gmail.com> - 2024-01-12 21:20 +0100
                                        Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-12 23:00 +0100
                                          Re: Change suspend type from kde menu Valerio Vanni <valerio.vanni@inwind.it> - 2024-01-15 14:50 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#265552

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

[toc] | [prev] | [next] | [standalone]

#265553

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.488880+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.

[toc] | [prev] | [next] | [standalone]

#265554

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.488880+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.

[toc] | [prev] | [next] | [standalone]

#265558

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.

[toc] | [prev] | [next] | [standalone]

#265561

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....

[toc] | [prev] | [next] | [standalone]

#265582

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.

[toc] | [prev] | [next] | [standalone]

#265587

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.

[toc] | [prev] | [next] | [standalone]

#265603

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.

[toc] | [prev] | [next] | [standalone]

#265638

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.

[toc] | [prev] | [next] | [standalone]

#265756

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.

[toc] | [prev] | [next] | [standalone]

#265769

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.

[toc] | [prev] | [next] | [standalone]

#265787

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.

[toc] | [prev] | [next] | [standalone]

#265730

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.

[toc] | [prev] | [next] | [standalone]

#265770

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?

[toc] | [prev] | [next] | [standalone]

#265790

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.

[toc] | [prev] | [next] | [standalone]

#265794

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"

[toc] | [prev] | [next] | [standalone]

#265724

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.

[toc] | [prev] | [next] | [standalone]

#265459

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 :-)

[toc] | [prev] | [next] | [standalone]

#265503

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

----------------------

[toc] | [prev] | [next] | [standalone]

#265506

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web