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