In Debian 9 Stretch Apache is configured to use the systemd PrivateTmp feature by default. This means that the Apache tmp directory actually lives in /tmp/systemd-private-BIGLONGSTRING--apache2.service-STRING.
So if you are running an SVN server that uses Apache for serving, anything written to /tmp in the hook scripts ends up in the private directory rather than the normal userspace one.
Setup – Dell Latitude 7490 running Ubuntu 18.04 Bionic and Dell WD15 USB-C dock.
Problem – system freezes when dock unplugged.
This problem started after updates. The solution found was to revert to the previous kernel (4.15.0-43-generic) from 4.15.0-44-generic. Did this by setting GRUB to remember the boot setting – change /etc/grub/grub with:
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
and run
Then hit esc at the loading screen to get to the grub menu.
Note to self – when trying to stop the continued requests for reboots to install pending updates in Windows Update, one of the go-to things to check is the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired
Remember, don’t just delete the contents of this key, delete the actual key itself!
After updating anything to use systemd-235 NIS logins either don’t work at all (usually for GUI logins), or take a long time to login (console or ssh, sometimes). The culprit is a line in the systemd-logind.service:
IPAddressDeny=any
This sandboxes the service and doesn’t allow it to talk to the network. Unfortunately this affects nis lookups done via the glibc NSS API. See the links at https://github.com/systemd/systemd/pull/7343
The quick solution is to turn off the sandboxing, either by commenting out or changing the line in systemd-logind.service, or creating a drop-in snippet that overrides it. This can be done by creating a file /etc/systemd/system/systemd-logind.service.d/IPAddress_clear.conf with the contents:
Read more...
As per this bug:
Debian Bug report logs – #852323
The Debian 9 installer (up to v9.5 at least) does not always configure GRUB to find the boot partition using UUID, but leaves it pointing to /dev/sdb or whatever. This can be a problem if you change disks in the system. In particular, if you install from a USB stick and then remove it when the system reboots after the install this can change the disk /dev id. The result is a unbootable system. This can be a bit fiddly to fix (although the first thing that’s always worth trying is to reverse the changes you made and see if it boots, e.g. plug the install USB stick back in to the same usb slot).
Read more...