十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Ubuntu20.04编译安装SRS流媒体服务器及systemd自启动配置

Ubuntu20.04编译安装SRS流媒体服务器及systemd自启动配置 1. SRS流媒体服务器是什么为什么我推荐它先说结论SRSSimple Realtime Server是一款开源的流媒体服务器我用它替换掉之前那套nginx-rtmp方案之后整个推拉流链路的稳定性和协议支持度都上了一个台阶。很多朋友一提到流媒体服务器第一反应就是推流加播放觉得用nginx挂个rtmp模块就够了。但等你真的遇到WebRTC低延迟互连、HLS切片异常、多路并发推流拉流这些需求时nginx-rtmp那套老架构会让你改到头大。SRS项目从早期只支持RTMP发展到现在已经内置了HLS、DASH、HTTP-FLV、WebRTC、SRT、GB28181等一系列协议能力。在Ubuntu20.04上编译安装SRS你就可以得到一个既能做直播流转发又能做点播切片还能当作WebRTC网关的综合性流媒体节点。它对服务器配置的要求也不高我实测2核4G的ECS跑个几百路RTMP拉流没什么压力关键是配置文件比nginx那套简单直观多了。这篇文章主要面向两类读者。第一类是运维或后端开发需要在Ubuntu20.04上快速搭一套可用的流媒体服务支撑直播、录播或摄像头接入场景第二类是刚接触流媒体技术的初学者想搞明白SRS怎么编译、怎么配置、怎么让它稳定运行。本文会从环境准备、源码编译、核心配置、自启动服务这几个层面展开最后给出我实际部署中踩过的问题和排查方法。整个流程你照着走一遍半小时左右就能把服务跑起来。2. 安装前的环境准备与版本选型2.1 为什么版本和系统环境决定了后续是否顺利很多人在编译SRS时翻车问题往往不是SRS本身而是卡在了环境层面。Ubuntu20.04默认的软件源里虽然带了gcc和make但版本差异会导致编译选项不兼容尤其当你的系统从老版本升级上来时残留的旧开发库很容易干扰编译过程。我建议拿到一台干净机器后先把系统版本和CPU架构确认清楚再开始装依赖。检查系统版本和架构执行这几条命令lsb_release -a uname -m cat /etc/os-release在Ubuntu20.04 x86_64环境下SRS的编译非常顺畅。但如果你用的是树莓派这类ARM板子部分依赖可能需要手动调整编译时间也会明显变长。2.2 安装编译器与基础依赖SRS的核心代码是C编写的编译时需要完整的构建工具链另外还需要python3来处理一些构建脚本。你在执行下面的命令之前先把软件源更新到最新避免装到旧版本的包sudo apt-get update sudo apt-get install -y git build-essential python3 autoconf automake libtool pkg-config有些精简版的Ubuntu系统默认没有安装unzip和net-tools你也可以顺手一起装掉后面检查端口和服务状态时会用到sudo apt-get install -y unzip net-tools curl wget依赖安装本身不复杂但这里有一个容易忽略的细节如果你打算让SRS启用全功能编译比如加入WebRTC、SRT、GB28181这些扩展还需要在后续的configure阶段指定相关选项那你最好提前把cmake也装上否则SRT模块可能在生成构建文件时报错。sudo apt-get install -y cmake2.3 创建独立的运行用户和目录出于安全考虑我不建议直接用root用户来运行流媒体服务。我的习惯是单独创建一个srs用户然后把SRS安装到/usr/local/srs目录下这样即使SRS被攻击者拿到权限也没法直接控制整个服务器。创建用户和目录的命令如下sudo useradd -r -s /usr/sbin/nologin srs sudo mkdir -p /usr/local/srs sudo chown -R srs:srs /usr/local/srs注意上面的useradd命令中我用-nologin指定了该用户不能登录Shell这样即使SRS进程被入侵攻击者也无法直接通过该用户登录系统。日志目录、配置文件、运行目录全部放在这个srs用户下后面你配置systemd服务时启动用户也直接指向srs权限就非常干净。3. SRS源码编译与安装从拉取代码到跑起来3.1 版本分支怎么选提到SRS版本很多新手会纠结。SRS的分支很多有develop、4.0release、5.0release等。我的建议是如果你只是做常规直播和点播直接拉取5.0release分支的稳定版因为4.0的时代比较久远5.0对HLS和WebRTC的支持更完善api接口也更规范。如果你是为了研究源码那develop分支可以拉但上线部署不建议用develop。cd /usr/local/srs sudo -u srs git clone -b 5.0release https://github.com/ossrs/srs.git由于SRS源码托管在GitHub上国内网络环境下载可能会比较慢你可以配置git代理或者直接从gitee镜像拉取。遇到clone超时多试几次一般也能成功。3.2 编译参数解析与执行进入源码目录后先执行configure脚本这一步决定你要编译哪些功能模块。最简单的做法是直接使用默认配置只编译核心的RTMP、HLS、HTTP-FLV等功能这对于绝大多数场景已经足够cd srs/trunk sudo -u srs ./configure --jobs4 sudo -u srs make -j4--jobs和make的-j参数都表示并行编译的线程数设置为CPU核心数的两倍左右能有效缩短编译时间。编译过程中屏幕上会滚动大量的编译日志看到以objs/srs开头的输出就说明编译完成了。这里顺便解释一下这个目录结构SRS的源码中trunk是主工程目录configure脚本和Makefile都在里面编译产物也会输出到trunk/objs下面。很多新手把srs.conf写到源码根目录下然后启动时找不到配置文件就是没注意这个路径层级。3.3 全功能编译的可选操作如果你需要WebRTC建连或者SRT协议接入那就要用全功能编译sudo -u srs ./configure --full --jobs4 sudo -u srs make -j4加上--full参数后编译时间会增加不少我自己的机器上大约多花了五分钟。需要注意的是全功能编译要求你的gcc版本不能太低Ubuntu20.04自带的gcc9完全没问题。如果你发现编译SRT模块报错先检查cmake是否安装。3.4 安装文件布局说明SRS编译完之后不需要额外执行make install所有运行文件都保留在trunk目录下。这种设计虽然让目录看起来有点乱但也意味着迁移服务时只要把整个srs目录打包拷到新机器上再启动就行不需要走标准的安装流程。最后把trunk目录的所有者改回srs用户sudo chown -R srs:srs /usr/local/srs4. 核心配置解析与流媒体功能验证4.1 SRS配置文件结构和常用指令SRS的默认配置文件是trunk/conf/srs.conf它的语法有点类似nginx的块状结构。我强烈建议你从默认配置出发做增量修改而不要自己从头写一个空配置因为SRS里很多配置项有默认值漏写一个就容易出现预期外的行为。下面是我在Ubuntu20.04生产环境上的一个基础配置模板它同时开启了RTMP和HLS功能listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; } vhost __defaultVhost__ { hls { enabled on; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } }这个配置中listen指定RTMP监听端口默认1935http_api是SRS的HTTP控制API默认1985http_server用于对外提供HLS和FLV的HTTP访问默认8080。vhost类似于nginx的server块__defaultVhost__表示默认虚拟主机所有请求如果没有匹配到其他vhost都会走这个配置。4.2 启动SRS并检查服务状态在启动之前建议先用配置测试命令检查一遍配置语法cd /usr/local/srs/srs/trunk sudo -u srs ./objs/srs -c conf/srs.conf -t如果能正常输出没有错误就可以正式启动了sudo -u srs ./objs/srs -c conf/srs.conf进程启动后用netstat确认监听端口是否正常netstat -tlnp | grep -E 1935|1985|8080看到这三个端口都处于LISTEN状态就说明SRS已经正常工作了。SRS的HTTP接口也可以直接验证浏览器里打开http://你的服务器IP:1985/api/v1/summaries如果返回一段JSON里面包含版本和运行时间就说明API服务也正常。4.3 RTMP推流和拉流验证流媒体服务器装好之后必须实际推流拉流测一遍确认整条链路是通的。我这里用FFmpeg推流在服务器上先安装ffmpeg工具sudo apt-get install -y ffmpeg然后准备一段视频文件test.mp4执行推流命令把本地的视频通过RTMP协议推到SRS上ffmpeg -re -i test.mp4 -c copy -f flv rtmp://127.0.0.1:1935/live/test这里的live是应用名test是流名称这两个字段你可以自己定义。推流时终端会持续刷新输出看到frame和fps数据在增长说明推流正常。接着在另一终端用ffplay拉流ffplay rtmp://127.0.0.1:1935/live/test能弹出画面并流畅播放RTMP链路就算验证通过了。除了RTMP你还可以测试HTTP-FLV拉流方式地址是http://127.0.0.1:8080/live/test.flv以及HLS拉流方式http://127.0.0.1:8080/live/test.m3u8HLS有切片延迟一般等几秒才能播放属正常现象。5. 开机自启动优化systemd服务配置详解5.1 为什么不用rc.local而用systemdUbuntu20.04采用systemd作为init系统。很多老教程会让你在/etc/rc.local里加启动命令但rc.local在systemd环境下默认是禁用状态还需要手动启用而且它根本没有进程守护能力。SRS万一崩了rc.local不会帮你重启你只能等用户报障。所以生产环境必须使用systemd来管理。好处有三点崩溃自动重启、开机自启、日志集中管理。5.2 编写SRS的systemd服务文件在/etc/systemd/system/目录下新建一个srs.service文件sudo vim /etc/systemd/system/srs.service写入以下内容[Unit] DescriptionSRS Streaming Server Afternetwork-online.target Wantsnetwork-online.target [Service] Typeforking Usersrs Groupsrs RuntimeDirectorysrs PIDFile/usr/local/srs/srs/trunk/objs/srs.pid ExecStart/usr/local/srs/srs/trunk/objs/srs -c /usr/local/srs/srs/trunk/conf/srs.conf ExecStop/usr/local/srs/srs/trunk/objs/srs -c /usr/local/srs/srs/trunk/conf/srs.conf -k ExecReload/usr/local/srs/srs/trunk/objs/srs -c /usr/local/srs/srs/trunk/conf/srs.conf -sr Restarton-failure RestartSec5 LimitNOFILE65535 [Install] WantedBymulti-user.target这个服务文件有几个关键点需要解释。首先是Typeforking这意味着SRS启动时会派生出子进程systemd通过PIDFile来识别主进程。这里要求SRS的daemon配置必须是on也就是后台运行模式。如果你在srs.conf里设置了daemon off那就应该把Type改为simple并且ExecStart直接以前台方式运行。其次是User和Group这里我用之前创建的srs用户来运行服务避免用root权限。如果你的证书文件、日志目录权限不对SRS可能无法写入这时候可以用一个简单办法验证手动切换到这个用户执行一次启动命令看是否报权限错误。最后是LimitNOFILE这个配置很关键。流媒体服务器需要维持大量网络连接默认的1024文件描述符限制非常容易耗尽。我把它设成65535基本能满足中小规模并发场景。5.3 重新加载服务并验证开机自启写完后执行sudo systemctl daemon-reload sudo systemctl enable srs sudo systemctl start srs sudo systemctl status srsstatus输出中只要看到loaded和active (running)就说明服务已经正常启动。下次重启Ubuntu20.04之后srs会自动拉起来无需手动操作。再验证一下开机自启是否生效systemctl is-enabled srs输出enabled就说明开机自启已经配置成功。如果你临时跑了多实例测试可以用systemctl stop srs停掉服务再用systemctl start srs重启。5.4 自启动优化日志与崩溃恢复经验SRS默认日志会输出到终端在systemd环境下这会被收集到journal日志里你可以用journalctl统一查看sudo journalctl -u srs -f如果你觉得journal日志不方便管理可以在srs.conf里设置日志文件输出srs_log_tank file; srs_log_file /usr/local/srs/srs/trunk/objs/srs.log;需要注意的是如果以srs用户运行日志目录必须对srs用户可写。我在部署时喜欢保持console输出因为配合systemd的日志排除机制可以在journal里做关键字告警。另外Restarton-failure并不是所有退出都会重启只有当进程异常退出时才会触发重启如果SRS检测到配置错误主动退出systemd也不会一直循环重启。RestartSec5表示崩溃后等待5秒再拉起进程这样避免快速重试导致服务器负载飙高。6. 常见问题与排查技巧实录6.1 编译阶段报错怎么办编译SRS最常见的报错是缺依赖比如提示找不到libopus或libsrt。Ubuntu20.04的软件源里这些库的包名可能和你搜索的不一样我建议直接装上以下开发包基本能覆盖多数编译依赖sudo apt-get install -y libopus-dev libsrt-dev libssl-dev如果你用的是全功能编译还会遇到protobuf和cjson相关错误。遇到类似configure: error: not found不要慌先去查看trunk/obds目录下的编译日志确认具体缺哪个头文件再通过apt-file search定位到对应的pack包。一个比较实用的办法是执行sudo apt-get install -y apt-file sudo apt-file update sudo apt-file search missing_header.h6.2 systemd启动失败无法连上端口如果你配置完systemd服务后status显示active但netstat查不到1935端口大概率是SRS进程启动后又被kill掉了。此时用systemctl status srs查看输出重点看ExecStart路径和PIDFile路径是否对得上。另一个常见原因是pid文件路径和srs.conf里配置的pid输出路径不一致导致systemd识别不到主进程。还有一种情况是srs.conf里继续沿用daemon off配置但systemd使用Typeforking。这时systemd会等待主进程退出SRS又一直在前台运行结果服务一直处于activating状态。解决办法很简单把Type改成simple或者把daemon改为on二选一。6.3 推流不成功或拉流404推流失败最常见的是live这个应用名和流名与播放地址不一致。例如你推流到rtmp://ip:1935/live/test但播放时却使用了rtmp://ip:1935/live/test2那肯定拉不到。除此之外vhost配置错误也会导致404尤其是你修改过vhost名但推流地址没有带上vhost参数。如果推流地址是rtmp://ip:1935/live/test默认会匹配__defaultVhost__虚拟主机。一旦你新建了自定义vhost并把hls配置只写在了自定义vhost下默认vhost就不会切片HLS。这时候播放HLS地址就会得到404。排查时可以先用HTTP API确认流是否存在curl http://127.0.0.1:1985/api/v1/streams/返回的JSON中如果能看到当前推流的流信息说明SRS已经正常接收推流问题就出在播放路径上。另外检查服务器防火墙是否放行了8080和1935端口Ubuntu20.04默认的ufw如果没有允许这些端口外部请求会被拦截你自己在服务器本机测试没问题但外网播放就不行。执行sudo ufw allow 1935/tcp sudo ufw allow 1985/tcp sudo ufw allow 8080/tcp6.4 服务器重启后SRS启动顺序问题有时系统刚开机时网络服务还没完全就绪SRS已经在尝试绑定端口结果绑定失败导致服务退出。为了避免这个问题systemd服务文件里我已经加了Afternetwork-online.target和Wantsnetwork-online.target这行配置会让系统在网络在线之后才启动SRS。如果你发现开机后SRS仍然没起来建议在ExecStart之前加一个等待命令或者在服务里增加服务启动延迟ExecStartPre/bin/sleep 5 ExecStart/usr/local/srs/srs/trunk/objs/srs -c /usr/local/srs/srs/trunk/conf/srs.conf6.5 常见问题速查表问题现象可能原因解决方法编译报错缺头文件缺少libopus、libsrt等开发库安装对应-dev包systemd状态activatingdaemon off与Typeforking冲突将Type改为simple或daemon改为on外部无法播放ufw或云安全组未放行端口放行1935、1985、8080端口HLS花屏或延迟高HLS切片时间配置过大调整hls_fragment和hls_window参数启动后进程自动退出pid路径或日志目录无权限检查srs用户对objs目录的写权限拉流404vhost或流名称不匹配确认推流地址与播放地址保持一致7. 最后分享几个实际部署中的小习惯我每次在Ubuntu20.04上部署SRS都会顺手做两件事。第一是把编译好的整个trunk目录打一个tar包留一个干净版本的备份下次要快速重建或者迁移服务器时直接解压就能用不用再重新编译一遍。第二是把srs.service文件的修改记录和配置变更日志整理到一个文档里SRS升级版本时对比配置文件改动会省很多体力活。还有一个很多人忽略的点SRS版本升级前一定要先读官方release note尤其注意配置文件是否引入了不兼容的字段。我遇到过升级后原有配置里某个参数被废弃导致服务初始化失败。这时候最好的办法不是降级而是根据官方迁移文档把配置项改成新语法。最后再提一句性能调优方向。如果你的并发连接数特别高除了调整服务文件里的LimitNOFILE系统层面的文件描述符上限和网络优化参数也值得关注。比如修改/etc/sysctl.conf中的net.core.somaxconn和net.ipv4.tcp_max_syn_backlog可以提升高并发下的连接接受能力。这些不是必须项但在大流量进来之前做好准备总比线上告警了再半夜改参数要踏实得多。
返回列表