I first got to know I.F. Stone when I came across an article by Jon -Schwarz on The Intercept -about -his extraordinary contribution to investigative journalism in -USA. The article is about a new documentary in two parts -(part one is 12 minutes and -part two is 30 minutes), and -I found both truly fascinating. It is amazing what he was able to -find by digging up public sources and government papers. He -documented lots of government abuse and cover ups, and I find -his weekly news letters -inspiring to read even today.
+ +Over the years, administrating thousand of NFS mounting linux +computers at the time, I often needed a way to detect if the machine +was experiencing NFS hang. If you try to use df or look at a +file or directory affected by the hang, the process (and possibly the +shell) will hang too. So you want to be able to detect this without +risking the detection process getting stuck too. It has not been +obvious how to do this. When the hang has lasted a while, it is +possible to find messages like these in dmesg:
-All governments are run by liars and nothing they say should be believed. -- -
- I. F. Stone +nfs: server nfsserver not responding, still trying +
nfs: server nfsserver OK
His starting point was that reporters should not assume governments -and corporations are telling the truth, but verify all their claims as -much as possible. I wonder how many Norwegian reporters can be said -to follow the principles of I. F. Stone. They are definitely in short -supply. If you, like me half a year ago, have never heard of him, -check him out.
+ +It is hard to know if the hang is still going on, and it is hard to +be sure looking in dmesg is going to work. If there are lots of other +messages in dmesg the lines might have rotated out of site before they +are noticed.
+ +While reading through the nfs client implementation in linux kernel +code, I came across some statistics that seem to give a way to detect +it. The om_timeouts sunrpc value in the kernel will increase every +time the above log entry is inserted into dmesg. And after digging a +bit further, I discovered that this value show up in +/proc/self/mountstats on Linux.
+ +The mountstats content seem to be shared between files using the +same file system context, so it is enough to check one of the +mountstats files to get the state of the mount point for the machine. +I assume this will not show lazy umounted NFS points, nor NFS mount +points in a different process context (ie with a different filesystem +view), but that does not worry me.
+ +The content for a NFS mount point look similar to this:
+ ++ ++[...] +device /dev/mapper/Debian-var mounted on /var with fstype ext3 +device nfsserver:/mnt/nfsserver/home0 mounted on /mnt/nfsserver/home0 with fstype nfs statvers=1.1 + opts: rw,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,soft,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=129.240.3.145,mountvers=3,mountport=4048,mountproto=udp,local_lock=all + age: 7863311 + caps: caps=0x3fe7,wtmult=4096,dtsize=8192,bsize=0,namlen=255 + sec: flavor=1,pseudoflavor=1 + events: 61063112 732346265 1028140 35486205 16220064 8162542 761447191 71714012 37189 3891185 45561809 110486139 4850138 420353 15449177 296502 52736725 13523379 0 52182 9016896 1231 0 0 0 0 0 + bytes: 166253035039 219519120027 0 0 40783504807 185466229638 11677877 45561809 + RPC iostats version: 1.0 p/v: 100003/3 (nfs) + xprt: tcp 925 1 6810 0 0 111505412 111480497 109 2672418560317 0 248 53869103 22481820 + per-op statistics + NULL: 0 0 0 0 0 0 0 0 + GETATTR: 61063106 61063108 0 9621383060 6839064400 453650 77291321 78926132 + SETATTR: 463469 463470 0 92005440 66739536 63787 603235 687943 + LOOKUP: 17021657 17021657 0 3354097764 4013442928 57216 35125459 35566511 + ACCESS: 14281703 14290009 5 2318400592 1713803640 1709282 4865144 7130140 + READLINK: 125 125 0 20472 18620 0 1112 1118 + READ: 4214236 4214237 0 715608524 41328653212 89884 22622768 22806693 + WRITE: 8479010 8494376 22 187695798568 1356087148 178264904 51506907 231671771 + CREATE: 171708 171708 0 38084748 46702272 873 1041833 1050398 + MKDIR: 3680 3680 0 773980 993920 26 23990 24245 + SYMLINK: 903 903 0 233428 245488 6 5865 5917 + MKNOD: 80 80 0 20148 21760 0 299 304 + REMOVE: 429921 429921 0 79796004 61908192 3313 2710416 2741636 + RMDIR: 3367 3367 0 645112 484848 22 5782 6002 + RENAME: 466201 466201 0 130026184 121212260 7075 5935207 5961288 + LINK: 289155 289155 0 72775556 67083960 2199 2565060 2585579 + READDIR: 2933237 2933237 0 516506204 13973833412 10385 3190199 3297917 + READDIRPLUS: 1652839 1652839 0 298640972 6895997744 84735 14307895 14448937 + FSSTAT: 6144 6144 0 1010516 1032192 51 9654 10022 + FSINFO: 2 2 0 232 328 0 1 1 + PATHCONF: 1 1 0 116 140 0 0 0 + COMMIT: 0 0 0 0 0 0 0 0 + +device binfmt_misc mounted on /proc/sys/fs/binfmt_misc with fstype binfmt_misc +[...] +
The key number to look at is the third number in the per-op list. +It is the number of NFS timeouts experiences per file system +operation. Here 22 write timeouts and 5 access timeouts. If these +numbers are increasing, I believe the machine is experiencing NFS +hang. Unfortunately the timeout value do not start to increase right +away. The NFS operations need to time out first, and this can take a +while. The exact timeout value depend on the setup. For example the +defaults for TCP and UDP mount points are quite different, and the +timeout value is affected by the soft, hard, timeo and retrans NFS +mount options.
+ +The only way I have been able to get working on Debian and RedHat
+Enterprise Linux for getting the timeout count is to peek in /proc/.
+But according to
+
Is there a better way to figure out if a Linux NFS client is +experiencing NFS hangs? Is there a way to detect which processes are +affected? Is there a way to get the NFS mount going quickly once the +network problem causing the NFS hang has been cleared? I would very +much welcome some clues, as we regularly run into NFS hangs.
I'm happy to report that -the -French paperback edition of -my -project to translate the Free -Culture book by Lawrence Lessig is now available for sale on -Lulu.com. Once I have formally verified my proof reading copy, which -should be in the mail, the paperback edition should be available in -book stores like Amazon and Barnes & Noble too.
- -This French edition, Culture Libre, is the work of the -dblatex developer Benoît -Guillon, who created the PO file from the initial translation -available from -the Wikilivres -wiki pages and completed and corrected the translation to match -the original docbook edition my project is using, as well as -coordinated the proof reading of the final result. I believe the end -result look great, but I am biased and do not read French. In -addition to the paperback edition, the book is available in PDF, EPUB -and Mobi format from the github project page linked to above.
- -When enabling book store distribution on Lulu.com, I had to nearly -triple the price to allow the book stores some profit. I also had to -accept that I will get some revenue when a book is sold via Lulu.com. -But because of the non-commercial clause in the book license -(CC-BY-NC), this might be a problem. To bypass the problem I -discussed how to handle the revenue with the author, and we agreed -that the revenue for these editions go to the -Creative Commons non-profit -Corporation who handle donations to the Creative Commons project. -So far they have earned around USD 70 on sales of the -English -and -Norwegian -Bokmål editions, according to Lulu.com. They will get the revenue -for the French edition too. Their revenue is higher if you buy the -book directly from Lulu.com instead of via a book store, so I -recommend you buy directly from Lulu.com.
- -Perhaps you would like to get the book published in your language? -The translation is done using a web based translator service, so the -technical bar to enter is fairly low. Get in touch if you would like -to make this happen.
+ +So the new president in the United States of America claim to be +surprised to discover that he was wiretapped during the election +before he was elected president. He even claim this must be illegal. +Well, doh, if it is one thing the confirmations from Snowden +documented, it is that the entire population in USA is wiretapped, one +way or another. Of course the president candidates were wiretapped, +alongside the senators, judges and the rest of the people in USA.
+ +Next, the Federal Bureau of Investigation ask the Department of +Justice to go public rejecting the claims that Donald Trump was +wiretapped illegally. I fail to see the relevance, given that I am +sure the surveillance industry in USA believe they have all the legal +backing they need to conduct mass surveillance on the entire +world.
+ +There is even the director of the FBI stating that he never saw an +order requesting wiretapping of Donald Trump. That is not very +surprising, given how the FISA court work, with all its activity being +secret. Perhaps he only heard about it?
+ +What I find most sad in this story is how Norwegian journalists +present it. In a news reports the other day in the radio from the +Norwegian National broadcasting Company (NRK), I heard the journalist +claim that 'the FBI denies any wiretapping', while the reality is that +'the FBI denies any illegal wiretapping'. There is a fundamental and +important difference, and it make me sad that the journalists are +unable to grasp it.
+ +Update 2017-03-13: Look like +The +Intercept report that US Senator Rand Paul confirm what I state above.
During this weekends -bug -squashing party and developer gathering, we decided to do our part -to make sure there are good books about Debian available in Norwegian -Bokmål, and got in touch with the people behind the -Debian Administrator's Handbook -project to get started. If you want to help out, please start -contributing using -the -hosted weblate project page, and get in touch using -the -translators mailing list. Please also check out -the instructions for -contributors.
- -The book is already available on paper in English, French and -Japanese, and our goal is to get it available on paper in Norwegian -Bokmål too. In addition to the paper edition, there are also EPUB and -Mobi versions available. And there are incomplete translations -available for many more languages.
+ +For almost a year now, we have been working on making a Norwegian +Bokmål edition of The Debian +Administrator's Handbook. Now, thanks to the tireless effort of +Ole-Erik, Ingrid and Andreas, the initial translation is complete, and +we are working on the proof reading to ensure consistent language and +use of correct computer science terms. The plan is to make the book +available on paper, as well as in electronic form. For that to +happen, the proof reading must be completed and all the figures need +to be translated. If you want to help out, get in touch.
+ +A + +fresh PDF edition in A4 format (the final book will have smaller +pages) of the book created every morning is available for +proofreading. If you find any errors, please +visit +Weblate and correct the error. The +state +of the translation including figures is a useful source for those +provide Norwegian bokmål screen shots and figures.
Just for fun I had a look at the popcon number of ZFS related -packages in Debian, and was quite surprised with what I found. I use -ZFS myself at home, but did not really expect many others to do so. -But I might be wrong.
- -According to -the popcon -results for spl-linux, there are 1019 Debian installations, or -0.53% of the population, with the package installed. As far as I know -the only use of the spl-linux package is as a support library for ZFS -on Linux, so I use it here as proxy for measuring the number of ZFS -installation on Linux in Debian. In the kFreeBSD variant of Debian -the ZFS feature is already available, and there -the popcon -results for zfsutils show 1625 Debian installations or 0.84% of -the population. So I guess I am not alone in using ZFS on Debian.
- -But even though the Debian project leader Lucas Nussbaum -announced -in April 2015 that the legal obstacles blocking ZFS on Debian were -cleared, the package is still not in Debian. The package is again in -the NEW queue. Several uploads have been rejected so far because the -debian/copyright file was incomplete or wrong, but there is no reason -to give up. The current status can be seen on -the -team status page, and -the -source code is available on Alioth.
- -As I want ZFS to be included in next version of Debian to make sure -my home server can function in the future using only official Debian -packages, and the current blocker is to get the debian/copyright file -accepted by the FTP masters in Debian, I decided a while back to try -to help out the team. This was the background for my blog post about -creating, -updating and checking debian/copyright semi-automatically, and I -used the techniques I explored there to try to find any errors in the -copyright file. It is not very easy to check every one of the around -2000 files in the source package, but I hope we this time got it -right. If you want to help out, check out the git source and try to -find missing entries in the debian/copyright file.
+ +A few days ago I ordered a small batch of +the ChaosKey, a small +USB dongle for generating entropy created by Bdale Garbee and Keith +Packard. Yesterday it arrived, and I am very happy to report that it +work great! According to its designers, to get it to work out of the +box, you need the Linux kernel version 4.1 or later. I tested on a +Debian Stretch machine (kernel version 4.9), and there it worked just +fine, increasing the available entropy very quickly. I wrote a small +test oneliner to test. It first print the current entropy level, +drain /dev/random, and then print the entropy level for five seconds. +Here is the situation without the ChaosKey inserted:
+ ++ ++% cat /proc/sys/kernel/random/entropy_avail; \ + dd bs=1M if=/dev/random of=/dev/null count=1; \ + for n in $(seq 1 5); do \ + cat /proc/sys/kernel/random/entropy_avail; \ + sleep 1; \ + done +300 +0+1 oppføringer inn +0+1 oppføringer ut +28 byte kopiert, 0,000264565 s, 106 kB/s +4 +8 +12 +17 +21 +% +
The entropy level increases by 3-4 every second. In such case any +application requiring random bits (like a HTTPS enabled web server) +will halt and wait for more entrpy. And here is the situation with +the ChaosKey inserted:
+ ++ ++% cat /proc/sys/kernel/random/entropy_avail; \ + dd bs=1M if=/dev/random of=/dev/null count=1; \ + for n in $(seq 1 5); do \ + cat /proc/sys/kernel/random/entropy_avail; \ + sleep 1; \ + done +1079 +0+1 oppføringer inn +0+1 oppføringer ut +104 byte kopiert, 0,000487647 s, 213 kB/s +433 +1028 +1031 +1035 +1038 +% +
Quite the difference. :) I bought a few more than I need, in case +someone want to buy one here in Norway. :)
+ +Update: The dongle was presented at Debconf last year. You might +find the talk +recording illuminating. It explains exactly what the source of +randomness is, if you are unable to spot it from the schema drawing +available from the ChaosKey web site linked at the start of this blog +post.