
Symbolic links in Linux are a fantastic feature, but they can be broken and left pointing at nothing. Next, We tell you how to locate broken symbolic links, review and remove them from your system if necessary.
symbolic links 101
Symbolic links, also called “smooth links” and “symbolic links”, they are a form of shortcuts that can point to files and directories. A symbolic link looks like a normal file or directory in a file manager window. Also appears as an entry in a file list in a terminal window. The file or directory that the symbolic link points to can be anywhere in the file system tree.
As an example, Let's say you have a symbolic link in your home directory called "dave-link" that points to a file called "text-file.txt" located somewhere else in the filesystem tree.. The commands you use in the symbolic link are automatically applied to the file it points to. If you try to use cat
O less
in the symbolic link, you will see the content of the file “text-file.txt”.
A standard Linux installation contains many symbolic links. Even if you don't believe them yourself, the operating system uses them. Application installation routines often use symbolic links to point to executable files. When the software is updated, the binary file is replaced by the new version and all symbolic links continue to work as before, as long as the name of the new file is the same as the old one.
We can easily see some symbolic links using ls
in the root directory. Some of the tickets are shown in a different color; on our Ubuntu test machine 20.10, shown in light blue.
We write the following:
ls /
We can take a deeper look using the -l
(long list) option. We write the following command to see all the inputs “lib” and the only entrance “bin”:
ls -l / lib * / bin
At the beginning of each line there is a “l”, which indicates that the element is a symbolic link. The text after “->”Shows what the symbolic link points to. In our example, the destinations are all directories.
Permissions are listed as read, deed and execution for the owner, the group and others. These are default bogus entries. They do not reflect the actual permissions on the objects pointed to by the symbolic links. It is the permissions on the destination file or directory that have priority and are respected by the file system.
broken symbolic links
A symbolic link is broken (or is left hanging) when the file it points to is deleted or moved to another location. If an app's uninstall routine doesn't work properly or is interrupted before it completes, you may be left with broken symbolic links.
If someone manually deletes a file without knowing that the symbolic links point to it, those symbolic links will stop working. They will be like road signs pointing to a city that has been razed.
We can easily see this behavior by using a symbolic link called “hello” in current directory. We write the following, using ls
to see:
ls -l
Point to a program called “htg” in a directory called “bin”. If we "execute" the symbolic link, run the program for us:
./hello
Now we can check if this is what is happening by running the program directly:
../bin/htg
How could we wait, we get the same answer. Let's delete the program file:
rm ../bin/htg
Now, when we look at the symbolic link, we see that it is in red because Linux knows that it is broken. It also tells us what it used to aim for, so we can replace the file, recompile the program or do whatever is necessary to repair the symbolic link.
Note that if we try to execute the symbolic link, the error we get refers to the name of the symbolic link, instead of the name of the program to which the symbolic link points.
We write the following:
./hello
Find broken symbolic links
Most modern versions of find
have the xtype
option (extended type), which simplifies the search for broken symbolic links. We will use the l
flag with xtype
, to instruct you to search for links. Using find
and xtype
in the next way, without any of the others type
banderas, forces xtype
to return broken links:
find . -xtype l
When running the command in our test home directory, there are quite a few broken symbolic links. Note that the search is recursive by default, so it searches all subdirectories automatically.
The symbolic link “hello” that we broke on purpose appears in the list, as we expected. One of the other symbolic links is related to the Firefox browser, and the rest is related to snapshots.
If we funnel the output through wc
with the -l
(lines), we can count the lines, which is the same as counting broken symbolic links.
We write the following:
find . -xtype l | wc -l
We are informed that we have 24 broken symbolic links pointing to nothing.
Look for, review then remove
Before you rush and remove all the broken symbolic links, see the results of the find
command. See if there is a valid reason for any of the broken symbolic links.
Sometimes, the symbolic link may be the problem, instead of the destination file. If the symbolic link was created incorrectly, it is feasible that it does not aim at anything, but the real goal is present. Then, the answer would be to recreate the symbolic link.
It is also possible that an apparently broken symbolic link is being used as something else, as a file lock indicator or other go indicator / not to go. Firefox does this; that's the first symbolic link on our list. Despite this, Firefox is not used on our test machine, so it is safe for us to remove it.
It is also possible that the target is only present periodically, and this is the expected behavior (and desired) of that particular software. Maybe the destination file is copied from another machine or from the cloud, performs its function and then is removed again, only to be replaced by a different program in the next cycle.
The broken symbolic link can also be a symptom of a failed software installation.. Then, instead of removing the symbolic link, you need to fix it manually or repeat the installation.
When you have fixed the broken links you need to keep, repeat the command to search. Fixed symbolic links should be absent from search results.
For the sake of safety, it is better to limit the removal of symbolic links to your own directories. Be very careful when running these commands as root or in system directories.
Delete broken symbolic links
the -exec
The option (run) run commands on the find
Search results. We are going to use rm
to remove every broken symbolic link. the {}
The string is replaced with the name of each broken symbolic link as each one is discovered by find
.
We have to use a semicolon (;
) to finish the list of commands we want -exec
to run. We will use a backslash () in order to “escape” semicolon, so it is treated as part of the
find
command, instead of something Bash
must act.
We write the following:
find . -xtype l -exec rm {} ;
We go back to the command prompt without any indication that something has happened. To verify that broken links have been removed, we repeat the command to search for them, in the next way:
find . -xtype l
No matching results, which means broken symbolic links have been removed.
Remember to check first
Again, always take the time to review a list of symbolic links before running the command to remove them. You can avoid removing any of the unsure ones by running the command to remove them in the appropriate directories.
As an example, above, we could have run the command in the directory “.snap” and after having manually removed the lonely symbolic link “hello”. This would have left the Firefox blocking symlink intact.
setTimeout(function(){
!function(f,b,e,v,n,t,s)
{if(f.fbq)return;n=f.fbq=function(){n.callMethod?
n.callMethod.apply(n,arguments):n.queue.push(arguments)};
if(!f._fbq)f._fbq = n;n.push=n;n.loaded=!0;n.version=’2.0′;
n.queue=[];t=b.createElement(e);t.async=!0;
t.src=v;s=b.getElementsByTagName(e)[0];
s.parentNode.insertBefore(t,s) } (window, document,’script’,
‘https://connect.facebook.net/en_US/fbevents.js’);
fbq(‘init’, ‘335401813750447’);
fbq(‘track’, ‘PageView’);
},3000);