Is Siduction any more stable than Sid with LXQT?

schnappi · 2017/09/26, 01:07:56

Hi,

Was having lots of problems with SId and LXQT (couldn't even shutdown correctly at one point). Is Siduction modified in any way to make it even a little more stable than Sid? Honestly Sid usually is pretty stable but for something like LXQT get why have been having issues.

Just wondering if can expect to have pretty much same issues if used Siduction or if there is some modifications that make Siduction even a little more stable than Sid. Live CD works fine and looks good by the way.

Thanks.

melmarker · 2017/09/26, 01:31:55

You had problems? I can't believe it, don't see any filed bugs.

schnappi · 2017/09/26, 01:38:17

Yep I know right?

Chalk it up to maybe the combination of hardware and software but yes was having issues with LXQT Sid to the point where deleted it and am just going to install something more out of box ready and a tiny bit more stable.

melmarker · 2017/09/26, 02:05:56

You know that we use the same packages as debian do? Esp. for LXQt. And i'm pretty sure every debian derivative does. So - bad luck, but a hint - writing good bugs might help, reading bugtrackers may help too. We nor debian nor upstream can help with problems we don't know.

(But maybe i'm completly wrong - maybe one with more LXQt knowledge should answer)

melmarker · 2017/09/26, 02:39:12

@schnappi: and your problem seems to be https://github.com/lxde/lxqt/issues/1311 - so there are only partial solutions that work more or less complete. And thats one of the reasons i mentioned filing bugs - your shutdown problem might be slightly better than in pure debian because we have the latest menu-cache and KillUserProcesses activated - but to be true, it solves nothing right now - and the system will shut down with enough patience - in case nothing helps the one-liner should help:

hard kill all panel processes, after that hard kill all menu-cached processes, after that shut down the system.

EDIT: ok, reducing the system time out and user time out for processes helps too. But it doesn't help to find and fix any problems as mentioned on the upstream bug.

dibl · 2017/09/26, 09:16:48

I run siduction/LXQT on a Dell laptop with Intel GPU that is 5 or 6 years old, and yes, I see the slow shutdown from CLI. It causes me no problems, but if I were in a hurry to shut it down, I would Ctrl-Alt-F1, login as root, and issue

Code Auswählen

systemctl poweroff

Other than that, it seems pretty stable.

EDIT: First

Code Auswählen

systemctl isolate multi-user.target
then

Code Auswählen

systemctl poweroff

melmarker · 2017/09/26, 19:55:02

@dibl - one should be more positive - it is infact so stable that it resist shut downs successful. Joke aside, it is a systemd thing, systemd is just to nice - much to nice - so this behaviour match perfect the systemd strategy: We are right, fix your f$%&ing apps that behave wrong. In System V one had paint it over with one ore two pkill -9 $disturbing_process.

And - so we've done. With the upcoming release it will only hang one or two times out of ten.

dibl · 2017/09/26, 20:14:48

Zitat@dibl, one should be more positive ...

LOL! In my house, there are five systems running the distro that won't be shut down -- that is VERY positive!

schnappi · 2017/09/27, 01:07:34

Wow. Cool active community. Reinstalled Debian Sid and it usually shuts down but as others stated still got it to hang on shutdown again a few times.

Probably should file bug reports but it takes forever to figure out who it should go to (Debian, PCMAN, LXQT) and then find out how to submit a bug for that given group. Just don't really have time and would rather concentrate on real life. But still love linux and do what can when can do it.

On a different note are there any other changes Siduction makes to Debian Sid that aren't immediately obvious from browsing the wiki?

dibl · 2017/09/27, 01:59:23

Speaking as a user, only ....

Yes, the Debian packages come only from the sid repo.

The new kernels are build by our hero, towo, and come from the siduction repo.

The grub splashes, kernel-remover, and some other packages come from the siduction repo. If you will follow a couple of simple rules, you should not have a problem with siduction:

1. Not less often than once per week:

Code Auswählen

apt update

Code Auswählen

apt full-upgrade -d

Ctrl-Alt F1, log in as root.

Code Auswählen

systemctl isolate multi-user.target

Code Auswählen

apt full-upgrade

If there is no new kernel, then

Code Auswählen

systemctl isolate graphical.target && exit

If there IS a new kernel installed, then

Code Auswählen

systemctl reboot

2. Look at the message from apt. Look for packages to be removed. If any packages are to be removed .... CAUTION!

Check this forum for Upgrade Warnings.

Sometimes we wait for a time, until the transition settles down and lets us have a safe upgrade.

melmarker · 2017/09/27, 02:16:24

@schnappi - and you don't need to file an issue for this particular issue - i know the problem, that should be sufficient - saying so with my LXQt Hat and my Debian Maintainer Hat on.

@dibl and systemd.isolate and such things are overkill. One can test this in the debug console. Just kill the fucking menu-cached process if it block the shut down is enough. Sorry - but menu-cached is buggy as hell, overcomplicated and not very debugging friendly to put it mild, the next version will be slightly better and should be released soon. In the end i will suggest to rewrite the entire caching from the scratch - less time intensive. And i'm dead sure that this will be acked by our devs. Until then - just set KillUserProcesses to true and lower the limit of:

Code Auswählen


system.conf:#DefaultTimeoutStopSec=90s
user.conf:#DefaultTimeoutStopSec=90s

to a sane value that don't hurt - i guess 5-10s should be enough time fore slower processes.

Edit: And please don't forget to remove the # if doing so

sidemmc · 2017/10/03, 12:23:42

Thank you for the hint, melmarker. It works fine on my acer TMB116-M, with both values set to 7 secs.
Grüße, sidemmc

GoinEasy9 · 2017/10/16, 00:28:23

Well, this thread gave me answers about the 90 second wait during shutdown.

I caused the machine to lock up during boot by setting the timers to 5 seconds. It stopped when trying to load the broadcom drivers, I guess they needed more time. So I restored them. I was too lazy to keep experimenting.

Just an FYI - I found that if you logout and click the shutdown icon from the login screen, there is no wait. At least for me.

Thanks for this thread, still exploring LXQt.

dibl · 2017/10/16, 11:03:43

On both KDE and LXQt, if you Ctrl-Alt-F1 to tty1, then

Code Auswählen

systemctl isolate multi-user.target

and then

Code Auswählen

systemctl poweroff

the system shuts down much faster.

melmarker · 2017/10/16, 12:07:48

for the brave LXQt users there might be another solution - add lxqt.debian.net/debian experimental-snapshots main to your sources and give it a go ..

Should be stable enough for daily usage - at least for me it is - we are sorted out a lot of things that block the damn menu-cached - it might help. Or just wait a little bit, i'm preparing the 0.12 release of LXQt right now. Will take a little bit time until it hit sid, some important packages stuck in NEW