Description of problem:
If there are many units (> ~1024) systemd will fail to load on boot with 'too many files' error. This prevents a boot from succeeding.
Version-Release number of selected component (if applicable):
systemd-44.23
How reproducible:
very
Steps to Reproduce:
1. Create >1024 units. A simple method is to create 1024 .automounts and corresponding .mounts. These mounts could be simple bind mounts. See below for example script to recreate.
2. reboot
Actual results:
On boot, some of the automounts will be loaded correctly, but the rest won't and you will be dropped into 'emergency mode'.
Expected results:
The system will boot successfully.
Additional info:
Script to help recreate this issue:
-------------------------snip--------------------
#!/bin/sh
count=$1
if [ -z "$count" ]; then
echo "usage: $0 number_of_automounts_to_create"
exit
fi
for i in $(seq 1 $count); do
echo "creating /etc/systemd/system/test-$i.automount"
cat >/etc/systemd/system/test-$i.automount <<EOF
[Unit]
Description=test automounter $i
[Automount]
Where=/test/$i
DirectoryMode=0770
[Install]
WantedBy=multi-user.target
EOF
echo "creating /etc/systemd/system/test-$i.mount"
cat >/etc/systemd/system/test-$i.mount <<EOF
[Unit]
Requires=test-$i.automount
After=test-$i.automount
[Mount]
What=/usr/bin
Where=/test/$i
Options=bind
EOF
done
echo "enabling svcs"
(cd /etc/systemd/system && systemctl enable test*mount)
-------------------------snip--------------------
running the script:
$ sudo create_many_automounts.sh 1024
- BACKPORT?
Note, this has already been fixed upstream:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=4096d6f5879aef73e20dd7b62a01f447629945b0
Would it be possible to backport this to f17? It also appears that f18 may not have this fix either.
I also have a slightly re-worked patch that compiles against the f17 branch (systemd-44.23).
https://github.com/joemiller/systemd/blob/7e362a8162f8b693e2046886800d3278bd9de88b/1001-rlimit_nofile.patch