Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #265238 > unrolled thread
| Started by | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| First post | 2023-12-25 04:40 +0100 |
| Last post | 2024-01-15 14:50 +0100 |
| Articles | 20 on this page of 63 — 6 participants |
Back to article view | Back to linux.debian.user
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 1 of 4 [1] 2 3 4 Next page →
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2023-12-25 04:40 +0100 |
| Subject | Change suspend type from kde menu |
| Message-ID | <HOJYR-fWET-5@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2023-12-27 22:00 +0100 |
| Message-ID | <HPJap-gxoP-9@gated-at.bofh.it> |
| In reply to | #265238 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-28 02:50 +0100 |
| Message-ID | <HPNH3-gA40-1@gated-at.bofh.it> |
| In reply to | #265315 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Franco Martelli <martellif67@gmail.com> |
|---|---|
| Date | 2023-12-28 15:50 +0100 |
| Message-ID | <HPZRT-gHne-19@gated-at.bofh.it> |
| In reply to | #265315 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2023-12-28 23:20 +0100 |
| Message-ID | <HQ6Tn-gLzJ-3@gated-at.bofh.it> |
| In reply to | #265331 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2023-12-29 00:20 +0100 |
| Message-ID | <HQ7Pr-gM81-3@gated-at.bofh.it> |
| In reply to | #265334 |
On Thu, 28 Dec 2023 23:17:06 +0100 Valerio Vanni <valerio.vanni@inwind.it> 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/
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2023-12-29 02:30 +0100 |
| Message-ID | <HQ9Rf-gNfl-3@gated-at.bofh.it> |
| In reply to | #265336 |
Il 29/12/2023 00:12, Charles Curley ha scritto: > On Thu, 28 Dec 2023 23:17:06 +0100 > Valerio Vanni <valerio.vanni@inwind.it> 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.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-29 03:00 +0100 |
| Message-ID | <HQakh-gNou-1@gated-at.bofh.it> |
| In reply to | #265337 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2023-12-29 23:00 +0100 |
| Message-ID | <HQt3z-gYGk-1@gated-at.bofh.it> |
| In reply to | #265338 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-02 19:20 +0100 |
| Message-ID | <HRRwR-kuX-5@gated-at.bofh.it> |
| In reply to | #265334 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Franco Martelli <martellif67@gmail.com> |
|---|---|
| Date | 2024-01-03 17:20 +0100 |
| Message-ID | <HSc8h-xq7-1@gated-at.bofh.it> |
| In reply to | #265423 |
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
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-03 17:50 +0100 |
| Message-ID | <HScBj-xAc-11@gated-at.bofh.it> |
| In reply to | #265442 |
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.)
[toc] | [prev] | [next] | [standalone]
| From | Arno Lehmann <al@its-lehmann.de> |
|---|---|
| Date | 2024-01-03 18:40 +0100 |
| Message-ID | <HSdnH-y5e-9@gated-at.bofh.it> |
| In reply to | #265445 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-04 15:10 +0100 |
| Message-ID | <HSwA1-Kr6-7@gated-at.bofh.it> |
| In reply to | #265445 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-04 16:30 +0100 |
| Message-ID | <HSxPr-Lwi-9@gated-at.bofh.it> |
| In reply to | #265505 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-05 18:00 +0100 |
| Message-ID | <HSVI5-117b-15@gated-at.bofh.it> |
| In reply to | #265510 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-05 20:00 +0100 |
| Message-ID | <HSXAd-12hH-1@gated-at.bofh.it> |
| In reply to | #265540 |
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.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. 2024-01-05T19:39:20.505334+01:00 newton NetworkManager[3208]: <info> [1704479960.5049] manager: sleep: wake requested (sleeping: yes enabled: yes) 2024-01-05T19:39:20.505722+01:00 newton ModemManager[3206]: <info> [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.305 44374 kaffeine valerio :1.305 user@1000.service - - :1.306 44374 kaffeine valerio :1.306 user@1000.service - - :1.307 44374 kaffeine valerio :1.307 user@1000.service - - org.kde.kaffeine 44374 kaffeine valerio :1.305 user@1000.service - - org.mpris.kaffeine 44374 kaffeine valerio :1.305 user@1000.service - - ------------------ after resume ------------------ 1.312 45857 kaffeine valerio :1.312 systemd-suspend.service - - :1.313 45857 kaffeine valerio :1.313 systemd-suspend.service - - :1.314 45857 kaffeine valerio :1.314 systemd-suspend.service - - org.kde.kaffeine 45857 kaffeine valerio :1.312 systemd-suspend.service - - org.mpris.kaffeine 45857 kaffeine valerio :1.312 systemd-suspend.service - - ------------------
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-01-05 20:10 +0100 |
| Message-ID | <HSXJT-12AJ-1@gated-at.bofh.it> |
| In reply to | #265540 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-05 20:20 +0100 |
| Message-ID | <HSXTz-12ES-5@gated-at.bofh.it> |
| In reply to | #265549 |
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
[toc] | [prev] | [next] | [standalone]
| From | Valerio Vanni <valerio.vanni@inwind.it> |
|---|---|
| Date | 2024-01-05 20:40 +0100 |
| Message-ID | <HSYcV-12Lw-9@gated-at.bofh.it> |
| In reply to | #265550 |
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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web