Date: Fri, 27 Feb 2015 21:51:02 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 198085] service devfs restart leaks tap devices Message-ID: <bug-198085-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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: freebsd-bugs@FreeBSD.org Reporter: brian@shadowcom.net 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-198085-8>