Bug 198085
| Summary: | service devfs restart leaks tap devices | ||
|---|---|---|---|
| Product: | Base System | Reporter: | brian |
| Component: | bin | Assignee: | Kyle Evans <kevans> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Only Me | CC: | emaste, kevans |
| Priority: | --- | ||
| Version: | 10.1-RELEASE | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
/dev/tap device "instability" may have been due to sysctl setting: root@tokyo:/etc # ls -l /dev/tap ls: /dev/tap: No such file or directory root@tokyo:/etc # sysctl -a | grep net.link.tap.dev net.link.tap.devfs_cloning: 0 root@tokyo:/etc # sysctl -w net.link.tap.devfs_cloning=1 root@tokyo:/etc # sysctl -a | grep net.link.tap.dev net.link.tap.devfs_cloning: 1 root@tokyo:/etc # ls -l /dev/tap crw------- 1 root wheel 0xa9 Feb 28 15:30 /dev/tap It is this sysctl that's making the /dev/tap* devices spawn too frequently, though. (When set to zero, the "service devfs restart" command doesn't cause them to continue accumulating.) Also still unable to see /dev/tap with a glob, but as long as the program (qemu-devel) can load it by explicit name, it's not the end of the world for me. Hi, Taking, since I'm working on tun/tap. Is this still relevant in later FreeBSD versions? I can't seem to reproduce it (but also don't immediately see what might have fixed it), and will likely close this in two weeks as "overcome by events" unless I hear back. The frequent spawning is indeed because of devfs cloning, any lookup of /dev/tap or any /dev/tapNN that doesn't exist will cause it to get created. You can cause two or three with a simple chmod 0777 /dev/tap, even. devfs cloning in a jail can work, but it would require an unwritten MAC module to do so, IIRC. The canonical solution for this is to pre-create the tap device and unhide it in the jail. Closing this with "Works As Intended" -- the cloning behavior isn't ideal, but it is expected and non-trivial to solve. devfs cloning in a jail should not be allowed without some consideration. |
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. :)