repowerd fails to start after recent upgrades

[mithrandir]

After performing the latest updates repowerd fails to start form me. Thus i.e. standby on close does not work any more.

root@gemini:/home/gemini# journalctl --unit=repowerd|cat
-- Logs begin at Tue 2019-01-15 18:12:52 CET, end at Tue 2019-01-15 18:32:29 CET. --
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: main: Starting repowerd 2017.03
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: SysfsBacklight: Using backlight /sys/class/leds/lcd-backlight
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: Loading module: 'libubuntu_application_api_touch_mirclient.so.3.0.0'
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: Unable to load selected module, using dummy.
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: Loading module: 'libubuntu_application_api_test.so.3.0.0'
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: TestSensor INFO: Setup for DYNAMIC event injection over named pipe /tmp/sensor-fifo-1473
Jan 15 18:12:54 gemini.mittelerde.ldr repowerd[1473]: TestSensor WARNING: Requested sensor light not yet created, blocking thread until create event received

However, I cannot find any information on libubuntu_application_api_touch_mirclient.so. It looks like recently this got used by (at least it worked before) libubuntu_application_api.so.

root@gemini:/usr/lib/aarch64-linux-gnu# egrep -r touch_mirclient
Binary file libubuntu_application_api.so.3.0.0 matches

One of these updates seems to have caused the problem:

Start-Date: 2019-01-14  01:24:11
Commandline: apt upgrade
Requested-By: gemini (100000)
Upgrade: libsystemd0:arm64 (232-25+deb9u6, 232-25+deb9u7), udev:arm64 (232-25+deb9u6, 232-25+deb9u7), libudev1:arm64 (232-25+deb9u6, 232-25+deb9u7), systemd-sysv:arm64 (232-25+deb9u6, 232-25+deb9u7), libpam-systemd:arm64 (232-25+deb9u6, 232-25+deb9u7), systemd:arm64 (232-25+deb9u6, 232-25+deb9u7)
End-Date: 2019-01-14  01:24:28

Start-Date: 2019-01-14  02:25:59
Commandline: apt remove desktop-mirror
Requested-By: gemini (100000)
Remove: desktop-mirror:arm64 (0.8.1)
End-Date: 2019-01-14  02:26:01

Start-Date: 2019-01-14  20:46:08
Commandline: apt upgrade
Requested-By: gemini (100000)
Upgrade: qtdeclarative5-ubuntu-telephony-phonenumber0.1:arm64 (0.2+gemian+0~20190112143006.17~1.gbp1b2b0b, 0.2+gemian+0~20190114151319.18~1.gbp784b7f), qtdeclarative5-ubuntu-telephony0.1:arm64 (0.2+gemian+0~20190112143006.17~1.gbp1b2b0b, 0.2+gemian+0~20190114151319.18~1.gbp784b7f), gemian-leds:arm64 (0.2+0~20190109163524.18~1.gbp42eccd, 0.2+0~20190114170611.20~1.gbp05ed0a), telephony-service:arm64 (0.2+gemian+0~20190112143006.17~1.gbp1b2b0b, 0.2+gemian+0~20190114151319.18~1.gbp784b7f)
End-Date: 2019-01-14  20:46:14

Start-Date: 2019-01-14  23:42:36
Commandline: apt upgrade
Requested-By: gemini (100000)
Install: libubuntu-application-api3:arm64 (3.0.3+gemian+0~20181125114448.15~1.gbp734b8b, automatic), libubuntu-platform-hardware-api3:arm64 (3.0.3+gemian+0~20181125114448.15~1.gbp734b8b, automatic), ubuntu-application-api3-test:arm64 (3.0.3+gemian+0~20181125114448.15~1.gbp734b8b, automatic)
Upgrade: repowerd-data:arm64 (2017.03+gemian+0~20181111171657.32~1.gbp0646ca, 2017.03+gemian+0~20190114210411.41~1.gbp3a0332), libzmq5:arm64 (4.2.1-4, 4.2.1-4+deb9u1), gemian-lock:arm64 (2.10+0~20180429112217.12~1.gbp94657a, 2.10+0~20190114215247.15~1.gbp2b698d), repowerd:arm64 (2017.03+gemian+0~20181111171657.32~1.gbp0646ca, 2017.03+gemian+0~20190114210411.41~1.gbp3a0332)
End-Date: 2019-01-14  23:44:14

Start-Date: 2019-01-15  02:10:44
Commandline: apt upgrade
Requested-By: gemini (100000)
Upgrade: qtdeclarative5-ubuntu-telephony-phonenumber0.1:arm64 (0.2+gemian+0~20190114151319.18~1.gbp784b7f, 0.2+gemian+0~20190114210353.19~1.gbpf74835), qtdeclarative5-ubuntu-telephony0.1:arm64 (0.2+gemian+0~20190114151319.18~1.gbp784b7f, 0.2+gemian+0~20190114210353.19~1.gbpf74835), telephony-service:arm64 (0.2+gemian+0~20190114151319.18~1.gbp784b7f, 0.2+gemian+0~20190114210353.19~1.gbpf74835)
End-Date: 2019-01-15  02:10:47

Is anybody else facing the same problem? Ideas how to fix or where to get the missing lib (assuming it is the cause)?

Thx+regards
Mith

[mithrandir]

Manually installing ubuntu-application-api3-touch solved the problem.

apt install ubuntu-application-api3-touch

In the first place I have searched for a libxyz package, since the dependent package also starts with lib. The naming scheme seems a bit weird...
Imho ubuntu-application-api3-touch should be dependency of repowerd.
Mith

[ArchiMark]

Thanks for sharing this, mithrandir!

Mark

[Eric BF]

I recently upgraded this tool but had no problems, I guess because the ubuntu*touch package was already installed, probably for some other package that depends on this.

I wonder if I could ask a related question: how does one use this tool, i.e. through the repowerd-cli command, to actually effect any changes in the system? The repowerd daemon does recognize that I am opening or closing the lid but I cannot get it to, say, suspend when lid is closed.  Any pointers would be welcome.

(apologies if I broke forum policy by slightly hijacking the thread; I can start a new post if so.)

[mithrandir]

I recently upgraded this tool but had no problems, I guess because the ubuntu*touch package was already installed, probably for some other package that depends on this.

I wonder if I could ask a related question: how does one use this tool, i.e. through the repowerd-cli command, to actually effect any changes in the system? The repowerd daemon does recognize that I am opening or closing the lid but I cannot get it to, say, suspend when lid is closed.  Any pointers would be welcome.

(apologies if I broke forum policy by slightly hijacking the thread; I can start a new post if so.)

Adamboardman has fixed the issue really fast after he got to know. Most likely you have updated after he has added the dependency.

Suspend when closing the lid works for me here. Which kernel are you using?
Maybe you can get some hints from the source: https://github.com/gemian/repowerd

Mith

[Eric BF]

Suspend when closing the lid works for me here. Which kernel are you using?

I am using, according to uname:

Code: [Select]

Linux gemini 3.18.41 #1 SMP PREEMPT Wed Nov 28 17:10:01 UTC 2018 aarch64 GNU/Linux
Edit: checked apt and I am behind on kernel version as there is a new one dated earlier this month. I'll install that in a week or so (I'm relying on my Gemini for work and don't want to gamble until I can do without it, just in case...).

I'll have a look at the code just in case I can figure something out. The key difference is I am not using the default window manager (lxde?) so maybe something is not being configured.

Thanks.

[Eric BF]

So, I've upgraded my system, including the new kernel and various X packages etc. I see no difference in terms of repowerd for my normal use case.

However, the problem is not with repowerd; it is with my window manager of choice (stumpwm). If I switch to the default lxqt window manager, the lid action works. So, my question is: how can I get stumpwm to do the same? In other words, where/how does lxqt configure repowerd to get the behaviour I want? I don't need help with stumpwm; I need help telling repowerd to do what I want!

Mind you, using the power management settings in lxqt and changing the behaviour of the lid to "suspend" seems to have no effect. The display is turned off but nothing else happens. WiFi remains enabled. What does "suspend" mean in the Gemini case?

Thank you.

Edit: explicitly running /usr/bin/lxqt-powermanagement when in stumpwm seems to do the job. The lid closing turns off the screen.  Making progress!

[Adam Boardman]

So when I was figuring out how to make this work I was bashing my head against this idea that the 'on' key gets squashed as one of the keys when the device is closed. Put this together with repowerd being from the UTouch/Mir land so its feed of the user activity to block suspend was not working with X11 on gemian.

The best I could figure at the time was to add a screen lock launched with xss-lock (gemian-lock), this then indicates back to repowerd that we can now suspend, and was also to eat any stray keypresses that were sneaking out on device close between hall switch and screen off.

In the last week or so I've re-worked the keyboard driver so that it blocks all keys when the device is closed directly rather than via the frame buffer on/off state. So far it looks like the direct blocking is a significant improvement in terms of stray keys, so we could review the need for such an active lock, once people have all updated to a fresh kernel (you should have a build date of 31 Jan 2019, 18:25:35).

For the moment if you want the device to sleep you need to run xss-lock gemian-lock, or a script that triggers the same dbus message as gemian-lock, see: https://github.com/gemian/gemian-lock/blob/..._event_sink.cpp you could trigger a dbus message based upon the lid switch?

General advice is against using the lid-watcher but that is as it conflicts with gemain-lock, so you might be able to use that with your own scripts if your against using gemain-lock.

There are known issues with wifi on suspend continually reconnecting and eating battery, so current advice is to disable wifi if you plan on leaving the device for any length of time, to help with this the outside LED's now have rotating colour displays to indicate which services are active (wifi=green).

[Eric BF]

Thanks for the update!  Very informative.

I think I'm at a happy place: the lid closing now turns off the display which was my main concern. I am happy to manually turn off WiFi as sometimes I want to have it on even when the lid is closed as I ssh into my Gemini quite often.

I'm curious about what you mean by rotating colour display but I'm sure it'll make sense when I upgrade the kernel!

[Adam Boardman]

Something else should have pulled it in as a dependency, gemian-leds is the component. I suspect you would have noticed if it was installed. But if not it comes highly recommended, even if just for the caps lock indicator. If your going the manual config route then you might want to also look at the gemian-leds-scripts for examples of how to animate some nice patterns.

[Eric BF]

Something else should have pulled it in as a dependency, gemian-leds is the component.

I do have gemian-leds installed and the leds light up (blue for bluetooth, green for wifi). It's the "rotating" element I don't understand. Mind you, nothing lights up with caps lock so maybe I'm not using the package appropriately. On the other hand, I'm not sure how useful it would be to have caps lock indicated when you cannot see the led while typing?

[Adam Boardman]

Sorry seems I might have confused you, the Caps LED is inside the device, just above the tab/caps key.

Rotating as in old gemian-leds the colours mix so cellular+bluetooth+wifi gave you a solid 'white' light, new gemian-leds gives you rotating colours so for all on you'd see red, then blue, then green.

[mithrandir]

Sorry seems I might have confused you, the Caps LED is inside the device, just above the tab/caps key.

Rotating as in old gemian-leds the colours mix so cellular+bluetooth+wifi gave you a solid 'white' light, new gemian-leds gives you rotating colours so for all on you'd see red, then blue, then green.

Now you confused me, because with new gemian-leds I have the old behavior. It turned out this is due to I have been running an animation. After running clear-anim I get the new rotating behavior. When starting an animation again (i.e. anim-red-side-to-side) the old behavior of the status led returns. Is this a bug or is it intended, maybe for technical reasons?

[Eric BF]

And I'm no less confused! I never even noticed that there was an LED above the TAB key (not sure what that says about my observation skills...). How do I actually invoke gemian-leds? Sounds like quite a useful tool but there is no obvious (man, /usr/share/doc) documentation.

Thank you.

[Adam Boardman]

Mith - Yes it falls back to old style mixing for the moment whilst there is an animation displayed on the block of five, I did contemplate doing a first run through the animation to find out its length, pick opportune points within it to then blend in the rotating c+w+b as needed, but decided there were more important things to work on first, also I wanted some user feedback as to whether the blending or rotating was more acceptable, to know whether it would be worth the effort. Personally I intend to use block of five animations for short term notifications so a slight degradation of readability of the c+w+b indicator LED is of no grate consequence, I only use that to remind me to turn wifi off before I go to sleep each night. It may also be of interest to know that during a call that particular indicator LED is stolen for the higher priority of telling you red is mic, green is earpiece, annoyingly the LED the other end next to the power one, is not the same colour green so it looks a bit odd. Not that the orientation stuff is pushed yet, or fully functional.

Eric - Its just a service that observes a bunch of stuff in terms of dbus messages, so you just have to install it, which you have, so I see no reason for it to not be active for you? However if you've gone off the reservation then its up to you to fix it to work for your divergence, or find someone else to fix it for you. Currently it fits the repowerd+connman+lxqt-globalkeys+sddm family of components.