Re: [gentoo-user] KDE weirdness after upgrade past Sunday.

[james]

On 3/4/20 11:16 AM, Dale wrote:
> Jack wrote:
>> On 3/4/20 8:41 AM, Dale wrote:
>>> All the timing of the above problems are very similar.� I believe they
>>> have the same cause.� When I finished my updates, I logged out, went to
>>> boot runlevel, used checkrestart to make sure everything that needed to
>>> be restarted was clean, restarted any that weren't and then when back to
>>> default runlevel.� In the past this has always worked fine.� Thing is,
>>> elogind is in the boot runlevel.� I'm going to have to get used to
>>> restarting it manually I guess.� Could elogind be the cause of all
>>> this?� Would it be safe to put elogind in the default runlevel?� That
>>> would solve the problem of me forgetting to restart it after upgrades.
>>> Or would some other service in the boot runlevel start it as a
>>> dependency anyway??
>>>
>>> When I get to a point where I can logout and back in, I'll test
>>> restarting elogind to see if it helps.� Thing is, I'm not really sure
>>> what all elogind does but from what little I know, it sounds like a good
>>> place to start.� Thing that confuses me, checkrestart not showing it
>>> needed to be restarted.� It's never failed me before.
>>
>> I was recently in a similar position (but not such serious effects)
>> but discovered that elogind refused to restart.� The message was that
>> it wouldn't start because it was already started, but that implies
>> that it simply failed to stop, without producing any error message.� I
>> didn't want to fight it any further, so I just rebooted.
>>
>> Jack
>>
>>
>>
>
>
> So elogind is a pretty good suspect.� One reason I'm asking about this,
> I'm trying to figure out how elogind fails.� After all, if I'm stuck on
> a console, I can't use Seamonkey or anything to find help.� I need to be
> able to recognize what is failing.� So far, I've yet to find where
> elogind problems are logged.
>
> When you run into the problem with a stuck script, don't forget the zap
> option.� I'd recommend using ps aux | grep <name> to make sure it is
> killed and if not kill it with kill first.� After you use the zap
> option, it should start it normally, the start option.� In case you have
> never heard of this, it looks like this:
>
>
> /etc/init.d/chronyd zap
>
>
> Hope that helps.� Thanks for the reply.
>
> Dale
>
> :-)� :-)

Hello Dale,

Truthfully, I learned, after much pain, decades ago, to keep at least 
(2) working gentoo systems, just to avoid catastrophic situations....

Used PC's, if running a minimalistic desktop, are pretty fast. Cross 
compile and copy over the updates, or there are many ways to keep old 
gentoo systems, active.

I also picked up a recent laptop, with a 1G traditional Hard Drive, for 
under $500.00. It's way faster than my '8350' AMD systems, until the 
Kernel-10.0 + starts using the video cards for compiling *everything* 
automagically.  Kernel-10.x is suppose to be a 'game-changer' for older 
hardware, speeding up compiling, tremendously.

I put 'thermaltake-watercoolers 3.0' on all my chassis based gentoo 
systems, at about $80/unit. Keeping the cpu cooled, allows for faster 
speeds. My 8350's run at 4GHz and can easily gain 25% clocking to 5GHz. 
I use sensors
to monitor temperatures:

'watch -n5 sensors -f'

If I were you, I'd figure out a second, graphical Gentoo system, on the 
cheap; as it can be used to fix most 'borked gentoo' systems, 
particularly if the best tools are setup and ready, just for gentoo_repair.


hth,
James