Just getting started with FreeFileSync. I want to use it to sync between two Linux servers. One server is running a relatively new version of CentOS and FreeFileSync starts and runs with no issues (so far). The other server is running an older version of CentOS and FreeFileSync does not start:
[server2 FreeFileSync]$ uname -a
Linux server2 2.6.32-754.33.1.el6.x86_64 #1 SMP Tue Aug 25 15:29:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[server2 FreeFileSync]$ ./FreeFileSync
/home/elliott/Downloads/FreeFileSync/Bin/FreeFileSync_x86_64: /lib64/libc.so.6:
version `GLIBC_2.17' not found (required by /home/elliott/Downloads/FreeFileSync/Bin/FreeFileSync_x86_64)
/home/elliott/Downloads/FreeFileSync/Bin/FreeFileSync_x86_64: /lib64/libc.so.6:
version `GLIBC_2.14' not found (required by /home/elliott/Downloads/FreeFileSync/Bin/FreeFileSync_x86_64)
Help would be greatly appreciated. (I have made a donation and have the Donation Edition.)
Thank you,
Elliott
FreeFileSync glibc startup error on Linux
- Posts: 2
- Joined: 1 Oct 2020
- Posts: 309
- Joined: 7 Jan 2018
When your glibc is too old, there is nothing that can be done. I believe CentOS 6 only has glibc 2.12 which obviously is not high enough for the various GLIBC versions shown here.
Even if you could package up, or manually compile, glibc 2.17 on there, it could present stability issues from other packages. The GNU C library (glibc) is a major component of the OS that is not easily replaceable outside of the distro's planned upgrade path.
But if you are enterprising enough to compile a newer version of glibc, let me also share that even CentOS 7 even with the SCL (devtoolset-9 which I swear I saw once but cannot seem to find now) for gcc 9 doesn't have the features necessary for compiling FreeFileSync 10.25. The last version I was able to compile on CentOS 7 was 10.24. So if you choose to compile glibc 2.17 or higher, you'll also want to compile gcc 10.
Even if you could package up, or manually compile, glibc 2.17 on there, it could present stability issues from other packages. The GNU C library (glibc) is a major component of the OS that is not easily replaceable outside of the distro's planned upgrade path.
But if you are enterprising enough to compile a newer version of glibc, let me also share that even CentOS 7 even with the SCL (devtoolset-9 which I swear I saw once but cannot seem to find now) for gcc 9 doesn't have the features necessary for compiling FreeFileSync 10.25. The last version I was able to compile on CentOS 7 was 10.24. So if you choose to compile glibc 2.17 or higher, you'll also want to compile gcc 10.
-
- Posts: 2451
- Joined: 22 Aug 2012
I don't know if you could update the outdated lib on the 2nd (older OS) server.
However, for running a FreeFileSync (FFS) between two servers, FFS only needs to run on one of two servers, (or even on a third machine with file-access to both servers).
So, by running FFS on your 1st (newer OS) server, you should already be OK.
However, for running a FreeFileSync (FFS) between two servers, FFS only needs to run on one of two servers, (or even on a third machine with file-access to both servers).
So, by running FFS on your 1st (newer OS) server, you should already be OK.
- Posts: 2
- Joined: 1 Oct 2020
Yes, good point. Thank you. I am running on the newer server just fine.
However, I am trying to run out of crontab and running into the following error: "Error: Unable to initialize GTK+, is DISPLAY set properly?". I have set DISPLAY in the (bin) shell script and even exported it but I still get the error. The script runs just fine on the command line. I do not know how to resolve this. Is a particular value for DISPLAY required?
However, I am trying to run out of crontab and running into the following error: "Error: Unable to initialize GTK+, is DISPLAY set properly?". I have set DISPLAY in the (bin) shell script and even exported it but I still get the error. The script runs just fine on the command line. I do not know how to resolve this. Is a particular value for DISPLAY required?
-
- Posts: 2451
- Joined: 22 Aug 2012
Sorry, can't help you with these Linux related issues.
Perhaps someone else ...
Perhaps someone else ...
- Posts: 309
- Joined: 7 Jan 2018
On CentOS 6 and 7, you're going to be using Xorg. If this is not the case, you are beyond my skill level. So, with Xorg, you have to have a running Xorg session whose DISPLAY value is usually determinable from the invocation parameters. So run a ps -ef | grep Xorg and find the ":0" or similar number. Any form of remote session (Xvnc or Xrdp or others) tends to start at :10 but really any free positive integer can be used. Sometimes a session includes a decimal value but I cannot remember why. That is, "DISPLAY=:0.0" could be a solution.
I am uncertain that a login prompt ("display manager" such as lightdm, gdm, slim, sddm, xdm, etc.) screen has the necessary ACLs to allow your user to run graphical applications. You normally need your own X session.
On servers where you don't expect to log in graphically, you could investigate using rsync. It's not user-friendly like FreeFileSync and is not related to it at all, but it's the traditional method for synchronizing two directories.
But, as a fun experiment, if the constraints are such that the DISPLAY=:0 or DISPLAY=:0.0 values do not work and you need to stick to FreeFileSync, we could investigate having your script run a dummy graphical session using a tool, Xvfb (xorg-x11-server-Xvfb on CentOS). I've used that successfully for other things and I feel confident we could get it going for you, but it's a bit of an extreme measure.
I am uncertain that a login prompt ("display manager" such as lightdm, gdm, slim, sddm, xdm, etc.) screen has the necessary ACLs to allow your user to run graphical applications. You normally need your own X session.
On servers where you don't expect to log in graphically, you could investigate using rsync. It's not user-friendly like FreeFileSync and is not related to it at all, but it's the traditional method for synchronizing two directories.
But, as a fun experiment, if the constraints are such that the DISPLAY=:0 or DISPLAY=:0.0 values do not work and you need to stick to FreeFileSync, we could investigate having your script run a dummy graphical session using a tool, Xvfb (xorg-x11-server-Xvfb on CentOS). I've used that successfully for other things and I feel confident we could get it going for you, but it's a bit of an extreme measure.
