Bug 1203731 - avahi-daemon won't start due to rlimit-nproc being too low
Summary: avahi-daemon won't start due to rlimit-nproc being too low
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: avahi
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1227052
TreeView+ depends on / blocked
 
Reported: 2015-03-19 14:48 UTC by Richard Marko
Modified: 2016-02-01 02:23 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
: 1227052 (view as bug list)
Environment:
Last Closed: 2015-03-20 10:48:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Richard Marko 2015-03-19 14:48:23 UTC
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):
avahi-0.6.31-30.fc21.x86_64

How reproducible:
Always

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 10:48:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.