Belly's questions

I've been plagued for a while by a major disparity between the CPU usage reported by a KVM host and guest. The guest will be reporting as basically idle, but the host will report one virtual core at 100% CPU.

I've finally tracked it down to a misbehaving application that ends up calling a very short nanosleep in a tight loop in the guest. The following C code will replicate the issue reliably:

#include <time.h>

void main() {
    while (1) {
        struct timespec ts = {0, 1024*100};
        nanosleep(&ts, NULL);
    }
}

If I run this program in the host, the CPU is basically idle. If I run it in the guest, the guest believes he is idle, but the host reports a core fully used.

I do intend to make the application better behaved, but I would like to understand the root cause of the mismatch. Is there potentially something misconfigured in my KVM setup that could lead to this, or is this an expected outcome somehow?

In my test setup, the host is Ubuntu 18.10, and the guest is CentOS 6. I've been able to replicate this with other guest OSes as well.

I've been investigating options for minimizing the amount of credentials that need to be retyped as credentials expire. One of the big problems I'm having now is dealing with delegated credentials, which interferes with long-running SSH sessions.

It seems like the GSSAPIRenewalForcesRekey and GSSAPIStoreCredentialsOnRekey options do exactly what I want - when a client renews its ticket, the credentials would be re-sent to the server.

However, the options appear to have no effect at all. For example, once I set up an SSH connection, I expect that running kinit or kinit -R would eventually refresh the credential cache on the server.

Running ssh and sshd in verbose/debug mode doesn't shed any light on this either.

Do I have the wrong idea about what these options do? I would greatly appreciate any information on what I'm doing wrong or alternate ways of accomplishing this.

EDIT: It appears that this might be an inherent issue with the .9 superblock version. Figures that I would only be able to find these links after I posted here.

https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/599515 mdadm assembles with drives instead of partitions

Recently, I added to new disks to a machine. I created one partition on each drive, and used software raid to set up a raid1 between the partitions. However, for some reason after I add the partitions to the array, mdadm also detects the superblock in the underlying block devices. This causes a lot of problems during boot, as udev tries to assemble arrays incrementally and stumbles on /dev/sda before /dev/sda1. As you can see below, only md3 suffers from this problem. It was assembled with mdadm -A /dev/md3 /dev/sda1 /dev/sdb1. Have I set up these partitions incorrectly somehow?

root@blaster:/# mdadm --examine --verbose --scan
ARRAY /dev/md3 level=raid1 num-devices=2 UUID=33868dc0:becdb6b6:8b9f62c7:cb89d2ee
   spares=2   devices=/dev/sdb1,/dev/sdb,/dev/sda1,/dev/sda
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=866cc7e5:f18b48c0:539d4f3e:4592bf76
   devices=/dev/sdd1,/dev/sdc1
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=550101be:d1fac9c9:48c0e818:59501087
   devices=/dev/sdd2,/dev/sdc2
ARRAY /dev/md2 level=raid1 num-devices=2 UUID=7783bbb3:6e381768:8b9f62c7:cb89d2ee
   devices=/dev/sdf1,/dev/sde1

I have a process that is reporting in 'top' that it has 6GB of resident memory and 70GB of virtual memory allocated. The strange thing is that this particular server only has 8GB physical and 35GB of swap space available.

From the 'top' manual:

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Given this explanation, I would expect the virutal memory allocation for a process to be limited to my swap + physical memory available.

According to 'pmap', the code, shared library, and shared memory sections of this process are all minimal - no more than 300M or so.

Obviously, the machine and the process are still functioning correctly (albeit slowly), so what am I missing here?

I'm trying to have puppet build a configuration file that looks like this:

[All]
Hosts=apt-dater@puppetmaster;apt-dater@blaster; (etc...)

Basically, this file needs an entry for each node that includes the apt-dater class. I've been experimenting with exported resources, but I can't find a clean way of putting it together. How should I go about creating this file?