Ubuntu 20.04源码编译SRS并配置systemd开机自启动全攻略-北京尧图网络

几个月前我接到一个项目要在 Ubuntu 20.04 上搭一套内部直播系统做技术分享和活动转播用。当时第一个想到的就是 SRS——这个国产开源流媒体服务器我关注了很久社区活跃、文档全、功能也不含糊。不过真正上手时才发现安装倒是顺利麻烦的是“开机自启动”这个看起来不起眼的需求反而折腾了最多时间。网上资料不少但版本混乱、路径杂很多都是复制粘贴照着做很容易翻车。所以这次我打算把我实测过的完整流程整理出来源码编译安装 SRS、基础推拉流验证、用 systemd 做开机自启动优化以及中间踩过的坑。整个方案我在 Ubuntu 20.04 Server 版上跑通了其他 20.04 变体桌面版、虚拟机等理论上完全通用。1. 安装前的环境准备与版本选择思路1.1 SRS 是什么为什么不是 Nginx-RTMP 或其他方案在进入安装步骤前先花点时间搞清楚一个核心问题为什么选 SRS而不是老朋友 Nginx-RTMP、国产的 FreeSWITCH 又或者直接上云厂商的直播服务。SRSSimple Realtime Server是一个开源的实时流媒体服务器。它最核心的价值在于协议支持非常全面RTMP、HLS、WebRTC、HTTP-FLV、SRT、GB28181 等主流协议都有原生支持而且可以在服务端做转封装、转码、集群、录制、回调鉴权。对一个想折腾自建直播、不想被云厂商绑定的人来说SRS 几乎是一站式方案。Nginx-RTMP 我也用过它的路径很清晰配置简单但功能面和生态维护明显弱于 SRS。Nginx-RTMP 模块停止活跃好几年了WebRTC 支持基本没有HLS 虽然能用但切片策略、延迟控制都比较粗糙。SRS 则一直在迭代尤其 4.0 版本之后把 WebRTC 能力做得相当完整5.0 版本又强化了 SR T、GB28181 这些行业协议。当然如果你只是想在本地快速搞一个几分钟的 RTMP 转发Nginx-RTMP 依然可以胜任。但只要涉及多协议分发、权限控制、监控回调、长时间稳定运行这几个维度SRS 的优势就非常明显了。这也是我在评估后最终转向 SRS 的根本原因。1.2 安装前必须检查的系统状态和依赖工具Ubuntu 20.04 是 2020 年发布的 LTS 版本系统自带的内核和软件源生态相对成熟。SRS 官方对 Ubuntu 的适配主要是 18.04 和 20.04所以在 20.04 上安装基本不会遇到官方支持层面的问题。但有几个初始化工作一定要做。第一个工作更新系统软件源并安装基础依赖。sudo apt update sudo apt upgrade -y第二步是确认编译工具链是否齐全。SRS 源码编译依赖 gcc、g、make、git 等基础工具。这些在 Ubuntu 上可以通过 build-essential 一键打包安装。sudo apt install -y build-essential git pkg-config这里注意pkg-config 很多人会漏掉但它关系到一些可选的依赖库能否被正确识别。即便 SRS 默认编译配置不强制要求 pkg-config后续如果你加装模块或者做二次开发缺了它会有各种奇怪的报错所以提前装上比较省心。第三个工作是检查系统时间和时区。流媒体服务对时间敏感RTMP 的 timestamp、HLS 切片的命名、鉴权回调的签名校验都依赖系统时间。我习惯在一开始就确认时间同步正常。sudo timedatectl set-ntp true timedatectl确认NTP service: active就行。如果系统时间偏差太大HTTP 回调里做签名校验时会频繁失败这个坑我踩过后面在常见问题里再细说。1.3 版本选择SRS 4.0 还是 5.0现在 SRS 有两个主要版本在并行更新4.0develop 分支稳定迭代版和 5.0后起之秀。对于大多数场景我推荐直接用最新 stable release 的 4.0 版本也就是4.0.x。理由很简单社区验证最多、生产案例最多、文档最全。5.0 版本引入了更激进的重构和一些新特性比如更完善的多任务处理、更强的 API 能力但它相对较新生产环境中踩出来的坑肯定不如 4.0 多。我在自己项目里用的是 4.0 版本整个部署过程中遇到的问题基本都能在官方 issue 和文档里找到答案。如果你对 5.0 的某些新特性有硬需求比如更高级的 SR T 配置那可以尝试。但作为起步阶段的安装和自启动配置我会用 4.0 的稳定版本讲解这样哪怕你是第一天接触 SRS也不至于被版本差异绕晕。2. 源码编译安装 SRS 的完整流程2.1 下载源码选对代码仓库和分支版本SRS 的官方源码托管在 GitHub 上。在写这篇博文时我用的版本是 4.0 的最新 release。下载源码时推荐直接用 git clone 而不是下载 ZIP 压缩包。因为后续你可能需要更新版本或者切换分支git 管理会方便很多。cd /opt sudo git clone https://github.com/ossrs/srs.git cd srs sudo git checkout 4.0release为什么放在 /opt 下这是我自己多年的习惯。/opt在 Linux 目录规范里是存放第三方软件的标准位置。你可以用/usr/local或者~/srs都行。但如果是生产服务器我强烈建议不要放在/root或/home下避免权限混乱和误删风险。2.2 编译参数说明configure 配置与 make 加速编译进入源码目录后SRS 提供了自动配置脚本configure。默认配置会编译出支持 RTMP 和 HTTP-FLV 等基础协议的版本。对于首次安装我建议直接使用--full参数把大部分常用功能都编进去。./configure --full make -j4-j4的参数表示用 4 个核心并行编译。如果你的服务器 CPU 核心多可以适当调大比如-j8。但注意不要贪心如果 CPU 核心不多或者内存有限过高的并行度会让编译过程变得极慢甚至卡死。在编译过程中SRS 会先构建一些第三方库比如 OpenSSL、FFmpeg 等依赖项。这部分比较耗时尤其是 FFmpeg 的编译即使 4 核并行也可能要等十几分钟。耐心等待就行看到最后出现make ok字样就是编译成功。2.3 安装与目录结构解析SRS 各关键文件放在哪里SRS 的“安装”和其他软件的make install有点不同。执行完make后SRS 的可执行文件和资源就会生成在源码目录下的objs文件夹里没有传统意义上的全局安装步骤。整个 SRS 目录中最核心的是这几个/opt/srs/objs/srs主服务可执行文件/opt/srs/conf/srs.conf默认配置文件/opt/srs/objs/logs/服务运行日志目录/opt/srs/objs/nginx/html/内置 HTTP 服务比如 HLS 文件分发的静态文件根目录这种“免安装”设计的好处是版本隔离做的干净但如果没搞清楚结构很容易在配置 systemd 服务时写错路径。所以我在配置自启动服务前做了一个非常关键的操作把 SRS 源码目录放到一个固定的、稳定的路径下。我选择的是/opt/srs这样后续配置 systemd 时不会因为路径混乱而出错。2.4 启动前必须熟悉的 SRS 配置参数SRS 的配置文件是conf/srs.conf默认监听 1935 端口做 RTMP。初次使用我建议先跑一下默认配置确认服务能正常启动再做个性化修改。最少得看明白这几个配置项listenRTMP 监听端口默认 1935http_apiSRS 提供的 HTTP API 服务端口默认 1985用于管理和监控http_server内置 HTTP 文件服务器端口默认 8080用于 HLS 分发vhost __defaultVhost__虚拟主机配置块绝大部分应用场景下用默认 vhost 就行。如果你有多个不同业务域名的分流需求再考虑新增 vhost在官方默认配置中已经开启了一个简单的直播应用支持 RTMP 推流和播放。我们不需要修改任何配置就能做第一次启动验证。2.5 第一次启动前台运行与停止方法在写 systemd 服务之前先手动前台启动一次 SRS确认基本功能正常。这样万一后面 systemd 配置有问题至少能排除是不是 SRS 本身的问题。cd /opt/srs ./objs/srs -c conf/srs.conf启动后终端会出现类似这样的日志config: main.conf start server: listen1935, api1985, http8080看到这样的输出说明服务已经起来了。这时先不要急着做推流验证按 CtrlC 停掉它我们继续下一步用程序化方式管理服务。为什么一定要先手动跑一次我遇到过很多人上来就直接配置 systemd结果服务起不来排查半天发现根本不是 systemd 的锅而是配置文件里路径写错了或者端口被占用了。先手动启动一次就把变量控制住了如果手动能起来systemd 的问题就只在 unit 文件本身如果手动都起不来更得先把 SRS 本身的问题解决掉。3. 验证流媒体服务推流拉流实测3.1 用 FFmpeg 做本地推流测试服务手动启动后下一步就是验证它真正能干活。最直接的方式就是推流拉流。FFmpeg 是我们最常用的推流工具安装命令很简单sudo apt install -y ffmpeg安装好 FFmpeg 后我一般建议先生成一个测试视频源。如果你的服务器有摄像头或者现成视频文件直接用文件测试就行。我开发测试时经常用一个方法用 FFmpeg 生成一段合成测试视频比如用 testsrc 信号源。ffmpeg -re -f lavfi -i testsrcsize1280x720:rate30 -f lavfi -i sinefrequency1000:sample_rate44100 -vcodec libx264 -preset veryfast -tune zerolatency -acodec aac -f flv rtmp://127.0.0.1:1935/live/test这段命令的意思是生成一个 1280x720、30fps 的测试画面配上 1000Hz 的测试音频编码成 H.264 AAC封装成 FLV推流到本机的 RTMP 地址rtmp://127.0.0.1/live/test。推流时注意-re参数它会让 FFmpeg 以真实时间速度读取输入避免瞬间推完整个测试文件。没有这个参数测试视频可能会在几秒内全部推完无法测试实时流。3.2 拉流验证FFplay、VLC、HTTP-FLV 三种方式推流成功后拉流验证也有几种方式。最简单的就是 ffplayffplay rtmp://127.0.0.1:1935/live/test看到画面和声音输出说明 RTMP 推拉流链路是通的。如果你的服务器是无桌面环境宿主服务器常见情况就要用第二种方式验证HTTP-FLV 拉流。在浏览器或者 VLC 里打开http://127.0.0.1:8080/live/test.flvSRS 默认配置已经开启了 HTTP-FLV 支持端口就是配置文件里http_server的 8080。这种方式很适合做网页端直播播放因为 HTTP-FLV 穿透性好、兼容性也强。第三个是 HLSSRS支持自动将 RTMP 流转封装成 HLS 分片。播放地址是http://127.0.0.1:8080/live/test.m3u8不过 HLS 对实时性有影响有几十秒的延迟我很少用它做实时直播的首选。3.3 检查日志确认服务正常验证完成后顺便看一下 SRS 日志确认有没有异常信息。SRS 日志默认会输出到终端前台模式和日志文件后台模式。查看日志tail -f /opt/srs/objs/srs.log正常情况下可以看到推流成功和播放访问的记录。如果发现 ERROR 级别的日志把对应的上下文截下来后面排查问题时会有大用。4. 开机自启动优化从 rc.local 到 systemd4.1 为什么不用 rc.local 而选择 systemd在 Ubuntu 20.04 上传统的 rc.local 启动方式虽然还能用但已经不再是官方推荐。Ubuntu 20.04 默认使用 systemd 作为 init 系统而且 rc-local.service 在默认情况下是关闭的。网上很多教程会让你写/etc/rc.local然后加一行启动命令。这种方式看起来简单但有两个问题一是不够健壮如果 SRS 崩溃了rc.local 只管启动一次不会自动拉起服务二是启动顺序不受控rc.local 里的命令在网络服务就绪前就可能执行导致 SRS 启动失败。systemd 的 service unit 是更现代的方案。它能管理服务的启动顺序、自动重启、日志记录、依赖关系一条systemctl status就能看到服务当前状态。这也是我推荐你在生产环境用 systemd 管理 SRS 的核心原因。4.2 编写 SRS 的 systemd service 配置文件在 Ubuntu 20.04 中systemd 服务的配置文件存放在/etc/systemd/system/目录下。我习惯给每个自定义服务取一个清晰的名字这里叫srs.service。创建配置文件sudo vim /etc/systemd/system/srs.service内容如下这是经过多次调整后的最终版每一步参数你都可以在注释和图例中找到解释[Unit] DescriptionSRS (Simple Realtime Server) Streaming Media Service Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple WorkingDirectory/opt/srs ExecStart/opt/srs/objs/srs -c /opt/srs/conf/srs.conf ExecStop/opt/srs/objs/srs stop Restartalways RestartSec5 LimitNOFILE65536 StandardOutputappend:/opt/srs/objs/srs_systemd.log StandardErrorappend:/opt/srs/objs/srs_systemd_error.log [Install] WantedBymulti-user.target这里每个参数都值得展开讲Afternetwork-online.targetWantsnetwork-online.target这个组合是保证网络就绪后再启动 SRS。SRS 启动时需要绑定端口如果网络栈没起来bind 会失败。虽然 SRS 可以作为 HTTP 服务用但作为流媒体服务器网络就绪是硬依赖。这一步能避免开机时因网络未就绪导致的启动失败。Typesimple表示 SRS 是前台运行模式。SRS 不像 Nginx 那样有 master-worker 模式默认就是前台运行。所以用 simple 类型没错。千万别用Typeforking因为 SRS 不会像传统 daemon 那样 fork 到后台如果用了 forkingsystemd 会一直等待进程 fork最终超时报错。ExecStart必须写绝对路径。这也是个容易踩坑的地方。systemd 执行命令时的 PATH 环境变量和 root 的不一样如果你只写srs -c conf/srs.conf很可能会出现 “srs: command not found” 之类的错误。绝对路径最保险。ExecStop/opt/srs/objs/srs stop这里要从 SRS 的进程管理机制说起。SRS 可执行文件本身可以通过传入stop参数来来停止正在运行的服务实现内部进程间的信号通信。这样写的好处是优雅停止SRS 会先停止接收新连接、处理完进行中的任务再退出。Restartalways是自启动优化里的重头戏。它让 systemd 在 SRS 进程意外退出时自动拉起服务。比如推流量过大导致进程 OOM、或者代码异常崩溃systemd 会在 5 秒后重新启动 SRS保证服务可用性。RestartSec5表示 5 秒后重试。这个值我调过几次太短了会让系统在故障时反复重启进程日志刷屏甚至影响其他服务太长了又会让服务不可用时间过长。5 秒在生产环境中是比较折中的选择。LimitNOFILE65536是一个容易被忽视的优化项。流媒体服务器的连接数受文件描述符数量限制。一个 RTMP 连接和一个 HTTP 请求都会占用一个 socket 文件描述符。Linux 默认通常只有 1024对生产流媒体服务来说远远不够。调高到 65536 可以在高并发时减少 “Too many open files” 的报错。StandardOutput和StandardError指定了日志输出位置。SRS 的日志本身会写到自己的日志文件但 systemd 启动阶段的输出比如配置文件解析报错会走 stdout/stderr。如果不指定这些信息会被 systemd 丢进 journal虽然也能查但还是落盘到指定位置更方便统一查看。4.3 重新加载 systemd 并启用服务开机自启配置文件写好后需要让 systemd 重新加载配置文件然后启动并启用服务。sudo systemctl daemon-reload先执行daemon-reload是必须的它能重新读取所有 unit 文件。如果你改了 service 配置却没有执行这行命令systemd 会继续使用旧配置排查问题时会一脸懵。接下来启动服务并设置开机自启sudo systemctl start srs sudo systemctl enable srssystemctl start是立刻启动服务systemctl enable是设置开机自启动。两条命令分开执行的好处是方便排查问题如果 start 之后服务没起来说明 SERVICE 文件配置有问题可以先解决再 enable。4.4 用 systemctl 命令验证自启动状态启动完成之后一定检查一下状态不要想当然认为 start 了就是活着的。sudo systemctl status srs看到active (running)字样说明服务正在运行。还要重点看Loaded段确认 enabled 的状态Loaded: loaded (/etc/systemd/system/srs.service; enabled; vendor preset: enabled)看到enabled就说明开机自启动已经生效了。这时你可以reboot试一下。重启后不要急着做任何操作等系统完全启动后直接检查 SRS 状态。sudo systemctl status srs curl http://127.0.0.1:1985/api/v1/versions第二条命令是访问 SRS 的 HTTP API如果返回了版本信息 JSON说明服务在开机后成功启动了网络也正常。这里强烈建议不要省掉这最后一步实际测试一次重启才能真正确认自启动配置无误。4.5 日志轮转配置别让日志把磁盘撑满当 SRS 作为长期服务运行时日志文件会持续增长。SRS 默认日志级别是trace这个级别下日志非常详细生产环境中一天能产生几百兆甚至更多日志。所以日志轮转是个必须解决的问题。systemd 自带logrotate机制我们可以为 SRS 创建一个 logrotate 配置sudo vim /etc/logrotate.d/srs内容如下/opt/srs/objs/srs.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }这段配置的意思是每天轮转一次日志保留 7 天对旧日志做 gzip 压缩。copytruncate很关键因为它是在不停止 SRS 进程的情况下复制日志文件内容并清空原文件这对长期运行的流媒体服务器来说是最安全的方式。很多人自建流媒体服务时容易忽略日志管理等到某天磁盘被塞满才发现问题。日志轮转配置好之后SRS 的日志管理可以做到基本无需人工干预。5. 常见问题与排查技巧实录5.1 编译报错、端口占用、权限问题速查表我把我在配置过程中遇到过的以及身边同事踩过的坑整理成了表格方便你对照排查。问题现象可能原因排查路径解决方案编译时报gcc: command not found未安装 build-essential执行gcc --versionsudo apt install -y build-essentiallisten1935报 address already in use端口被占用netstat -tlnp | grep 1935杀掉占用进程或修改 SRS 端口systemctl start srs后服务秒退Service 文件路径错误journalctl -u srs.service -n 50检查 ExecStart 中的绝对路径拉流 403 Forbidden推流鉴权配置问题检查 SRS 配置中的 auth 参数关闭鉴权或确认 token 正确推流和拉流都好但 HTTP-FLV 播放失败HTTP server 端口被防火墙屏蔽sudo ufw status开放 8080 端口sudo ufw allow 8080/tcp开机后 SRS 没有自动启动未执行 systemctl enablesystemctl is-enabled srssudo systemctl enable srsRTMP 推流成功但 HLS 没有生成HLS 配置未开启检查配置中hls参数在 vhost 中添加hls { enabled on; }5.2 启动失败的逻辑排查法journalctl 与手动启动结合如果 systemd 服务启动失败我有一套固定的排查路径。第一步是看系统日志sudo journalctl -u srs.service -n 50这里会显示 systemd 启动 SRS 时的日志输出。常见错误基本都能从这里读出来比如配置文件路径错误、端口占用、权限不足等。第二步是尝试手动启动cd /opt/srs ./objs/srs -c conf/srs.conf如果手动启动正常说明 SRS 本身没问题问题大概率出在 systemd service 文件的配置上重新核对路径和参数。如果手动启动也报错那就回到 SRS 自身的配置问题上。第三步检查监听端口ss -tlnp | grep srs确认 SRS 是否真的在监听 1935、1985、8080 等端口。这个方法适用于绝大多数启动类问题。核心思路是先区分问题边界是 systemd 的问题、还是 SRS 本身的问题、还是网络环境的问题。5.3 系统时间偏差导致的定时任务与推流鉴权异常这个坑比较隐蔽我当时排查了很久。现象是每次服务器重启后SRS 服务能起来但推流鉴权不稳定有时候能推流成功有时候返回 401而且和重启的时间有关系。查到最后发现是系统时间漂移了导致 SRS 做 HTTP 回调鉴权时时间戳校验不通过。流媒体服务里时间就是钱这真不是玩笑话。解决方法是确保 NTP 时间同步服务正常启用sudo timedatectl set-ntp true timedatectl status后续我每次配置完流媒体服务器都会第一时间确认时间同步。这也是运维里最基础但最容易被忽视的检查点。5.4 高并发连接时的 “Too many open files” 处理排查完启动类问题再分享一个高并发场景才会遇到的坑。当你的直播流数量多同时在线观看人数暴增时SRS 可能出现Too many open files的错误日志里会频繁刷这个错误。这时候除了我们前面在 systemd 配置里设置的LimitNOFILE65536还要确认系统级的文件描述符上限。查看当前系统限制ulimit -n如果发现是 1024 或者很小需要在/etc/security/limits.conf里做系统级调整* soft nofile 65535 * hard nofile 65535 root soft nofile 65535 root hard nofile 65535同时还要确认内核参数 fs.file-max 是否够大sysctl fs.file-max如果这个值也不大可以临时调大sudo sysctl -w fs.file-max2097152不过这个值通常已经够用真正卡住连接数的往往是进程级别的限制也就是 ulimit 和 systemd 的 LimitNOFILE。5.5 防火墙与安全组配置要点最后提醒一个部署中很常见的坑防火墙。Ubuntu 20.04 默认可能没有开启 ufw但在云服务器上安全组/防火墙默认策略通常是“只放行特定端口”。SRS 部署后需要放行的端口至少有几个1935RTMP 推流/拉流1985HTTP API 如果需要外部访问管理接口8080HTTP-FLV、HLS 播放如果你用的 ufw可以这样放行sudo ufw allow 1935/tcp sudo ufw allow 1985/tcp sudo ufw allow 8080/tcp如果你用的云服务商安全组策略直接在控制台里放行以上端口即可。这个步骤看似基础但很多人部署完推流后拉流失败最后发现就是防火墙挡了端口。6. 系统安全加固与多实例扩展的进阶思路6.1 用非 root 用户运行 SRS 的优化方案默认配置下SRS 以 root 用户运行。这在有公网暴露风险的生产环境里不太稳妥。如果 SRS 被攻击者利用漏洞提权root 权限意味着整台服务器沦陷。作为长期运维方案我建议创建一个专用的系统用户来跑 SRS。创建用户和设置权限sudo useradd -r -s /usr/sbin/nologin srs sudo chown -R srs:srs /opt/srs然后修改 service 文件在[Service]部分添加Usersrs Groupsrs注意一个细节配置文件里 SRS 的日志路径、HTTP 文件目录必须有 srs 用户的写权限。如果 HLS 输出目录没有写权限SRS 会在运行时频繁报错。根据我自己的经验/opt/srs/objs目录整体授权给 srs 用户比较省事。改完 service 文件后记得sudo systemctl daemon-reload sudo systemctl restart srs6.2 多实例部署一个 SRS 服务同时服务多个业务有些场景下你可能需要一套机器上跑多个 SRS 实例比如一个给公司内部直播用一个给客户做测试用。这时可以通过多份配置文件和多个 service unit 来实现。第一步是复制一份配置sudo cp /opt/srs/conf/srs.conf /opt/srs/conf/srs2.conf修改 srs2.conf 中的监听端口避免和第一个实例冲突。比如把listen改成 1936http_api改成 1986http_server改成 8081。第二步是复制一份 service 文件sudo cp /etc/systemd/system/srs.service /etc/systemd/system/srs2.service修改 srs2.service 里的Description、ExecStart和StandardOutputExecStart/opt/srs/objs/srs -c /opt/srs/conf/srs2.conf StandardOutputappend:/opt/srs/objs/srs2_systemd.log StandardErrorappend:/opt/srs/objs/srs2_systemd_error.log最后加载并启动sudo systemctl daemon-reload sudo systemctl start srs2 sudo systemctl enable srs2这种多实例方案在测试环境或隔离业务时非常实用也不用额外增加服务器成本。6.3 SRS 的 API 接口状态监控与自愈脚本的基础SRS 自带了一套完整的 HTTP API当你需要做监控报警时会发现这套 API 特别顺手。核心接口就几个GET /api/v1/versions版本信息GET /api/v1/summaries摘要信息包括 CPU、内存、带宽GET /api/v1/streams当前推流列表DELETE /api/v1/streams/{id}踢掉指定流我写过一个简单的监控脚本每 10 秒拉一次/api/v1/summaries如果连续三次拿不到数据就调用 systemd 的 restart 接口curl -s http://127.0.0.1:1985/api/v1/summaries /dev/null || systemctl restart srs这在边缘节点上很管用。你可以根据自己的需求扩展比如当推流数达到上限时自动禁用新的推流。7. 我的几个实操习惯与经验总结在 Ubuntu 20.04 上从源码安装 SRS 并配置好开机自启动和优化整个过程走下来有几个习惯是我现在每次部署都会坚持的。第一个习惯是日志先行。SRS 部署完先把日志目录、日志轮转、日志级别定好。不要等服务跑了一段时间后才发现日志文件把磁盘塞满了。我的习惯是生产环境用warn或error级别开发和测试用trace级别。SRS 在高并发场景下如果开 trace 级别日志量非常惊人。第二个习惯是定期更新 SRS 版本。SRS 本身迭代快很多核心 bug 修复和功能增强都是在新版本中提供的。每隔几个月我都会去 GitHub 上看一眼 release 记录有重要的安全更新就做一次升级。升级的流程也很简单备份配置文件、git pull、重新编译、重启服务。得益于配置文件与源码分离升级时配置文件基本不用动。第三个习惯是验证权限最小化。每次配置完 SRS我都会检查一次运行用户是不是 root、目录权限是不是过宽、API 是不是暴露在公网。在大多数生产场景中SRS 的 HTTP API 不需要映射到公网。如果确实需要远程管理建议加一层访问控制。第四个习惯比较特别我会在 systemd service 里额外加一个ExecStartPre来做端口预检。ExecStartPre/bin/sh -c ss -tlnp | grep -q :1935 exit 1 || exit 0什么意思呢在每次启动 SRS 之前先检查 1935 端口是否已经被占用。如果被占用就直接退出启动流程这样能避免 SRS 启动失败后反复重启同时也便于快速发现端口冲突问题。这套部署方案我在多台 Ubuntu 20.04 机器上验证过有 2 核 4G 的小内存机器也有 16 核 32G 的高配机器SRS 运行都很稳定。如果你也在折腾流媒体服务按照上面的步骤操作从源码编译到开机自启动一整套流程应该能在半小时内搞定。

Ubuntu 20.04源码编译SRS并配置systemd开机自启动全攻略

相关推荐

BoxMOT多目标跟踪器如何选：11种算法对比与最小验证

防止会话超时数据丢失：session-timeout-recovery 可访问性规则实战指南

CANN ops-transformer 中的 BlockAttentionResidualsGrad：融合 Softmax 与 RMSNorm 反向的注意力残差梯度算子解析

更多资讯

enzyme ShallowWrapper.debug() 方法完全指南：用 HTML 化字符串快速定位组件渲染问题

Skynet框架设计原理与高并发系统实践

WeKnora 完整部署指南：Docker Compose 四步跑通私有 RAG 知识库

ExoPlayer Cast 投屏 Demo 实战指南：用 CastPlayer 与 ExoPlayer 实现投屏与本地播放无缝切换

OpenResearch工作流搭建指南：打造可追踪、可复现的开放研究链路

Learn Go with Tests 章节模板解读：把 TDD 循环固化为每个章节的标准骨架

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？