Tilman's questions

On a Ubuntu 20.04.2 TLS server, I have a need to start a service after another one has fully started up. Specifically, the openvpn-server service creates a tun0 interface with the IP address 10.87.0.1 to which the rinetd service then binds. So the rinetd service should only be started after the openvpn-server service has created that interface.

rinetd comes with a sysvinit service script /etc/init.d/rinetd saying:

# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog

This causes rinetd to be started during system startup before openvpn-server has created the interface. It then emits the log message:

rinetd[792]: couldn't bind to address 10.87.0.1 port 873 (Cannot assign requested address)

and does not accept connections until I manually restart it with sudo systemctl restart rinetd, after which it then runs just fine.

According to sudo systemctl status the openvpn server process is run by a systemd service named [email protected]. Extending the Required-Start line in /etc/init.d/rinetd to say:

# Required-Start:    $remote_fs $syslog openvpn-server@server

is duly translated by systemd-sysv-generator to an additional line

[email protected]

in /run/systemd/generator.late/rinetd.service. But systemd ignores that. rinetd still shows the same log message and malfunction, proving that it is still started before openvpn-server is up.

How can I get systemd to reliably start the rinetd service only after the openvpn-server service has done its part and created the interface?

I'm running a hundred Ubuntu 16.04 LTS servers with basically identical hardware distributed worldwide. (I'm working on upgrading them to 20.04 LTS but certain unfortunate design decisions on the part of Ubuntu are still blocking this.) Each of these servers is running a KVM VM with Windows 10 Enterprise. Three of them show the following problem:

Without any apparent cause, monitoring shows the server's Linux load average jumping up to above 2. top shows the CPU load from the qemu-system-x86 process running the Windows VM solidly at 200%, matching the 2 cores assigned to the VM. The Windows desktop accessed through VNC appears extremely sluggish. Windows Task Manager shows a process "System interrupts" consuming 100% CPU.

Rebooting the Windows VM does not fix the situation. It persists for several hours or even days and then goes back to normal by its own, again without any apparent cause or reason.

Researching reasons for high CPU usage by "System interrupts" in Windows turns up a general consensus that this is a hardware issue. The hardware running Windows in this case is virtual, namely the KVM hypervisor. The physical hardware of the hosts did not change before or after the high load episodes, nor does it differ significantly between the servers that show these episodes and those that don't. The Linux host system does not show any signs of malfunction except the excessive load from the Windows guest. Inspection of the Linux logs on the affected systems has turned up nothing unusual. The Windows event logs show the obvious heaps of secondary errors during the high load episodes, such as services not responding, but nothing indicating a possible cause.

Where would I begin to look for possible causes of that behaviour?

For the sake of completeness, this is my KVM invocation:

kvm \
        -daemonize \
        -name "$vmname64-$(hostname)" \
        -drive file="/srv/kvm/${vmname64}.qcow2",if=virtio \
        -net nic,model=virtio,macaddr=$macaddr64 -net tap \
        -vga std \
        -rtc base=localtime \
        -usb -usbdevice tablet \
        -nodefaults \
        -runas srvadmin \
        -chroot /home/srvadmin \
        -k de \
        -smp 2 \
        -m 4096 \
        -vnc :1,password \
        -monitor mon:telnet:127.0.0.1:4445,server,nowait

On a server running Ubuntu 20.04 LTS I am trying to list installed kernels with the command:

 dpkg-query -W -f '${Package}\n' 'linux-image-[0-9]*'

which according to the manpage should list installed packages matching the pattern. However the output of the command includes kernel versions which have already been removed. How can I limit the output to kernels which are still installed?

I am using autofs to mount CIFS shares automatically as described in the German Ubuntu users wiki. This works perfectly fine, except that every time a share is mounted, a warning message is logged to /var/log/syslog stating:

kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.

I understand that I can prevent that message by specifying an explicit SMB protocol version. I would however prefer to keep the default behaviour of negotiating the highest SMB protocol version supported by both sides, subject to a minimum version of 2.1, just without that annoying message.

Is there a way to just silence that message while keeping the default behaviour?

How can Ubuntu 16.04 LTS be forced to use the manually configured list of NTP servers in /etc/ntp.conf even if DHCP tries to provide a different one?

On Ubuntu 16.04 LTS (and probably all later releases), when an interface is configured via DHCP and the DHCP server response contains NTP server information, dhclient creates a configuration file /var/lib/ntp/ntp.conf.dhcp which overrides the configuration in /etc/ntp.conf and contains only the NTP server(s) received via DHCP, not the ones configured explicitly.

This happens even if (as recommended over on Server Fault) the request directive in /etc/dhcp/dhclient.conf is set explicitly to a list not containing the ntp-servers keyword.

In my case, a set of servers distributed worldwide receives its IP addresses via DHCP from each site's ISP access router but are required to synchronize their clocks to a common set of NTP servers.

I have a number of video files of various formats (mostly MP4 and FLV) that have apparently been encoded with the wrong aspect ratio, so when they are played with standard settings they appear stretched. If I select the correct aspect ratio manually in the player they look fine, but it is annoying to do that every time. Is there a tool to fix this in the file itself, preferably from the command line and without reencoding?

We are running sssd on a number of Xenial servers to authenticate against Active Directory.

Upon installation, the sssd package added sss to most lines in /etc/nsswitch.conf as documented in https://help.ubuntu.com/lts/serverguide/sssd-ad.html#sssd-ad-nsswitch . Regrettably, this includes the sudoers line, which results in an error message

problem with defaults entries

being mailed to the root account for every single use of sudo, which in our case includes an important number of cron jobs resulting in a lot of mails.

This is easily fixed by manually removing sss from that line again. However, each update of the sssd package re-adds that unwanted entry, triggering another flood of mails before we manually remove it again.

How can we avoid that?

I've inherited a server running Ubuntu 14.04.5 LTS that has a single 30 TB RAID partitioned into a very small boot partition and a big LVM partition containing everything else. Here's the current config:

# lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                        8:0    0    30T  0 disk 
├─sda1                     8:1    0   113M  0 part /boot
└─sda2                     8:2    0    30T  0 part 
  ├─vg01-root (dm-0)     252:0    0  55,9G  0 lvm  /
  ├─vg01-pooling (dm-1)  252:1    0   1,8T  0 lvm  /var/lib/bareos/pooling
  ├─vg01-postgres (dm-2) 252:2    0 465,7G  0 lvm  /postgres
  ├─vg01-swap (dm-3)     252:3    0   3,7G  0 lvm  [SWAP]
  └─vg01-storage (dm-4)  252:4    0  27,7T  0 lvm  /var/lib/bareos/storage

As you can see, the boot partition is really much too small. So I need to free up a comparably small amount of space at the beginning of sda2 in order to grow sda1. There are lots of well-written tutorials how to shrink an LVM Physical Volume on the 'net, but the freed space invariably shows up at the end of the PV.

Of course I can move the PV after shrinking it, but that would mean copying the entire 30 TB which would take ages, increasing the risk of something going wrong, and appears quite wasteful to me. Is there a better way? It doesn't matter which of the LVs the space is taken from, all of them have a Gig or two to spare.