Differences between current version and revision by previous author of CommonErrors.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
Newer page: | version 42 | Last edited on Saturday, May 20, 2006 10:03:48 pm | by AristotlePagaltzis | |
Older page: | version 41 | Last edited on Friday, May 19, 2006 6:59:28 am | by GemmaPeter | Revert |
@@ -1,154 +1,134 @@
-!!error while loading shared library.
cannot open shared object file
+!!! <tt>
error while loading shared library. cannot open shared object file</tt>
-This occurs when it can't load a shared library, use "
ldd(1)"
to determine which libraries this program is trying to link against and which ones are missing or can't be linked against.
eg:
-
ldd /bin/cat
+Use
ldd(1) to determine which libraries this program is trying to link against and which ones are missing or can't be linked against,
eg. <tt>
ldd /bin/cat</tt>.
-In Linux, one possible reason for this is that the shared library
is not in /usr/lib. Either moving
the existing library
to /usr
/lib, or
creating a symlink
in /usr/lib to its
current location (e.g., ln -s
/usr/local
/lib/libdmalloc.so /usr/lib/libdmalloc.so
).
+In [
Linux]
, one possible reason for this is that the SharedLibrary
is not in <tt>
/usr/lib</tt> or one of the other directories which are searched for shared libraries
. In that case, add
the directory
to <tt>
/etc
/ld.so.conf</tt> and run ldconfig(8). (Other ways of dealing with this are
creating a SymLink
in <tt>
/usr/lib</tt>
to the
current location of a library or moving the library to <tt>
/usr/lib<
/tt> (this is not advisable
).)
-----
-!!"No such file or directory" or "Bad interpreter: no such file or directory"
+!!! <tt>/path/to/program: No such file or directory</tt> %%% <tt>/path/to/program: bad interpreter: No such file or directory</tt>
-If you see this message when trying to run
a program
, even though you can plainly see
it right in front of you
, there are
a couple of possibilities:
+*
If it is
a dynamic BinaryExecutable
, it is possibly linked against a library that doesn't exist
, or against
a specific SharedLibrary on your system that has the same name but contains different symbols as on the machine that the file was compiled on.
-1) Executable
is a script
- If it is some kind of script, it might point to an interpreter that doesn't exist on your system. For example, it used to be common to see perl scripts whose first line was:
-<verbatim>
- #!/usr/local/bin/perl
-</verbatim>
- But if you had perl installed
as /bin/perl or /usr/bin/perl
you would
get this message.
+ This
is particularly annoying
as you can also
get this message when trying to use ldd(1) to find out which dynamic library is causing the problem
. Eg.:'''
- Another possibility is that the script was edited on windows, or another
- editor that added windows' style line endings (carriage-return + linefeed)
.
- Try using "dos2unix"
or "tr
-d '\r'" to go back to normal newline (linefeed
- only
) line endings
.
+ <verbatim>
+ $
./ninfo
+ zsh: no such file
or directory: ./ninfo
+ $ file ninfo
+ ninfo: ELF 32
-bit LSB executable, Intel 80386, version 1,
+ dynamically linked (uses shared libs
), not stripped
+ $ ldd
./ninfo
+ /usr/bin/ldd: ./ninfo: No such file or directory
+ </verbatim>
-2) Executable is a binary
- Your dynamic binary executable is linked against
a library that doesn't exist
, or against a specific dynamic library on your system that has the same name (but different binary interfaces??) as the machine that the file was compiled on. This is particularly annoying as
you can also get this message when trying to use ldd(1) to find out which dynamic library is causing the problem!
+ This makes diagnosis
a bit harder! However
, you can try:''''
- Sometimes, missing libraries can cause ldd itself to fail, which can make it difficult to determine what the problem is. Eg:
-
<verbatim>
- $ .
/ninfo
- zsh: no such file or directory: .
/ninfo
- $ file
./ninfo
-
./ninfo: ELF 32
-bit LSB executable, Intel 80386, version 1, dynamically linked (uses
- shared libs), not stripped
- $ ldd
./ninfo
- /usr/bin/ldd
: ./ninfo
: No such file or directory
-</verbatim>
+
<verbatim>
+
$ /lib
/ld-linux
.so
.2 --verify -
-list
./ninfo
+
/usr/local
/bin/ninfo
: error while loading shared libraries:
+ libc
.so.5: cannot open shared object file
: No such file or directory
+
</verbatim>
- This makes diagnosis a bit harder! However, you can try
:
-<verbatim>
- $ /lib/ld-linux.so.2 --verify --list ./ninfo
- /usr/local/bin/ninfo: error while loading shared libraries: libc.so.5: cannot
- open shared object file: No such file or directory
-</verbatim>
- or
-<verbatim>
- $ strings ./ninfo | grep
'\.so
'
- /lib/ld-linux.so.1
- libtermcap.so.2
- libc.so.5
-</verbatim>
- and it becomes clear that this program is linked against very old versions of libraries that don
't exist any more. The program needs to be re-compiled against current versions (you do have the source code, right?)
+ Or
:''''
+ <verbatim>
+ $ strings ./ninfo | grep \.so
+ /lib/ld-linux.so.1
+ libtermcap.so.2
+ libc.so.5
+ </verbatim>
-3) File
is in a partition where
the noexec is on
- To check this look in /etc/fstab
+ It then becomes clear that this program
is linked against very old versions of libraries that don't exist any more. The program needs to be re-compiled against current versions. (You do have
the source code, right?)
-----
+* If the executable is some kind of script, it might point to an interpreter that doesn't exist on your system. For example, [Perl] scripts often started with <tt>#!/usr/local/bin/perl</tt> when you had <tt>perl</tt> installed as <tt>/bin/perl</tt> or <tt>/usr/bin/perl</tt>.
-!!Xlib: connection to ":
." refused by server
-
<verbatim
>
- Xlib: connection to ":." refused by server
- Xlib: Client is not authorized to connect to Server
- some_app: unable to open display ":."
-
</verbatim
>
-The user running the command is different
to the user that started the X-server, or is otherwise not allowed by the X server
to create new
(graphical
) windows
.
+ Another possibility is that the script was edited on MicrosoftWindows, or another editor that added Windows style line endings (Carriage Return + Linefeed)
. Try using
<tt
>dos2unix
</tt> or <tt>tr -d '\r'</tt
> to go back
to Unix style line endings
(Linefeed only
).
-Also see
the [XFree86Notes] page on giving other users permission
to open graphical windows on your X server
.
+ Lastly,
the script might be fine and its interpreter might exist, but the interpreter might not be launchable. This is what <tt>bad interpreter</tt> means here, but only bash(1) seems
to provide that helpful part of the message, not zsh(1). If that is the case, see below
.
-----
+!!! <tt>/path/to/program: Permission denied</tt> %%% <tt>/path/to/program: bad interpreter: Permission denied</tt>
-!!-bash: /bin/bash: Permission denied:
/path/to/program
+* The executable bit is not set on the program file. Issue <tt>chmod a+x
/path/to/program</tt> to fix this.
-!!bash: /path
/to/script:
/bin
/bash: bad interpreter: Permission denied
+* The program is located on a [Partition] that is mounted <tt>noexec<
/tt>. Alternatively, on many LinuxDistribution~s you can't run executables from removable media such as [CDROM]s and floppies, due
to the <tt>user</tt> mount option. Check your <tt>
/etc
/fstab<
/tt>. See also mount(8).
-Note that other shells (such as zsh(1)) don't give
the "bad interpreter" part of
the message for some of the following circumstances - only bash(1) seems
to.
+* Some secure [Kernel]s used by certain LinuxDistribution~s will throw this error occurs when
the directory containing
the program is world writable, eg. if you are trying
to launch <tt>~~/bin/prog</tt> and <tt>~~/bin</tt> is world/group-writable. Issue <tt>chmod go-w ~~/bin</tt> and try again
.
-Possible causes for this message (in decreasing order of probability):
-
* /bin/bash exists and runs fine; the probable cause is
the program is a script and
the "u+x" bit is not set on
the script
.
("chmod a+x program" would also set it.
) Bash will report this even if
the script is not a bash script - that is because bash has to first load
and run the script, which is can't do
.
+* If you get the <tt>bad interpreter<
/tt> message,
the program is a script whose interpreter has one of
the above problems. Unfortunately, only bash(1) seems to provide that helpful part of
the message
. If you use another shell, such as zsh
(1
), you must check both
the script and its interpreter for these problems
.
-* This error occurred on my system on the /var directory because /dev/hda5 was mounted on /var with the option "noexec". This is also the case for [CDROM]s and floppy drives - by default in many distributions you can't run executables from removable media. (This is caused by the "user" mount option.)
-* It is possible (but very unlikely) that /bin/bash (or whatever shell the script uses) isn't executable, and since it is a bash script the kernel is trying to start bash.
-
<verbatim
>
- chmod a+rx /bin/bash /usr/bin/perl /usr/local/bin/perl ''/path/
to/your/script/here''
-
</verbatim
>
-this will mark these all as executable and readable by everyone.
+!!!
<tt
>Xlib: connection
to ":." refused by server
</tt
>
-* It
is possible
that the interpreter being used
is not runable, for example it has unresolved link dependencies as described earlier in
the page
.
+The user running the command
is different to the user
that started
the [XServer], or
is otherwise
not allowed by
the [XServer] to create new (graphical) windows. See [XFree86Notes] on giving other users permission to open graphical windows on your [XServer]
.
-* Mandrake 9.1 using the secure kernel: this error occurs when the directory containing the script is world writable. e.g.: the script ~~/~MyDir/myscript.sh will give this error if the directory ~~/~MyDir is world- (or group-?)writable. chmod 700 ~~/~MyDir and try again :)
-* This error will occur when trying to execute a script if the mount point that the directory
is in was
mounted with the option "noexec"
. See the mount(8) ManPage
.
+!!! <tt>ping: unknown protocol icmp</tt>
+
+If <tt>/proc</tt>
is mounted, your interfaces are correctly configured, and <tt>/etc/protocols</tt> is fine, check <tt>/etc/nsswitch
.conf</tt>
. It might be declaring other sources than <tt>/etc/protocols</tt> as authoritative:
-----
-!!ping: unknown protocol icmp
<verbatim>
- cobalt root # ping
- ping
: unknown protocol icmp.
+protocols
: ldap [NOTFOUND=return] files
</verbatim>
-I googled for this, and only found suggestions to make sure /proc was mounted (which it was) and that my interfaces were correctly configured (which they were, and I dont see why this would matter). I asked GreigMcGill, and he suggested
/etc/protocols issues: my /etc/protocols was fine, *BUT* my system had taken upon itself to declare my LDAP server as authoritative for protocols in /etc/nsswitch.conf:
-<verbatim>
- protocols: ldap [NOTFOUND=return] files
-
</verbatim
>
-Deleting the ldap portion (
as I don't have protocols info in the LDAP tree) fixed this
:
+
+Here you could allow <tt>
/etc/protocols</tt
> as a fallback
:
+
<verbatim>
-
protocols:
files.
+protocols: ldap
files
</verbatim>
-!!ping
: sendto: Operation not permitted
+Or delete every other source all together
:
+
<verbatim>
- PING 192.168.66.10 (192.168.66.10)
: 56 data bytes
- ping: sendto: Operation not permitted
- ping: wrote 192.168.66.10 64 chars, ret=-1
+protocols
: files
</verbatim>
-The interface you are pinging out of (192.168.66.10) is firewalled. Fix your firewall :)
-----
+!!! <tt>ping: sendto: Operation not permitted</tt>
-!!Your shell hangs
-Your shell hangs, and it even ignores ctrl-c
. You have to close the xterm
(or gnome-terminal or konsole
) to remove the process
.
+ <verbatim>
+ PING 192
.168.66.10
(192.168.66.10
): 56 data bytes
+ ping: sendto: Operation not permitted
+ ping: wrote 192
.168.66.10 64 chars, ret=-1
+ </verbatim>
-Possible answer:
you have inadvertently typed the special "stop" flow control character used by terminals. By default, this is ^S
(control-s)
. By default, control-q sends a start character again
. This
is particularly common if you were pressing ctrl-d or ctrl-a or a nearby key on a QWERTY keyboard
.
+The interface
you are pinging out of
(192
.168
.66.10)
is firewalled. Fix your FireWall
.
-You can use the stty(1) program to change this behaviour:
- $ stty -ixon
-will tell your terminal not to use XON/XOFF flow control.
- $ stty stop ""
-will mean that no character sends a stop character.
- $ stty stop " "
-causes your terminal to stop every time you press space. This is probably not a very clever thing to do (unless you are playing a trick on someone...)
+!!! The shell hangs
-Re
-defining
the stop key has the added advantage that you can then use ctrl
-s
to search your command line
in bash(1)/zsh(1) as well as ctrl
-r
for reverse search.
+Your shell hangs and even ignores Ctrl
-C. You have to close the terminal to remove the process.
+
+Possible answer: you have inadvertently typed the special stop flow control character used by terminals. By default, this is Ctrl-S, with Ctrl-Q sending a start character. This is particularly common if you were pressing Ctrl-D or Ctrl-A or a nearby key on a QWERTY keyboard.
+
+You can use the stty(1) program to change this behaviour. <tt>stty -ixon</tt> will tell your terminal not to use XON/XOFF flow control. You could also say <tt>stty stop ''</tt> to specify that no character sends a stop character. If you want to play a practical joke on someone you could issue <tt>stty stop ' '</tt>, which will tell the terminal to stop every time they hit space. To restore the default, you can use <tt>stty stop ^s</tt> (the circumflex is a common way to spell “Ctrl-” on Unix). Redefining
the stop key has the added advantage that you can then use Ctrl
-S
to search your command history
in bash(1)/zsh(1) as well as Ctrl
-R
for reverse search.
+
+
+!!! Xscreensaver: <tt>couldn't create GL context for visual 0x21</tt>
-----
-!!! Xscreensaver gives "couldn't create GL context for visual 0x21"
Symptom: xscreensaver(1) gives this message when trying to run one of the 3D screensavers, even though you can run it fine from the command line (such as $/usr/lib/xscreensaver/bubble3d). Or perhaps it works fine when run in a window, but not fullscreen.
-You are probably using the nvidia binary drivers
for [XFree86]. The problem is that these drivers mmap(2) large parts of the graphics card's memory and registers into virtual memory
, and xscreensaver defaults to having a limit on the amount of memory it uses. For example
:
- 20502 john 16 10 139m 8096 2632 S 1.9 3.2 :00.22 sierpinski3d
-This [OpenGL] application has 139MB of addressable space in use, but it is not using that much virtual memory. Edit ${HOME}
/.xscreensaver and edit the line that says
-
memoryLimit: 50M
+You are probably using the nVidia BinaryDriver~s
for [XFree86]. The problem is that these drivers mmap(2) large parts of the graphics card's memory and registers into VirtualMemory
, and xscreensaver(1)
defaults to having a limit on the amount of memory it uses. Eg.
:
+
+ <verbatim>
+
20502 john 16 10 139m 8096 2632 S 1.9 3.2 :00.22 sierpinski3d
+ </verbatim>
+
+This [OpenGL] application has 139MB of addressable space in use, but it is not using that much virtual memory. Edit <tt>~~
/.xscreensaver</tt>
and edit the line that says
+
+<verbatim>
+
memoryLimit: 50M
+</verbatim>
+
to either something much bigger, or set it to 0 (for no limit).
-----
-!! *** attempt to put segment in horiz list twice
-You might see this error message if you use GNOME - it appears quite regularly in my $HOME/.xsession-errors file.
-It is '
mostly harmless'
, and
seems to occur most frequently when activating menus. Apparently
, it is
caused by libsvg/libarts, and
implies a minor problem with one of the [SVG] icons.
+
+!!! <tt>~*~*~* attempt to put segment in horiz list twice</tt>
+
+You might see this error message if you use [GNOME] – it appears quite regularly in my <tt>~~/.xsession-errors</tt> file.
+
+
It is "
mostly harmless,"
seems to occur most frequently when activating menus, and appears to be
caused by libsvg/libarts. It
implies a minor problem with one of the [SVG] icons.
+
----
+
For more errors see: CategoryErrors