I've been talking with the Owfs developers and trying to get a more reliable startup. I would have to stop and restart mine several times before the devices would be seen in the fuse filesystem. They suggested I try the newest version 2.7p2 because some fixes and updates have been done. That worked great!! With my startup script I could stop/start reboot and devices on the 1-wire hub were seen. I decided to try the Gentoo startup scripts and I get the same problem had before switched to the newest Owfs version. Mine use to start like this before the new version: # ls /mnt/owire bus.0 settings statistics structure system uncached That is not showing the 1-wire devices on the hub. It should look like this: # ls /mnt/owire 1F.66BD04000000 1F.67BD04000000 bus.0 settings statistics structure When I start /etc/init.d/owserver, then /etc/init.d/owfs it looks like the first one, no devices shown. According to top Owfs developer that means: Clearly owfs is working, it's owserver that doesn't always pick up the 1-wire hub. So I suspect the /etc/init.d/owserver script is the problem. I haven't been able to work around it yet. So continue to use my startup script: #!/bin/bash case "$1" in start) { echo "Starting 1-Wire server" /usr/bin/owserver -F -d /dev/ttyS1 -p 127.0.0.1:3001 echo "Starting 1-Wire file system" /usr/bin/owfs -F -s 127.0.0.1:3001 --allow_other --fuse_open_opt="\"-o uid=1000,gid=150\"" -m /mnt/owire exit 0 } ;; stop) { echo "Stopping 1-Wire file system" umount /mnt/owire echo "Stopping 1-Wire server" killall -TERM owserver exit 0 } ;; esac Reproducible: Always
This has exactly nothing to do w/ Gentoo Bugzilla product; see the descriptions.
No idea what's Owserver; reopen with exact ebuild name and version; thanks.
Yes, sorry, I forgot to mention it is the owfs application. Added that to the Summary.
Created attachment 139573 [details] /etc/init.d/owserver Removed UID:GID references
Created attachment 139574 [details] /etc/init.d/owfs Changed UID:GID variables to numbers, removed the original chown:chgrp references and added --fuse_open_opt
Sorry, it appears my attachments have proceeded my comments. But here is the explaination. I seem to have figured this out. What is happening is we are getting a permission denied on the serial port when start owserver init script: OWFS[22644]: Cannot open port: /dev/ttyS1 : Permission denied OWFS[22644]: Cannot open port: /dev/ttyS1 : Permission denied OWFS[22644]: Cannot detect DS9097 (passive) interface on /dev/ttyS1. Then owfs doesn't start cause of the same problem but also the conf.d opts it grabs is from owhttpd (from /etc/init.d/owfs): ${OWHTTPD_OPTS:--m /var/lib/owfs/mnt --allow_other -s 127.0.0.1:4304} Even when you change OWHTTPD_OPTS to OWFS_OPTS you will not see the devices cause of the permission problem with owserver to the serial port. So you see this (I have my mountpoint in /mnt/owire): ls /mnt/owire bus.0 settings statistics structure system uncached I found the permission problem to be from the OWUID and OWGID variables. What I did was use a little known option called --fuse_open_opt . It doesn't seem to accept anything but the uid:gid numbers ie. 150 in this case. Can't get it to work with owfs. Removed the owner:group in the script and added option as: OWUID=150 OWGID=150 --fuse_open_opt="\"-o uid=$OWUID,gid=$OWGID\"" \ That was in /etc/init.d/owfs, with /etc/init.d/owserver removed all references to OWUID, OWGID cause I don't think it needs it. /etc/init.d/owhttpd, needs the same thing. I have not used it so not sure if it would need the uid:gid like the owfs or not need it like the owserver script. Results, what should see and do now: # ls /mnt/owire -l total 0 drwxrwxrwx 1 owfs owfs 8 Dec 29 11:18 1F.66BD04000000 drwxrwxrwx 1 owfs owfs 8 Dec 29 11:18 1F.67BD04000000 drwxrwxrwx 1 owfs owfs 8 Dec 29 11:18 1F.ECD703000000 drwxr-xr-x 1 owfs owfs 8 Dec 29 11:18 bus.0 drwxr-xr-x 1 owfs owfs 8 Dec 29 11:18 settings drwxr-xr-x 1 owfs owfs 8 Dec 29 11:18 statistics drwxr-xr-x 1 owfs owfs 30 Dec 29 11:18 structure drwxr-xr-x 1 owfs owfs 8 Dec 29 11:18 system drwxr-xr-x 1 owfs owfs 8 Dec 29 11:18 uncached attached scripts for /etc/init.d/owfs and owserver that I changed. Didn't do anything with owhttpd yet.
I forgot to test one scenerio, but is still doesn't invalidate the attachments. The UID:GID with owserver has to be removed or get the permission denied error, but it does not cause same problem with owfs script like I thought. owfs script does start but it is not owned by owfs:owfs it is owned by root:root. You need to replace with the --fuse_open_opt to set the UID:GID like mentioned and correct the conf.d file to use. Otherwise it will work, but as you see like below the filesystem is owned by root:root. # ls /mnt/ -l drwxr-xr-x 1 root root 8 Dec 29 11:31 owire # ls /mnt/owire -l total 0 drwxrwxrwx 1 root root 8 Dec 29 11:32 1F.66BD04000000 drwxrwxrwx 1 root root 8 Dec 29 11:32 1F.67BD04000000 drwxrwxrwx 1 root root 8 Dec 29 11:32 1F.ECD703000000 drwxr-xr-x 1 root root 8 Dec 29 11:31 bus.0 drwxr-xr-x 1 root root 8 Dec 29 11:31 settings drwxr-xr-x 1 root root 8 Dec 29 11:31 statistics drwxr-xr-x 1 root root 30 Dec 29 11:31 structure drwxr-xr-x 1 root root 8 Dec 29 11:31 system drwxr-xr-x 1 root root 8 Dec 29 11:31 uncached
Sorry, but that's just bullshit :-) Make sure user or group 'owfs' can read/write-access your 1-wire bus controller device(s). For serial devices (/dev/ttyS*): # gpasswd -a owfs uucp For USB devices (/proc/bus/usb): # gpasswd -a owfs usb That's it.
1) I guess I am misunderstanding the -c ${OWUID}:${OWGID} part of the script then. I assumed it was to change owner:group of the owfs mountpoint. Looks like it just sets the pid owner:group. Sorry, I didn't realize that was the extent of it when saw the mountpoint was still root:root. 2) As far as the permission problem when starting owserver, I am in the 'uucp' group and the 'owfs' group: $ groups wheel uucp cdrom apache usb users owfs portage and ls -l /dev/ttyS1 crw-rw---- 1 root uucp 4, 65 Dec 30 05:05 /dev/ttyS1 I see what you are saying in the ebuild notes now, but it took several reads to catch it. Maybe it could be reworded. I think most people see 'user' and assume it means them, but in this case it meant the owfs daemon user (owfs). In my defense, I didn't have to do that with my script or any of the other scripts used to test owfs. All I had to do was make sure the User user was in uucp group. But it does work now with the gentoo script. 3) The current /etc/conf.d/owfs is not used by the init scripts. /etc/init.d/owfs is told to use ${OWHTTPD_OPTS . Unless I am mistaken again, shouldn't that be ${OWFS_OPTS . That is what I changed mine to. 4) Actually I am using owfs-2.7p2 but the new bug for this version wasn't out yet. I am testing 2.7p2 for Paul A. because it has a lot of fixes in it. Have been using it since the 27th and working great on my x86 system. That is why I am also testing the gentoo scripts, because we are trying to get a reliable startup with certain devices like hubs.
