Bug 786853 - usbmuxd: udev rules cannot be used to directly fork() long running services
Summary: usbmuxd: udev rules cannot be used to directly fork() long running services
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: usbmuxd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-02 15:19 UTC by Kay Sievers
Modified: 2012-07-10 17:23 UTC (History)
3 users (show)

Fixed In Version: usbmuxd-1.0.8-3.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-10 17:23:37 UTC
Type: ---


Attachments (Terms of Use)

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.


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