服务器交给其他人使用了几天之后,返到我手里进行检查,发现许多动态链接库不见了,包括ntfs的协议也链接不上了,所以一块ntfs的硬盘挂载错误,导致系统一直处于紧急状态,无法正常启动。
使用ldconfig检查,发现大量的.so文件为空,如下:
……
ldconfig: File /lib64/libtk8.5.so is empty, not checked.
ldconfig: File /lib64/libgfortran.so.3.0.0 is empty, not checked.
ldconfig: File /lib64/libamd.so.2 is empty, not checked.
……
ls一下发现确实是内容为空的文件。这种情况下,相应的链接库就得重装。如果逐个重装,步骤如下:
先查询该库文件属于哪个安装包:rpm -qf ....so
然后yum reinstall该安装包就好。
但是我这里丢失的库文件太多太多了,一个个弄得整到天荒地老,所以写了个自动处理脚本如下:

#/bin/bash
LDCONFIG=`ldconfig 2>&1|sort|awk '{print $3}'`

echo "$LDCONFIG" |
while read line
    do
            if [ `ls -l $line | grep -c '^l'` -ne 0 ]
                    then
                            continue
            else
                    PACKAGE=`rpm -qf $line`
                    if [ `echo "$PACKAGE" | wc -l` -eq 1 ]
                            then
                                    echo "prepare reinstall $PACKAGE"
                                    yes | yum reinstall $PACKAGE
                                    [ $? -eq 0 ] && echo "$PACKAGE reinstall success"|| echo "$PACKAGE reinstall failed"
                            else
                                    echo 'i don not know need reinstall which PACKAGE'
                    fi
            fi
done

执行上述脚本,就可以让它自动处理了。搞定之后再运行下ldconfig,就不报错了。重新挂载上硬盘重新开机,也没问题。

近期在多台机器上安装配置ffmpeg,顺便将整体过程记录一下,以供参考。
环境是rocky linux 8,64位。
在32位系统上编译要复杂很多,因为很多工具和库都不再支持32位系统了。
有些人和有些教程,喜欢在源码configure的时候指定输出文件夹什么的,在这里不建议大家指定,否则后期拷贝和链接库文件是很繁琐的。除非你是要交叉编译,将来运行到其它地方。
以下是整体步骤:
----install x264
cd ~
git clone https://code.videolan.org/videolan/x264.git
cd x264/
./configure --enable-static --enable-shared --disable-asm
make && make install && ldconfig && x264 --version
cd ..

----install nasm
cd ~
wget http://www.nasm.us/pub/nasm/releasebuilds/2.15/nasm-2.15.tar.bz2
tar xjvf nasm-2.15.tar.bz2
cd nasm-2.15/
./autogen.sh
./configure
make && make install && ldconfig && x265 --version
cd ..

----install libnuma
dnf makecache --refresh
dnf -y install numactl-libs
ldconfig

----install x265
cd ~
git clone https://bitbucket.org/multicoreware/x265_git.git
cd ./x265_git/build/linux
./make-Makefiles.bash

在弹出的窗口中确保以下选项开启:
enable_shared    on
其余默认即可。
选择完毕后,按c执行,然后按e返回,再按g退出。

make && make install && ldconfig && x265 --version

----install PKG config
yum install pkg-config
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
ldconfig

----install ffmpeg
cd ~
git clone https://git.ffmpeg.org/ffmpeg.git
cd ffmpeg
./configure --enable-shared --enable-gpl --enable-libx264 --enable-libx265 --enable-static --enable-pthreads
make && make install && ldconfig && ffmpeg -codecs | grep h26

使用ffmpeg在一台多网卡的linux主机上接upd广播数据,总是抓不到。但是网络检测能看见过来的udp组播数据包。
按照官方手册进行了许多尝试,没什么帮助。冷静下来仔细想了想,感觉还是这台机器本身网络的问题;先是重新设置了default gateway,无济于事;然后又确认了防火墙等是否关闭;最后发现一个过滤开关正处于启用状态,选择关闭后,ffmpeg立即就监听到udp流了。开关位置如下;
/etc/sysctl.conf
有个net.ipv4.conf.default.rp_filter的值一定要为0,此外,还要新增一个设置,把要接udp流的网卡的rp_filter设置为0,如:net.ipv4.conf.eth2.rp_filter = 0

保存后,再设置/proc/sys/net/ipv4/conf/eth2/rp_filter(要接udp流的网卡)、/proc/sys/net/ipv4/conf/all/rp_filter两个均为0,然后重启电脑就好。命令示例:
echo "0" > /proc/sys/net/ipv4/conf/eth2/rp_filter

此外,ffmpeg的命令也要和平时略有变化,格式为:
ffmpeg -localaddr XXX.XXX.XXX.XXX[要监听的网卡ip] -i "udp://xxx.xxx.xxx.xxxx:xxxx" -f [format] outurl
其中要监听的网卡ip在我这是经常变化的,因为抓的是iptv的数据,ip是dhcp自动获取的,所以就写了个shell命令,直接返回ip地址:
$(ifconfig ethX | grep "inet addr:" | awk '{print $2}' | cut -c 6-)
这行代码是根据我自己主机来的,其他机器需要进行一些修改。

这样就没什么问题了,正常接收udp的组播数据。

近期使用了一些多铁克生产的接收机、编码器设备,看到它都内置了ts over ip发送能力,可以将接受到的节目发出去。其原本的地址是广播地址,清一色的224.0.0.1;我出于自己设计的要求,改成了单播形式的地址192.168.XXX.XXX。这批设备总共有十来台,改好地址接入网络后,发现网络迅速瘫痪;抓包解码发现多铁克的多台机器在发upd包的时候,虽然ip地址是我设置的那个,但是mac却还是一个全1的广播地址,十分奇怪;确定好故障原因后,下线了这几台机器,网络瞬间恢复正常;没有办法,只好又将这几台机器的tsip输出设置为广播地址,然后用端口来进行区分,至此该问题解决。

本次故障得到了carefree2005于20220620发布的博客文章的帮助,较为顺利解决,非常感谢!
https://www.pudn.com/news/62afb880dfc5ee1968829493.html
起初,是使用yum update upgrade自动升级了系统,之前使用了阿里云的源,没有仔细看升级列表的提示,直接就执行了。没想到glibc等一票动态库都被替换为高版本,导致几乎所有命令都不能使用、几乎要全盘重装。
起初表现是smb服务总是无法被访问。一开始是其它主机无法获得该服务的共享文件夹内文件列表,但能看到共享文件夹;后来连文件路径都不能访问了,提示“找不到网络路径”。这时候还没意识到问题的严重性,看到putty窗口还开着,就上去检查了一下(幸亏没关这个窗口,否则就真的完蛋了),发现连最基本的ls等命令都没办法使用了。
之后就是按照提示(/lib64/libpthread.so.0: symbol __libc_dl_error_tsd, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference),寻找可能的问题,就找到了上述博客文章,然后按照他的经验检查了下自己的ldd版本,确实和实际的动态库版本不一致。我机器里是2.17,但lib库和软链接都变成了2.25。
按照作者的解决方法,逐个改掉了软链接;可是一个yum update就又全回来了;即便删了阿里云的repo、清空了缓存,也是无济于事,一个update就回到解放前。
最后想到了一个低级招数,我把所有2.25的so等文件全部用2.17的替换掉了,名字还是2.25,但事实上是2.17。之后再update,就没再出过问题。
以后会怎样,还得用着看看;反正是不会再用第三方repo了。