Bug 1294589

Summary: owfs services fail to start, and other issue with owfs
Product: [Fedora] Fedora Reporter: Richard Keech <richard.keech>
Component: owfsAssignee: Tomasz Torcz <tomek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 23CC: 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
Description of problem:

When starting owfs service using systemd the service starts then stops immediately.

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

owfs-fs-3.1p0-2.fc23.x86_64


How reproducible:

Steps to Reproduce:
1. fit DS9490 one-wire adapter (https://www.maximintegrated.com/en/products/comms/ibutton/DS9490.html)
2. blacklist one-wire modules wire and ds2490 (see BZ1229231)
3. set owfs to start with "-u" option instead of "-w1" option to overcome driver issue
4. start owfs service with systemctl


Actual results:

log shows service terminating immediately, despite correct operation if systemd's ExecStart is called manually.


Expected results:

service should persist.


Additional info:

Problem determined to be the lack of appropriate service type in unit file.
If I set "Type=forking" in unit file then problem disappears.  Currently using this unit file:

[Unit]
Description=1-wire filesystem FUSE mount
Documentation=man:owfs(1)

[Service]
Type=forking
ExecStart=/usr/bin/owfs -uall --allow_other /run/owfs
ExecStop=/usr/bin/umount /run/owfs
RuntimeDirectory=owfs

[Install]
WantedBy=multi-user.target


Additional issues with owfs:

1.  Pkg dependencies incorrect . The owfs-package depends upon the owfs-server package unnecessarily.  The default configuration of owfs is to connect via socket to owserver instance.  I find that performance in this mode of operation is poor and configuration is needlessly complex.  Owfs daemon can access one-wire hardware directly without need for owserver.

   Suggestion:  
     1. remove the package dependency of owfs-fs upon owfs-server.
     2. change the default ExecStart from:

ExecStart=/usr/bin/owfs --server=127.0.0.1 --allow_other /run/owfs

to

ExecStart=/usr/bin/owfs -uall --allow_other /run/owfs

This allows owfs to work without needing owserver.

Note, starting owserver or owfs using -w1 requires kernel modules in package kernel-modules-extra.  If the -w1 option worked properly then it would be appropriate to add this dependency.


2.  Default configuration uses the linux kernel w1 virtual bus master with the '-w1' option.  Per BZ1229231 this doesn't work properly.  I've been using owfs for over two years.  In that time I've never been able to get it working with -w1 option.  Operation via usblib (-u option) works OK.

    Suggestion:  For owfs-owserver package change unit file usr/lib/systemd/system/owserver.service as follows:

Change ExecStart=/usr/bin/owserver --w1
to ExecStart=/usr/bin/owserver -u 
or ExecStart=/usr/bin/owserver -uall


3. Fuse 'allow other' option.  For the owfs server to work properly per the command-line options, the option 'user_allow_other' needs to be set in /etc/fuse.conf.

    Suggestion:  Set this option in /etc/fuse.conf in the install script.

Comment 1 Tomasz Torcz 2016-01-02 11:53:26 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.

Comment 2 Jan Kandziora 2016-01-14 14:12:22 UTC
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.

Comment 3 Jan Kandziora 2016-01-14 15:03:19 UTC
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.

Comment 4 Jan Kandziora 2016-01-14 16:09:09 UTC
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.

Comment 5 Tomasz Torcz 2016-01-15 13:48:39 UTC
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.

Comment 6 Fedora Update System 2016-01-18 08:23:44 UTC
owfs-3.1p0-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9da22de418

Comment 7 Fedora Update System 2016-01-20 03:55:23 UTC
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

Comment 8 Fedora Update System 2016-03-21 01:52:32 UTC
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.