https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198085
Bug ID: 198085
Summary: service devfs restart leaks tap devices
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
The /dev/tap* interface has become somewhat unstable as of 10.1-R; One
particular problem is that every time I reload devfs (testing rulesets in a set
of jails), the system creates a whole new set of tap interfaces. For example:
root@tokyo:~ # ls /dev/tap* | wc
198 198 2266
root@tokyo:~ # service devfs restart
root@tokyo:~ # ls /dev/tap* | wc
205 205 2350
The other issue is with the "new" (to me) /dev/tap pre-interface that client
utilities need to use to select and register a tap device. This device doesn't
consistently get created by devfs.rules in jailed environments, causing
programs that depend on tap to fail on startup.
root@tokyo:~ # head /etc/jail.conf
pdc1 {
mount.devfs;
devfs_ruleset = 5;
...
root@tokyo:~ # cat /etc/devfs.rules
[devfsrules_pdc1=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'tap' unhide mode 0600 group wheel
add path 'tap0' unhide mode 0600 group wheel
add path 'bridge0' unhide mode 0600 group wheel
root@tokyo:~ # service jail start pdc1
Starting jails: pdc1.
root@tokyo:~ # ls -l /jail/pdc1/dev/tap
ls: /jail/pdc1/dev/tap: No such file or directory
The device itself doesn't show up in directory listings, which can cause
scripts that expect to "see" it to fail. (I suspect this is also causing
devfs.conf not to be able to correctly set permissions on this device.)
root@tokyo:~ # ls /dev/tap* | xargs echo | grep '/dev/tap '
(nothing returned)
If this interface is undergoing development, I'd understand these
instabilities; If my system is missing configuration files that control this
behavior, then my apologies. Either way, would love to hear the development
team's thoughts on this. :)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
