[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: System unusably slow after Debian upgrade.



Tixy wrote: 
> On Fri, 2020-02-28 at 06:45 -0500, Dan Ritter wrote:
> > Dan Ritter wrote: 
> > > Go to /etc/nsswitch.conf
> > > 
> > > If these lines look like this
> > > 
> > > passwd:         compat systemd
> > > group:          compat systemd
> > > shadow:         compat systemd
> > > 
> > > remove the systemd references.
> > > 
> > > If performance improves immensely immediately after the edit,
> > > that was the problem.
> > 
> > On re-reading the original complaint, I am nearly convinced that
> > this is the problem.
> > 
> > A ridiculously decelerated gzip is evidence of one of the
> > following:
> > 
> > - CPU throttling
> > - disk errors
> > - something interfering with the disk reading or writing
> > 
> > The failure mode for systemd providing nsswitch services is a
> > huge delay of lookup times for every passwd or group entry
> > which affects every file open. gzip opens a lot of files.
> 
> Huh? You mean a glibc goes to talk to systemd on every fopen? Surely,
> file access permissions are handled by the kernel, otherwise you could
> just bypass checks by directly using the 'open' syscall.

The data source of translating UID and GID is handled by
nsswitch. Usually it's "files", which means /etc/passwd,
/etc/shadow, and /etc/group. It could be ldap, it could be
nis, it could be some other service.

At some point systemd decided that it needed to interpose
itself. I have witnessed this failure mode on two or three
machines: when the systemd keyword is inserted but systemd
doesn't actually handle the call, every stat call (not open,
sorry) delays for many seconds. The machine does nothing.

Symptoms:

An operation that doesn't involve file opening happens without
delay. Run emacs and it's painful waiting for it to start, but
internal operations are as fast as ever.

load averages aren't affected.

-dsr-


Reply to: