> Are you sure about that? To my knowledge, Debian 9 is still using the good old network scripts. I'm 100% about Debian 8 since that's why I use in production,

> Are you sure about that? To my knowledge, Debian 9 is still using the good old network scripts. I'm 100% about Debian 8 since that's why I use in production, with systemd-networkd nowhere to be seen. The last job developed/supported Debian based high performance storage systems in production, starting with Debian 7, then Debian 8, and Debian 9. root@localdns:~# cat /etc/debian_version 8.10 root@localdns:~# locate systemd-networkd /lib/systemd/systemd-networkd /lib/systemd/systemd-networkd-wait-online /lib/systemd/system/systemd-networkd-wait-online.service /lib/systemd/system/systemd-networkd.service /usr/share/man/man8/systemd-networkd-wait-online.8.gz /usr/share/man/man8/systemd-networkd-wait-online.service.8.gz /usr/share/man/man8/systemd-networkd.8.gz /usr/share/man/man8/systemd-networkd.service.8.gz Its there, but I disabled it in this case. > Why are you decreasing the timeouts? I actually increased them in my case to give services more time to exit (upstream default is 90s). This comes from long debugging/tracing sessions where we were trying to understand why we wound up with effectively repeating timeouts. [...] On systemd-udev-settle, allowing it to run was actually the cause of a race condition on start. The only way to fix this that I found was to disable this. Once we did this, no more race condition. The system booted normally. It sounds like your experience is significantly different than mine on this. We built very large high performance computing and storage systems for many users, where the things that people used simply had to work, without surprise. Every line I showed came from a set of long and often painful debugging sessions where we had to figure out what new change had broken a key bit of software. The RuntimeDirectorySize issue actually tickled another bug, and caused some incredible paging problems when used with a specific software package. Enough end users on a system (we had many) could launch an effective DoS against the system by using these tmps. Generally, my observation, and I've seen others make a similar set elsewhere, is that the default and general distribution settings for systemd parameters appear to be generally set for desktop users (single or very few users per machine). Not for large shared resources.