Bug 1203731

Summary: avahi-daemon won't start due to rlimit-nproc being too low
Product: [Fedora] Fedora Reporter: Richard Marko <rmarko>
Component: avahiAssignee: Lennart Poettering <lpoetter>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 21CC: jberan, lpoetter, msekleta, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1227052 (view as bug list) Environment:
Last Closed: 2015-03-20 06:48:26 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1227052    

Description Richard Marko 2015-03-19 10:48:23 EDT
Description of problem:
Mar 19 15:36:30 grampi avahi-daemon[17498]: chroot.c: fork() failed: Resource temporarily unavailable
Mar 19 15:36:30 grampi avahi-daemon[17498]: failed to start chroot() helper daemon.

Adjusting rlimit-nproc=2 to higher number in /etc/avahi/avahi-daemon.conf
fixes this issue.

Version-Release number of selected component (if applicable):

How reproducible:

To reproduce start LXC container and try running avahi-daemon along with avahi-daemon running on host.

If there are avahi-daemons running in LXC then it even prevents starting of avahi-daemon on host.
Comment 1 Michal Sekletar 2015-03-20 06:48:26 EDT
I don't think there is anything which can be done about this in avahi. In struct_user in kernel there is a field,

atomic_t processes;	/* How many processes does this user have? */

Setting rlimit_nproc will set this field to two. Since avahi service by default spawns two processes then once you start it in container which *does not* use user namespace then you are screwed because you exhausted your limit which is per user. Then you can't start avahi on the host nor in any other container you might have.

To prevent this unfortunate behavior you can of course use user_ns. However once you go this road note that you are entering another realm of pain with current user_ns implementation. 

I'd say you'll be better off setting rlimit-nproc to higher number.