Red Hat Bugzilla – Bug 1477623
Running file API on a special chardev may hang forever
Last modified: 2017-08-08 13:27:09 EDT
Created attachment 1308246 [details]
Dockerfile to reproduce the issue
Description of problem:
When you try to run the file tool on special chardevices like /dev/console or /dev/tty on your machine, it works fine.
For example it reports the following output:
$ file /dev/console
/dev/console: character special (5/1)
$ file /dev/tty
/dev/tty: character special (5/0)
But using libguestfs, it somehow hangs, and it don't see why, as it should just run the file tool and returns the output i guess ??
-> libguestfs hangs forever
Version-Release number of selected component (if applicable):
latest available on Ubuntu 16.04
Steps to Reproduce:
1. mount the filesystem in libguestfs
2. using the python API run g.file('/dev/console')
libguestfs should return /dev/console: character special (5/1)
I provided a Dockerfile for you to reproduce the issue.
You can take it from here : https://gist.github.com/Wenzel/09b222f3572fa34ec01b50f69c5a556e
1. docker build -t libguestfs-bug-file .
2. docker run --rm -it libguestfs-bug-file
Running it will drop you into a ipython shell with libguestfs initialized and a image is already mounted.
Thanks a lot !
$ virt-builder fedora-26
$ guestfish -a fedora-26.img -i
><fs> mknod-c 0777 5 1 /dev/console
><fs> ll /dev
drwxr-xr-x. 2 root root 21 Aug 2 13:41 .
dr-xr-xr-x. 17 root root 224 Jul 19 14:39 ..
crwxr-xr-x 1 root root 5, 1 Aug 2 13:41 console
><fs> file /dev/console
Reproducible for me in libguestfs-1.36.5-1.fc26.x86_64
Also reproducible with libguestfs from git (with the OCaml API).
Grrr I thought we'd fixed this bug years ago :-(
*** Bug 1477665 has been marked as a duplicate of this bug. ***
These two bugs are different aspects of the same problem.
The guestfs_file API filename parameter is marked as Dev_or_Path:
This is supposed to allow you to do g.file ("/dev/sda1") and have it
do the obvious thing.
This is implemented by looking at the appliance device node if we think
the parameter corresponds to a device.
However the stub code in the daemon only checks if the path begins with
"/dev/", which is not very clever. It should really check if the path
corresponds to the name of an appliance block device (possibly untranslated).
In any case I wouldn't try using guestfs_file on /dev/ paths. Even if
we fix this problem it won't return any useful information because the
implementation simple returns fixed strings like "block device" etc for
anything which is a block device etc. It's probably better to use g.statns()
first and only call g.file() for regular files which don't begin with "/dev/".
That was a bit harder than I thought it was going to be, but
This is fixed upstream in libguestfs >= 1.37.21.