[root@maverick ~]# cat /etc/os-release NAME="IPFire" VERSION="2.27" ID=ipfire VERSION_ID=2 PRETTY_NAME="IPFire 2.27 (x86_64) - core172 Development Build: master/eb9e29f9" ANSI_COLOR="0:31" [root@maverick ~]# ldd $( which lsof ) linux-vdso.so.1 => linux-vdso.so.1 (0x00007ffe40d8e000) libtirpc.so.3 => not found libc.so.6 => /lib/libc.so.6 (0x0000703bd6a53000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000703bd6c3d000)
This was introduced in a93d06297947a68e598b1a8478e79714427da247, specifically: lsof-4.93.1 4.93.0 May 7, 2019 [freebsd] Made FreeBSD 13 adjustment. [darwin] Fix a typo causing a build error. Fix a potential memory leak. [linux] use tirpc for rpc if libc doesn't provide rpc.h. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ However, lsof does not appear to provide an easy was to turn this off, and I don't want to delay the release of Core Update 172 further because of this. As a workaround, users can install libtirpc as an add-on, which restores lsof functionality again.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=9ea8de7c39ee35d6fcabc3bfca4a7754344e6610 To buy us time for resolving this, I just reverted the lsof update to 4.96.4, so we won't ship anything broken on purpose. The symlink in core/172/filelists/ remains in place deliberately, to ensure any systems upgraded to Core Update 172 (testing) will receive an intact lsof binary again.
Sorry, I hadn't realised that this was related to my update of lsof. Done some searching on this. rpc.h used to be provided by glibc but it was deprecated for some time and then in glibc-2.32 it was removed. Changelog entry Remove configure option --enable-obsolete-rpc. Sun RPC is removed from glibc. This includes the rpcgen program, librpcsvc, and the Sun RPC header files. Backward compatibility for old programs is kept only for architectures and ABIs that have been added in or before glibc 2.31. New programs need to use TI-RPC http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary and rpcsvc-proto https://github.com/thkukuk/rpcsvc-proto. Interestingly enough there is still an rpc.h file in the glibc source tarball even in 2.36 but it doesn't get placed in /usr/include/rpc/ The above changelog entry also indicates that future needs should be met by using libtirpc. The build has always worked b ecause the configure file looks for /usr/include/rpc/rpc.h which originally came from glibc. If this is not present then configure looks for /usr/include/tirpc/rpc.h and this is always present as libtirpc is built before lsof and it places the rpc.h file in the directory. I checked my CU171 system by running ldd $( which lsof ) and found that the same message is shown ldd $( which lsof ) linux-vdso.so.1 => linux-vdso.so.1 (0x00007ffd079eb000) libtirpc.so.3 => not found libc.so.6 => /lib/libc.so.6 (0x0000787f8500f000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000787f851f9000) So this problem has been present already in the previous version of lsof (4.95.0) and based on the changelog message that @Peter found it has been present since lsof-4.93.1 which for IPFire means it came on board with lsof-4.95.0 which was updated on 6th July 2022 and came in with Core Update 170. Previous version of lsof was 4.91 which was installed in August 2020. Do we use the rpc aspects of lsof? It would seem like probably not as no one has flagged up a problem with lsof in CU170 or CU171, although maybe it has caused problems that were not identified to be coming from lsof. It looks like if we need the rpc elements of lsof (and it does look like it can't be turned off in lsof, at least not easily) the libtirpc would need to be converted from an addon to a core program. I can supply a patch to do that if it is the correct thing to do but I don't know enough about all this to make that decision.
> Sorry, I hadn't realised that this was related to my update of lsof. No worries. Many thanks for your comment and the thorough analysis. You are right, this is not related to your lsof update, and was already present on Core Update 171. Frankly, I don't like lsof doing something with rpc, since I don't really see why such a tool should do that (unless I misunderstood something); I'll have a look at the situation surrounding libtirpc and will report my findings here. For now, please lean back and relax - it's not your fault. :-)
just found the same: ``` [root@ipfire ~] # lsof lsof: error while loading shared libraries: libtirpc.so.3: cannot open shared object file: No such file or directory [root@ipfire ~] # ``` tested on APU4D4 IPFire 2.27 (x86_64) - Core-Update 172 (no response needed)
The searching I have done on lsof indicates that since glibc deprecated the rpc.h file that the use of libtirpc for lsof has been made a required dependency for both build and execution. All my searching has failed anyway to stop the rpc options being built. I have checked several of the build files looking for any rpc related variables that might be able to be patched without finding anything. The only rpc related stuff is where it checks that either the glibc version or the libtirpc version is present during the build. If it is not present then a build error occurs. This error does not happen in the IPFire build because the libtirpc addon is built before the lsof package is built and so the files are present in the build directory and lsof finds them and continues on the basis of libtirpc being linked. Being able to turn of rpc in lsof might be desired if rpc is not being used, that option is not easily available. Also in the past rpc was available in lsof automatically because it was built and the library was available from the glibc package. Therefore it seems like libtirpc needs to be converted from an addon to a core program as without it the lsof package does not work, and has not been working in IPFire since CU170.
(In reply to Adolf Belka from comment #6) > Therefore it seems like libtirpc needs to be converted from an addon to a > core program as without it the lsof package does not work, and has not been > working in IPFire since CU170. This is the way to go. This library is probably being used by other things, too. Would you like to submit a patch?
(In reply to Michael Tremer from comment #7) > (In reply to Adolf Belka from comment #6) > > Would you like to submit a patch? Will do so.
Patch submitted to dev mailing list and patchwork https://lists.ipfire.org/pipermail/development/2023-January/015319.html https://patchwork.ipfire.org/project/ipfire/patch/20230127143002.3442315-1-adolf.belka@ipfire.org/
[atch has been merged into next https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=024220e4dfc5993d5d64abfced918340f729fe62
Core Update 173 Testing released https://blog.ipfire.org/post/ipfire-2-27-core-update-173-is-available-for-testing
lsof with CU172 comes up with missing libtirpc library message. With CU173 Testing lsof gives its normal listing output.
I still have the same error: ``` [root@ipfireAPU ~] # lsof lsof: error while loading shared libraries: libtirpc.so.3: cannot open shared object file: No such file or directory [root@ipfireAPU ~] # ``` Tested with: APU4D4 IPFire 2.27 (x86_64) - Core-Update 173 Development Build: master/fa2f6cb6 This was an upgrade from CU 172 to CU 173. With pakfire I only have Borg and Borg dependencies installed. No libtirpc add-on. Do I need to remove something?
I caused this... :-( First, I did the upgrade from CU 172 to CU173 (test). Second, I deleted ALL of the add-ons in my pakfire list. (I had way too many in the pakfire list from testing other things over the past few months.) I am almost positive one of those was the add-on `libtirpc`. Third, I tested Borg, and messagebus (dbus). And then I tested `lsof`. I think when I deleted the `lsof` add-on it caused the error to pop-up. Ugh!
https://blog.ipfire.org/post/ipfire-2-27-core-update-173-released