Bug 786853

Summary:	usbmuxd: udev rules cannot be used to directly fork() long running services
Product:	[Fedora] Fedora	Reporter:	Kay Sievers <kay>
Component:	usbmuxd	Assignee:	Peter Robinson <pbrobinson>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bnocera, cfergeau, pbrobinson
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	usbmuxd-1.0.8-3.fc18	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-10 17:23:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Kay Sievers 2012-02-02 15:19:55 UTC

Please do not start any daemon or long running services directly from
udev rules. Udev rules are meant to configure and identify devices, but
never to play 'init' and start services.

This needs to be fixed as soon as possible. The started services will
currently be tracked as belonging to udev's process group, and if
udev.service is stopped, these started daemons might just get forcefully
cleaned up.

Please use systemd's facilities and mark the devices to automatically
pull-in a service for the mux daemon, or use socket activation to start
the mux daemon when something tries to connect to it.

Udev is not and never was the appropriate place to start system services.
Service management can not be provided by udev, it is a lot more complex
than to fork an executable and wait for it to return, which is the only
thing that the simple udev rules really support.

Thanks!

Comment 1 Peter Robinson 2012-02-02 15:30:52 UTC

usbmuxd is designed to be started on the plugging in of a particular device and not continue to run if it's not plugged in to ensure devices just work when available but it would never be run if people don't own the said device. Please provide the documentation for how systemd handles these use cases. I couldn't find anything the last time I looked.

Comment 2 Kay Sievers 2012-04-15 13:18:06 UTC

The daemon needs a usbmux.service file which describes the daemon and carries
the command line to start it.

The udev rules can add:
  ENV{SYSTEMD_WANTS}="usbmux.service"
for matching devices, which will instruct systemd to start the daemon.

A common example of this model is bluetooth, which is started only twhen
a device is found.

The usbmux daemon should probably exit on its own if the device it handles
goes away.

Note, that the current udev rule will not work for Fedora 18, the started
daemon will immediately get a SIGKILL; the entire udev.service will clean
up all started background processes right after every event handling.

This problem already exists on current systems, where a restart of udev,
manually or by a RPM package upgrade would kill the daemon, it is just not
enforced immediately.

Thanks!

Comment 3 Bastien Nocera 2012-07-10 17:23:37 UTC

Done in usbmuxd-1.0.8-3.fc18.

I'm not sure we want the patch in F17, as it's quite intrusive (and untested), and the cases where it can happen are quite restricted.