Date: Mon, 11 Sep 2017 17:34:05 -0600 From: Ian Lepore <ian@freebsd.org> To: Morgan Reed <morgan.s.reed@gmail.com>, Vick Khera <vivek@khera.org> Cc: FreeBSD Stable List <stable@freebsd.org> Subject: Re: entropy lockup Message-ID: <1505172845.32063.90.camel@freebsd.org> In-Reply-To: <CAKnh_YsW5DsZ5=Z-bdM2XAG2UrkDotCxVz5EdCY6ZqWzvWS8rg@mail.gmail.com> References: <CALd%2Bdcd6bG%2BNpk=PEwSGJEbC-EQb57MwjKh9xG38S-a50CK3TA@mail.gmail.com> <CAKnh_YsW5DsZ5=Z-bdM2XAG2UrkDotCxVz5EdCY6ZqWzvWS8rg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2017-09-12 at 09:20 +1000, Morgan Reed wrote: > In all likelihood the process wasn't "hung" per-se, more likely > random > hadn't been seeded yet and as such you *can't* get 4096b of entropy > out of > it (so the process was attempting to do its job, just nothing on the > device). >=20 > The issue is basically that there are very few "good" entropy sources > in a > VM environment, and as such (particularly on a machine which is only > running SSH) there's not enough data available to seed random. >=20 > Check 'man 4 random' for some discussion. >=20 The save-entropy files get written from a crontab entry. =A0That means the system is already up and running, which means it's well past the point of hanging because it needs to be seeded. =A0Once it is seeded, it can never "run out of entropy". So all in all, this is a genuine problem of some sort. =A0The fact that the save-entropy process has accumulated 48+ minutes of cpu time is another problem indicator. =A0The process state is RL, runnable and waiting to acquire a lock, which seems contradictory (unless that means it's waiting for a spinlock maybe). -- Ian > On Tue, Sep 12, 2017 at 12:02 AM, Vick Khera <vivek@khera.org> wrote: >=20 > >=20 > > I just had a VM running in Google's cloud become totally useless, > > and I > > tracked it down to the save-entropy operation. > >=20 > > Basically this process was sucking up all CPU, even when nothing > > else > > running other than my ssh shell: > >=20 > > % ps axuw803 > > USER=A0=A0=A0=A0=A0PID=A0=A0%CPU %MEM=A0=A0VSZ=A0=A0RSS TT=A0=A0STAT = STARTED=A0=A0=A0=A0=A0TIME COMMAND > > operator 803 100.0=A0=A00.1 8336 2096=A0=A0-=A0=A0RL=A0=A0=A008:55=A0= =A0=A048:20.14 dd > > if=3D/dev/random of=3Dsaved-entropy.1 bs=3D4096 count=3D1 > >=20 > >=20 > > The process is unkillable, and I cannot even get the system to shut > > down. > > That has been hanging for about 10 minutes so far, with the last > > output > > being > >=20 > > System shutdown time has arrive90 second watchdSep 11 09:50:02 > > yertle init: > > /bin/sh on /etc/rc.shutdown terminated abnormally, going to single > > user > > mode > > Sep 11 09:50:47 init: some processes would not die; ps axl advised > > Waiting (max 60 seconds) for system process `vnlru' to stop... done > > Waiting (max 60 seconds) for system process `bufdaemon' to stop... > > done > > Waiting (max 60 seconds) for system process `syncer' to stop... > > Syncing disks, vnodes remaining... 4 4 4 4 4 4 4 timed out > > 2 2 2 2 2 2 2 > >=20 > >=20 > > Running FreeBSD 11.1-p1 on a 1CPU standard machine in GCE. > >=20 > > What's the proper recovery from this kind of lockup, or how to > > prevent it? > > I've never encountered this on a bare metal system, or other KVM > > based > > machines. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebs > > d.org" > >=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1505172845.32063.90.camel>