>>I thought: can't we instead do this as part of setting up the systemd >>scope/qemu.slice with LimitNOFILE?
I have tried (see my cover-letter ;), I can't get it work. "start failed: org.freedesktop.DBus.Error.PropertyReadOnly: Cannot set property LimitNOFILE, or unknown property. " I don't seem to be available in scope object https://www.freedesktop.org/wiki/Software/systemd/dbus/ >>But that would also affect the swtpm process spawned there :/ Yes, not sure about the impact on other process and the systemd.exec man page says: > │LimitNOFILE= │ ulimit -n │ Number of File > Descriptors │ Don't use. Be careful when raising the soft limit above > 1024, since select() cannot │ > │ │ > │ │ function with file descriptors above > 1023 on Linux. Nowadays, the hard limit │ > │ │ > │ │ defaults to 524288, a very high value > compared to historical defaults. Typically │ > │ │ > │ │ applications should increase their > soft limit to the hard limit on their own, if │ > │ │ > │ │ they are OK with working with file > descriptors above 1023, i.e. do not use │ > │ │ > │ │ select(). Note that file descriptors > are nowadays accounted like any other form of │ > │ │ > │ │ memory, thus there should not be any > need to lower the hard limit. Use MemoryMax= │ > │ │ > │ │ to control overall service memory use, > including file descriptor memory. │ >>So not sure if that's really nicer. This suggests QEMU should raise >>the >>limit itself. Yes, but it don't raise the limit :/ But it's really working with more than 1024 file descriptor. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
