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
