View previous topic :: View next topic |
Author |
Message |
G3nt00 Guru
Joined: 09 Apr 2023 Posts: 337
|
Posted: Thu May 04, 2023 10:22 am Post subject: |
|
|
Goverp wrote: | Logicien wrote: | I think it's a good idea to compile in a Linux terminal (tty1,6) because those terminals do not depend on the Xorg state. Your desktop screen can be freeze and if Ctrl+alt+Fx conduct you to the Linux terminal where your emerge world is running, you can continue to compile as if nothing had happen and use an other Linux terminal to manage the system.
The problem is if Xorg freeze it can make freeze the frambuffer too and the whole system. This is why I ping a freezed system from an other machine in my local network. If there is an answer maybe a hard poweroff can be advoid specially if you can connect to it using ssh. |
I've remembered another more insidious problem with running emerges from a GUI desktop terminal - something, I suspect related to systemd, even though I don't have that installed, seems to reduce the priority of long-running threads in such a window when it loses focus. I'd start an emerge, and all would be well, and the fans would spin loudly , but about 5 minutes later having switched to say my browser, the fans would stop, and stay stopped until I went back to the emerge window! This happens on both Wayland and X11. It might be KDE-specific, but my hunch is it's somewhere else in the system. It doesn't happen with ttys.
Whatever, the recommendation is to run emerges in a tty window using something like tmux or screen to get the scrollback window.
(Actually, I thought someone had returns the terminal scrolling to framebuffers like it was about Kernel 3 but I don't recall a setting to enable it. Both screen and tmux have, IMHO, far too many bells and whistles, and horrible magic key mixtures when all I really want is PgUp and PgDn !) |
Interesting! So guess it either will be tmux or a tty from now on when I know it will take time, thanks for sharing! |
|
Back to top |
|
|
Logicien Veteran
Joined: 16 Sep 2005 Posts: 1555 Location: Montréal
|
Posted: Thu May 04, 2023 5:43 pm Post subject: |
|
|
Firefox detect when he run an older version in memory than the one who is installed after and upgrade and ask to restart. How many applications detect that the librairie who installed they ask for is for a newer version of the application than the one who run in memory? This can lead to tricky things.
In text mode, Linux terminal, you have less applications who run and can be confuse by an upgrade. But stay the possibility to upgrade the base binaries but I never seen any problem on this. As G3nt00 say, he have not expect that hibernation would start when emerge run but say that the resume was successfull as emerge continue it work normally. Was emerge sleeping during hibernation, yes I think as well in memory than on the swap partition on the hard disk. _________________ Paul |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9690 Location: almost Mile High in the USA
|
Posted: Thu May 04, 2023 11:05 pm Post subject: |
|
|
After a library is dynamically linked, that copy is permanent until it disengages it or restarts (like most software in general) regardless of what overwrote the file. New files are not actually overwriting, they're put in a different spot, and old running programs get their own mapping of the old file until they quit.
Most of these automatic detection of current running versions is through a dbus or its own socket. Older software depend on pid files or don't care at all, that can be tricky...
I kind of figure that some software now will reduce priority of any windows and its children when they're in the background. Not exactly traditional unix but that's what cgroups can do...
I've used gnu-screen for long enough it's pretty much my goto despite some fairly recent crash bugs. I couldn't get into tmux, that's how bad I've gotten used to screen. I used to use splitvt but screen usurped that for the most part (occasionally I'll run it inside of screen). I've screened so hard that I am kind of used to running screen inside of screen and still can control the sessions :) Only trouble I have with screen is when itself gets upgraded and changes its socket and I've locked myself out of screen sessions when 'accidentally' upgrading screen while using it. Now I avoid upgrading it when using it...
Oh and don't ask me to run screen inside of screen inside of screen (i.e., 3 layers or more deep)... Now that I'll probably go bonkers. Then I might have to look into tmux. _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
sam_ Developer
Joined: 14 Aug 2020 Posts: 1685
|
Posted: Fri May 05, 2023 6:01 am Post subject: |
|
|
Someone's filed bug 905440, possibly inspired by this discussion, fwiw. |
|
Back to top |
|
|
G3nt00 Guru
Joined: 09 Apr 2023 Posts: 337
|
Posted: Fri May 12, 2023 4:09 am Post subject: |
|
|
sam_ wrote: | Someone's filed bug 905440, possibly inspired by this discussion, fwiw. |
Thanks for sharing! It sounds from that that this has sparked something that may possibly improve stability if implemented |
|
Back to top |
|
|
G3nt00 Guru
Joined: 09 Apr 2023 Posts: 337
|
Posted: Fri May 12, 2023 4:11 am Post subject: |
|
|
normscruze wrote: | I was just thrown out of my Gnome session while using my keyboard...! Things locked up for a second, then screen locked! NOT happy. |
Exactly what was happening to my session as well. Fingers crossed the filed bug leads to something blocking this behaviour |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|