I'm working on Linux CentOS 6.5.
Can someone explain to me the following:
[root#zwoop html]# locate l4_test
/var/www/html/l4_test
[root#zwoop html]# file /var/www/html/l4_test
/var/www/html/l4_test: cannot open `/var/www/html/l4_test' (No such file or directory)
I want to delete this folder, but I'm not allowed to delete it with
rm -R /var/www/html/l4_test
Because apparently it does not exist, even though it exists...
Thanks.
As the manual describes, locate reads one or more databases prepared by "updatedb".
It may not have the latest information if it's been a while since the last updatedb.
Run it manually (updatedb) and then try locate.
Related
I have a dynamic linker which is /lib64/libc.so.6
I stupidly renamed it to /lib64/libc.so.6.old and now NO commands work.
I cannot do ls or mv to rename it back.
I can run ldconfig but it says permission denied and I cannot run sudo or su - What on earth can I do to fix this? I am running Oracle Linux redhat 6.7
LD_PRELOAD=/lib64/libc.so.6.old mv /lib64/libc.so.6.old /lib64/libc.so.6
Start from a recovery/install iso and rename the file back.
If you can't reboot or don't have physical access to the machine you could try to install a compiled version of BusyBox https://busybox.net/FAQ.html#getting_started and use its su and mv commands. Since BusyBox is statically linked it should work without libc.so.
Go to single user mode, mount the file system with rw, since you know the location of the renamed file move /lib64/libc.so.6.old /lib64/libc.so.6
I would also propose a workaround with a mount point as already mentioned by #wildplasser.
You can make majority of command line tools working again if you have a mounted directory on your broken host. If you are lucky to have one then all you need is to upload the libc-x.yz.so (which you can take from another host of from Internet) on the share, rename it there to libc.so.6 and add the mounted directory to LD_LIBRARY_PATH.
If the version x.yz is the same as for the one which you thoughtlessly moved then the commands like ls, cp etc. will work again in the console where you set LD_LIBRARY_PATH. You should not logout from this console, because you won't be able to login again.
! Be aware that setuid command line tools won't work (see https://askubuntu.com/a/1029363/832810). Unfortunately "sudo" is one of them, this is why you won't be able to put back easily your long-suffering .so (unless you have a root# console). However it gives you a possibility to save all data and finish all actions before you do some hard restore.
If you managed to do the above-mentioned trick and you have enough time you can try to build a statically linked version of "sudo" as suggested on https://askubuntu.com/a/1030475/832810 (probably even build on another host and copy through NFS) and move the .so back using it.
I just found Matlab (2016a) put a 2.5 Gb installation files that it fetched during the installation in the root home directory (Linux mint 18), under /root/Downloads/MathWorks. I guess it is probably because I use sudo for installation.
My question is:
Is it normal that program store information when user executes it with sudo?
Can I delete the file under /root/Downloads? (My limited Linux knowledge told me do not touch anything in the /root folder)
When you execute anything with su...do, you basically execute it 'as' root.
Mathworks uses the Download-Folder (which is in your case /root/Downloads - since you have executed the installer as root) for temporary data (According to https://de.mathworks.com/matlabcentral/answers/229835-is-the-mathworks-folder-necessary-to-run-properly?requestedDomain=www.mathworks.com).
So, yes. It seems like you can delete the folder.
Or just move it to MathWorks.bak and check if Mathworks still works properly. In case everything is working fine, you can delete MathWorks.bak.
A program can do anything when run as sudo and depends only on what the program is designed to do. sudo simply elevates the permissions when running a given command.
I would have thought that the installer would have downloaded everything to /tmp instead of /root/Downloads, but as long as you didn't select /root/Downloads as your installation directory for MATLAB and this is only the temporary download location you can certainly remove it after successfully installing MATLAB to a "typical" location such as /usr/local/MATLAB/R2016a.
I installed homebrew with brew install wget and when I opened my .bash_profile it was some file I had never seen before full of homebrew's things. My aliases are still working, but I was wondering where I could find them since they're not in the txt file anymore.
I am not familiar with OSX, but I guess your old bash settings could have been backed up somewhere, because your aliases are still working. Try searching for files/directories named "bash*".
you should try using a file recovery program. it is possible the alias is referring to the location on the HDD and that the file still exists, even if the file with that name isn't accessible anymore.
a file recovery program may be a good option.
I recently found out that one of our servers has lost (probably someone deleted it) the /etc/fstab file, it's a Fedora Core 6.
Is there anything we can do to rebuild the fstab without a copy?
If system is still running you can get a copy of fstab from file /proc/mounts.
I've just been setting up a Ubuntu workstation and wanted to add some settings to eclipse.ini. When I searched for the file I found:
/etc/eclipse.ini
/usr/lib/eclipse.ini
My questions are:
Does Eclipse actually use both files?
If so, in what order does it read them?
How does it merge them?
Both of the files I found are system wide, is there a location in my home directory I could put one that would effect only my instances?
Here's how to determine which eclipse.ini file you should use (joomla.org):
If you downloaded Eclipse IDE manually from internet the "eclipse.ini" file is just inside the unpacked folder
If you installed Eclipse via terminal or software center the location of the file is "/etc/eclipse.ini"
In some Linux versions the file can be found at "/usr/share/eclipse/eclipse.ini". Do not use this file if you found a config file at "/etc/eclipse.ini".
To be sure where your Eclipse folder is, check $ECLIPSE_HOME, and if not specified (these directions at least work for Juno):
Open Eclipse as you normally do.
Click Help -> About Eclipse SDK
Click Installation Details
Go to the Configuration tab
Find "eclipse.home.location=file:PATH". PATH is where eclipse is installed.
sources:
http://docs.joomla.org/Configuring_Eclipse_IDE_for_PHP_development/Linux:
There is only one file.
lrwxrwxrwx 1 root root 16 Aug 8 2012 /usr/lib/eclipse/eclipse.ini -> /etc/eclipse.ini
You probably have already found this out, chances are when you installed Eclipse the installation created (or you did manually) a file /usr/bin/eclipse which if you check it probably looks like the following:
#!/bin/sh
export ECLIPSE_HOME="/opt/eclipse"
$ECLIPSE_HOME/eclipse $*
especially if you followed instructions similar to the ones like these on If-not-true-then-false
On the other hand if you have installed from a package, I suspect you will find that eclipse ends up in /usr/bin, most likely a symbolic link to /usr/lib/eclipse/eclipse (or at least I found it on my Fedora system after using yum to install eclipse).
I have Ubuntu 18 and eclipse installation is squashed in a file
/var/lib/snapd/snaps/eclipse_40.snap
which is mount on /snap/eclipse/40 as read only. Just run
mount | grep eclipse*.snap
This eclipse.ini file is really read only, that means, you cannot modify it, even with sudo. However, I also have a eclipse.ini.ignored file in HOME/.eclipse/some number/configuration. This is being by default ignored, but you can change the "launcher.ini" in the eclipse launcher command.
According to https://wiki.eclipse.org/Eclipse.ini
Eclipse startup is controlled by the options in
$ECLIPSE_HOME/eclipse.ini. If $ECLIPSE_HOME is not defined, the
default eclipse.ini in your Eclipse installation directory (or in the
case of Mac, the Eclipse.app/Contents/MacOS directory) is used.
The certain way to make sure is to run strace on eclipse. In the output you'll see where is eclipse actually trying to pull the file from.