shared object "libcrypto.so.7" not found

Last night we installed a new UPS unit, which meant shutting down all our servers.

Our FTP server runs on FreeBSD and when it was brought back up we get shared object "libcrypto.so.7" not found message for the Proftpd, NTPD, SSHD, and SENDMAIL all fail to start because of this. So the FTP server is now in a non-working state.

I did a locate libcrypto.so.7 the result was:
/usr/lib32/libcrypto.so.7

I tried to create a sym link to libcrypto.so.7 but when I tried to start the packages it said the file was not correct.

What do I need to do get the correct libcrypto.so.7 back in place and allow all the dependent programs to run again?

Any help would be greatly appreciated.

Curt Winter
 
Last edited by a moderator:
What kind of information do you need? I am new to the FreeBSD as a Certified Microsoft Professional I am a bit out of my zone. Please let me know what I can provide to help the troubleshooting process.

Thank you.

Curt Winter
 
It might help if we knew which version of FreeBSD you are running and which architecture you are running on. You can probably get most of the useful info that would help by running the command
Code:
uname -a
and pasting whatever output appears here on the forum.

My guess as to what happened is perhaps the services were upgraded, but for some reason the underlying dependencies were not updated at the same time. (This mailing list post talks about the possibility: http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035535.html)

You might try backing up your configuration files and doing a re-install of the affected services.

By the way, welcome to the world of FreeBSD.
 
More specifically, from the FreeBSD command prompt, run the following to download the file.
Code:
fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz
Using tar as follows will unpack it.
Code:
tar xzf base.txz
 
Using tar as follows will unpack it.
Code:
tar xzf base.txz
I think the right command would be [DEL]tar xfp base.txz -C / [/DEL].
The -z option, according to tar(1), is only valid with the -c option and is ignored on extract mode.
--- Edit ---
See bellow why it is a bad idea... Sorry for this bad advice. I used this command with lib32.txz and it worked fine. I should not have generalized.
 
I think the right command would be tar xfp base.txz -C /. The -z option, according to tar(1) is only valid with the -c option and is ignored on extract mode.

Please don't do that or instruct anyone else to do that either! What this does is that it overwrites all /etc/* configuration files unconditionally including /etc/master.passwd which means you will lose all of you non-default user accounts and all passwords that are set.
 
I think the right command would be [DEL]tar xfp base.txz -C / [/DEL].
The -z option, according to tar(1), is only valid with the -c option and is ignored on extract mode.
--- Edit ---
See bellow why it is a bad idea... Sorry for this bad advice. I used this command with lib32.txz and it worked fine. I should not have generalized.

The tar(1) command I posted above, tar xzf, does work, I use it all the time and the -z option does not require -c. If the manual page says so, then it is obvously wrong, I've been doing it this way for years.
 
I have just run a short test using two text files as below.
Code:
Script started on Sun Feb 22 16:08:39 2015
# ls
d.txt  r.txt
# tar -czf tmp.tgz *.txt
# rm *.txt
# ls
tmp.tgz
# tar -xzf tmp.tgz
# ls
d.txt  r.txt  tmp.tgz
# rm *.txt
# tar -cxzf tmp.tgz
tar: Can't specify both -x and -c
# tar -xf tmp.tgz
# ls
d.txt  r.txt  tmp.tgz
# exit
I think there is just a misunderstanding.
The -z option, according to tar(1), is only valid with the -c option and is ignored on extract mode.
In my opinion the meaning is that -z is only possible when creating a new archive using -c. Updating compressed archives using the -u or -r option is not possible. The option -z is ignored on extract mode. This matches with the man page about option -z. :beer::)
 
The first thing I would recommend is to check freebsd-update IDS and post the output here. Files shouldn't just go missing on your hard drive for no reason. You can exclude anything that command finds in the /etc/ directory as that's a given that configuration files in that directory would get picked up by freebsd-update IDS as changing from what was installed.

The second thing is to fix it. As said above it's easy enough to grab the base.txz file and replace what went missing. I would stick everything in the /tmp and only replace what's needed.
fetch http://ftp.FreeBSD.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz tar xvzf base.txz -C /tmp
cp /tmp/lib/libcrypto.so.7 /lib/libcrypto.so.7

Since you are a Microsoft Certified person you are likely familiar how things get done there with DLL libraries and how they get split between Windows\system32 and Windows\SysWOW64 on a Windows system. FreeBSD is similar in concept as shared object, .so, libraries are split up in /lib and /lib32 directories. There are actually in several places in the file system hierarchy depending on what they do. See the hier(7) man page for more info on the file system layout.
 
Ok Ran freebsd-update IDS:
Code:
looking up update.freebsd.org mirrors . . . shared object "libcrypto.so.7" not found, required by "host"
none found.
Fetching public key from update.freebsd.org . . . failed.
no mirrors remaining, giving up.

Ok tried the fetch:
Code:
shared object "libcrypto.so.7" not found, required by "fetch"

rebooted into single user and tried again.

freebsd-update IDS
Code:
FreeBSD-update: Directory does not exist or is not writeable: var/db/FreeBSD-update

So I ran a fsck -f -y
Code:
File system is clean
file system was modified

Tried the fetch:
Code:
shared object "libcrypto.so.7" not found, required by "fetch"

How can these files suddenly disappear from turn off to turn on?

Frustrating

Curt
 
Alright, let's fix the missing libcrypto.so.7 first. Same steps for that but use ftp http://ftp.FreeBSD.org/pub/FreeBSD/releases/amd64/10.0-RELEASE/base.txz instead as ftp(1) doesn't need libcrypto.so.7.
 
Ok the ftp worked it downloaded the base.txz, when I tried the tar command:

tar xvzf base.txz -C /tmp
It returned:
Code:
shared object "libcrypto.so.7" not found, required by "tar"
 
YES! The /rescue/tar worked expanded all the files. Then I was able to copy the file, reboot and now the FTP server is up and working again.

Thanks everyone for all the help and hand holding.

Have a great week.

Curt Winter
 
This thread appears to be a train wreck I missed. Symlinking libraries is a bad idea. Overwriting existing libraries by extracting an archived tar file also seems like a bad idea, but there was a bug in freebsd-update(8) lately, and maybe that is related.

Many people try to avoid reboots, but that can be a mistake. The problem with avoiding them is that when they happen after an unexpected power cycle, you won't know whether the software will all still work, as happened here. Whatever method you use to upgrade the operating system, testing with a reboot afterwards is a good idea.
 
I did not upgrade anything, I init 0 to shutdown the box, upgraded the UPS unit and when I turned it back on I had the errors.

Again thanks to the people who provided constructive posts which lead to the resolution of the issue.

Curt
 
Something changed in the operating system. Usually this is due to an upgrade, often with freebsd-update(8).

shutdown(8) is recommended rather than running init(8) directly. It gives services a chance to do a clean stop.

Some people never encounter problems due to library symlinks or overwriting current binaries with old ones. Those that do find them to be mysterious and often very difficult to diagnose.
 
With the immediate problem fixed there still might be a bigger picture issue. The libcrypto.so.7 should not have just gone missing. It may change during upgrades as wblock@ implied and some folks do try to symlink shortcuts together to do what they believe is a "fix". However, library versions change for a reason so if things do happen to work it's still a ticking time bomb before something breaks.

With that said, the steps you did should not have caused a file to go missing. An upgrade while simultaneously pulling the power plug before the file was saved might do it. A disk issue might be a cause but you would likely have more issues than one file. Human error on the part of a prior admin might have done it. It's hard to say. If the system was maintained via binary updates or is a fresh install then freebsd-update IDS is the quickest thing you can do check the integrity of the system against what should be 10.0-RELEASE. I would highly recommend you run that command and if any files outside of /etc show up then be proactive and ask for some help before any more problems are found in the future.
 
Do updates install themselves automatically like in Windows Update?

Should I run the freebsd-update IDS under Multi User or Single User Mode? What is the difference? I know in the past I had an issues that I needed to run fsck to fix, but that needed to be done in single mode.

I inherited the server and supporting it, so I have no idea how it was originally created, I have to reverse engineering everything I do with it. I appreciate the input and tasks I should be doing to ensure proper running into the future.

Curt
 
Back
Top