The following error message occasionally appears in my terminal:
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
… which is pretty annoying.
I have searched online for solutions to this error, without success.
Is there any way to at least identify the process responsible for sending these error messages to my terminal?
Let me clarify that, as far as I can tell, these error messages appear "out of the blue". In fact, they appear asynchronously with respect to my interactions with the terminal (more often than not I see them for the first time when I return to a terminal window that has been unattended for some time). I'm sure there's a definite, deterministic cause for these messages, but it is not one that I can readily identify. In short, I have not noticed any pattern or regularity to their occurrence.
In particular, in my case their occurrence has nothing to do with running MPlayer, or any other video playback program. (Please refer to my earlier post about it.) For one thing, the machine in question is a work machine, and I rarely watch any videos with it. In the very few instances in which I've watched a video on this machine I've used VLC, not MPlayer, and these errors never appeared in these rare occasions that I used VLC.
Best Answer
lsof "$(tty)"
does what you ask, by listing what has your terminal open for read or write.You can check what has been writing to your terminal if it still has your terminal open, which is usually the case, at least if it is still running. It is possible for it to have output an error message to your terminal, closed the file descriptor for it, but kept running. But the more likely reason you wouldn't be able to check is if the process itself runs only intermittently.
jobs
shows your background jobs. If you've run the process yourself with&
so it runs asynchronously--or suspended it with Ctrl+Z--and it is still running, then thejobs
builtin will show it unless you havedisown
ed it.lsof "$(tty)"
lists everything that has your terminal open for reading or writing. This works even in the rare case of something that writes to your terminal without ever having been started from it or being descended from some other process that was.It is possible that you have many graphical programs that have your terminal open for write:
unity --replace &
from your terminal, that would explain unexpected errors from applications appearing in it.pstree
to see your process tree, which may help.Your terminal device is a "file" and you can pass its filename to
lsof
.You can get a list of processes that have the current terminal--the terminal in which you run the command--open for reading or writing, by passing the path to its device node to the
lsof
command. Sincetty
outputs that path, you can run it and then runlsof
with what it shows you, or you can use any of the following:The output will usually look something like this, if the only programs you're running in your terminal are your shell and--of course--
lsof
itself:If you have more things running that read from or write to your terminal, they should be shown. Note that the commands shown above must be run from the terminal where you see the annoying messages. You can do this from a separate terminal, too, but you must give
lsof
a path to the terminal you're interested in. For example, you can runtty
in the terminal you want to know about, then use the path it shows you as the argument tolsof
in the terminal you want to run it from.Regarding access and permissions, you may be wondering:
tracefs
warning may or may not appear for you. Either way, you probably needn't worry. Usually it's from the debug filesystem being altogether unavailable rather than being restricted to you, so...lsof
as root withsudo
, but probably not. Usually you can view information about all processes, and even if your system is configured not to allow that, whatever is doing this is probably running as you anyway.Some processes appear more than once, because they have your terminal open more than once. I don't really recommend trying to show only processes that have your terminal open for write, though, because:
jobs
anyway, which gives one line (or fewer) per process. If you're usinglsof
, you want details.An
lsof
example:cat
ing from one terminal to another.You don't have to do this--it's really just a demonstration. This section exists only because:
lsof
and want some kind of confirmation that it really is showing you processes that write to your terminal, even if they were not started from it.If you just run
tty
in your terminal, by itself, it prints the path to your terminal's device node:This will not always be
/dev/pts/0
. You can open another terminal and runtty
and the path will be different. Go ahead and do that.In the second terminal, run
cat
but redirect its output to the first terminal. To do that, run this but replace/dev/pts/0
with whatevertty
showed you when you ran it in the first terminal:Type text in the second terminal and press Enter. It will appear in your first terminal.
In the first terminal, run any of the
lsof
commands shown above.Your terminal won't highlight the line with
cat
--I just did that to show the difference.(In the second terminal where
cat
is running, you can quit it by pressing Ctrl+D at the beginning of a line, or just by pressing Ctrl+C. If you type text on a line and then press Ctrl+D, that will flush the input buffer even though you haven't pressed Enter, and you will see the text on the first terminal.)Debugging "Failed to open VDPAU backend" Errors
Although that's a general answer to the question of how to find what's writing to your terminal and it may well help you, there are other approaches you should consider, for the particular problem you've described here. Aside from kernel messages on virtual consoles--which this is not--messages shown in your terminal usually come from some program you have run from your terminal, or some program that one of those programs has run, etc.
As NickTh's answer says, if you're not manually running anything from your terminal that seems like it could produce those messages, check the files your shell may run commands from when it starts, especially
.profile
and.bashrc
(as NickTh mentions) because those are the ones you're likely to have modified.The error you are seeing probably isn't a bug in MPlayer itself, but instead in a library it uses, which is used by many other programs. If you are running any graphical programs from your terminal--especially if you have placed them in the background with
&
, so they run asynchronously with your shell--then one or more of them is almost certainly the reason you're seeing these messages. Web browsers are particularly likely to produce them, mainly because they may run plugins, such as Adobe Flash, that use the affected library.There are a number of bugs reported on Launchpad about error messages like this one. Bug 808254 is particularly similar to what you have described. Bug 1300215 is especially prominent, though it involves an Intel video driver. You can search Launchpad for text from the message to find more bugs. You may find workarounds--either just for silencing the messages or for doing more about the bug--in such bug reports and their comments. In addition, while the other question linked to in NickTh's answer is about the problem is it occurs in MPlayer and has several MPlayer-specific workarounds as answers, the currently top-voted answer is not specific to MPlayer and may work for you.
If you're running many programs from your terminal, you may have seen many entries in the output of
lsof
(if you decided to use that method in your troubleshooting). One way to figure out which program is producing the output is to run your programs from separate terminals. This works even if your separate terminals are started from each other--a GUI terminal emulator like GNOME Terminal does not pass the error messages or other text that it displays up to the terminal from which it was itself run (if any). Similarly, one way to stop being bothered by this problem--assuming the annoying messages are the only real problem--is to not run things from your terminal that you don't want output from in your terminal. Normally you can achieve this by using your graphical menus instead. But please see the top of this answer for why you might be running more from your terminal than you need or intend.