Bug 1294589
Summary: | owfs services fail to start, and other issue with owfs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Keech <richard.keech> |
Component: | owfs | Assignee: | Tomasz Torcz <tomek> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 23 | CC: | jjj, tomek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | owfs-3.1p0-4.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-03-21 01:52:36 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Richard Keech
2015-12-29 06:03:11 UTC
Indeed, it seems that owfs started forking somewhere before introduction of upstream unit and version 3.1. I will add full Type=notify support upstream, in the meantime I will spin the packages with type=forking. I'll analyze your other suggestions soon. Limiting the started processes to owfs only isn't useful. The FUSE binding of OWFS is only useable for demonstration purposes as it had concurrency issues when values are updated by the owfs process. Healing this would require file locking, which none of the usual tools (cat et al.) supports. So owserver is the main program of OWFS, not the name-giving owfs. You can then access owserver with the owread, owwrite, owdir and owget processes from command line without those concurrency issues. In addition, there is another concurrency problem when the owfs, owhttpd, owftpd etc. programs are accesssing the same hostadapter (e.g. DS9490 USB) directly. libusb cannot serialize the requests correctly (some of them require many, many USB messages), so it breaks transactions and makes the onewire communication fail and hard to detect problems arise. That's why we always recommend to configure owserver connect to the hardware and all the other programs (including your own ones) connect to owserver. I recommend to change any of the systemd unit files to ExecStart=/usr/bin/ow... -c /etc/owfs.conf and supply a minimal /etc/owfs.conf like this -------- server: --w1 !server: -s localhost:4304 -------- in the owserver package, which should be the main package, along with the command line tools for accessing it. That's sufficient for the average user, and if Richard or someone else likes to switch from w1 to libusb, there is a single place where this has to be done. Performance isn't a concern for the average user, at least not when the underlying bus operates at roughly 10kBaud. The owfs subpackage should be seen as a mere technical demonstration because of its concurrency problems and a big fat warning because of this should be included. For the same reason, strip it of any default configuration and systemd unit files. I write all this as the person who answers all the bug reports and configuration advice we receive upstream since Paul isn't available any more. Oh, and I should address what Richard encountered with the w1 subsystem. Kernel behaviour changed roughly 12 month ago and noone using newer kernels reported it upstream but everyone was applying private fixes instead. I've just included such a fix into our git archive so the next release should be okay with --w1. And another idea, instead of announcing Type=Forking, all daemons could be started with --foreground to avoid that forking. That way systemd has it easier to control the daemon. Thanks Jan for your comments. When I introduced unit files for owfs, I've asked the mail list about how to proceed. Going through owserver was recommended and so I did that. Although I tried to make the configuration mostly working by default, it was not possible in all cases. OWFS can be configured in multitude of ways, so there is no one-size-fits-all solution. Going through owserver plus relying on kernel autoconfiguration (w1) was the best I'm able to do. To have full flexibility, administrator has to exploit config files. Fortunately systemd unit files are just that, config files. With quite flexible priority (/etc vs /usr vs /run) and customisation options (dropins), customizing systemd unit files is easy. There are also tools like systemd-delta on so on. So if you don't want default option for startup, customize unit files. I'm not going to touch configuration from other packages (fuse.conf), especially changing option depending on security. This must be a consious decision by sysadm. Therefore: a) for owfs, I've changed unit to have Type=forking. Package is now being tested in rawhide, after successes I will fix F23. I will prepare better solution for upstream, I hope to have it for 3.1p2. b) I will upgrade owfs in rawhide to 3.1pLATEST just before F24 branch (because of gratious soname changes, upgrading owfs is cumbersome) c) I will probably backport w1 fix to F23 and F22. I'll leave this bug for tracking this backport. owfs-3.1p0-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9da22de418 owfs-3.1p0-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9da22de418 owfs-3.1p0-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |