Hi, Mattia!
Yes, you are right. I checked again eatmydata and found that error
message due to chroot use.
On 8/24/18 1:31 AM, Mattia Rizzolo wrote:
Control: tag -1 unreproducible moreinfo
On Wed, Aug 22, 2018 at 03:39:14PM +0300, Vasiliy Shlykov wrote:
script eatmydata provided by the package has a serious bug.
Please, consider that this package has been in that state for nearly 2
years; with so many users somebody else would have noticed such a
serious bug.
The symptom: running command with eatmydata script produces message:
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
Can't reproduce here.
mattia@warren ~ % eatmydata true
mattia@warren ~ %
Obviously, this happens due to using wrong path and name of the library:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+"$LD_LIBRARY_PATH:"}/usr/lib/libeatmydata
LD_PRELOAD=${LD_PRELOAD:+"$LD_PRELOAD "}libeatmydata.so
Dir /usr/lib/libeatmydata doesn't exists and file libeatmydata.so doesn't
exists too.
That's false.
For starters, libeatmydata.so sure does exist, in
/usr/lib/x86_64-linux-gnu/libeatmydata.so shipped by the package
libeatmydata1, which is depended by eatmydata.
Secondly, /usr/lib/libeatmydata used to exist, and is there to support
loading the library from such legacy location (think abount having this
script wrapping around a chroot call, etc). http://bugs.debian.org/765810
Also the manpage contains this information.
And anyway, adding random directories to LD_LIBRARY_PATH wouldn't
automatically trigger such "bug".
So, I think you should check your environment and the program you are
then calling (as something programs mangle LD_LIBRARY_PATH and
LD_PRELOAD themselves).
If you can't figure what's going on, please consider sharing more
details about your situation.
