c程序在服务器上运行，本质上就是把源码编译成服务器系统能直接执行的二进制文件，再通过终端命令把它启动起来。这个过程并不神秘，但如果你第一次接触服务器，很容易在编译、上传、运行这三个环节里卡住，下面按实际操作的顺序，把每一步拆开讲清楚。
linux服务器运行c程序的准备工作
在动手之前,先确认服务器端的几项基本信息，这能帮你避免后面一半的坑。
服务器系统是Linux还是Windows
绝大多数云服务器和物理机跑的是Linux发行版,比如CentOS、Ubuntu、Debian，Linux对C程序的支持非常友好，gcc编译器几乎是标配或者能一键安装，如果你的服务器是Windows Server，流程会略有不同你可能需要Visual Studio编译环境，或者用MinGW把程序编译成exe再上传，但行业共识是，C程序部署首选Linux服务器，环境干净，资源占用低，权限管理清晰。
服务器上有没有可用的编译器
运行C程序分两种情况：一是在服务器上直接编译源码，二是本地编译好再上传，如果你打算在服务器上编译，那得确保装了gcc或clang，用命令查一下：
gcc --version
如果提示找不到命令,Ubuntu系用apt install gcc，CentOS系用yum install gcc，如果你选择本地编译、上传二进制，那服务器上只需要有运行库即可，不需要编译器。
程序是命令行工具还是长期服务
你要跑的C程序,是一次性的数据处理工具，还是一个需要常驻后台的web服务？这决定了运行方式，一次性工具直接前台执行，输出结果就行；长期服务需要用nohup或systemd托管，保证掉线后不挂掉。
c语言程序部署到服务器的完整流程（含命令）
把这一段当作标准操作模板,无论你的程序多简单或多复杂，步骤骨架是固定的。
本地编译出可执行文件
在你自己电脑上,打开终端，进入源码目录，执行：
gcc -o myapp myapp.c -Wall
-Wall参数会显示所有警告，强烈建议加上，如果你的程序涉及数学库或线程库，记得链接：
gcc -o myapp myapp.c -lm -lpthread
编译成功后,当前目录会多出一个myapp文件，这就是Linux下的可执行文件，用file myapp看一眼，确认它是ELF格式，如果你本地是Mac或Windows，编译出来的文件不能直接在Linux服务器上跑，必须在Linux环境里重新编译，或者用交叉编译工具。
把文件上传到服务器
有几种常见手段,最简单的是用scp命令：
scp ./myapp root@你的服务器IP:/root/
输入密码后文件就传过去了,如果你习惯用图形界面，可以用WinSCP或FileZilla这类SFTP工具，拖拽上传，上传后建议统一放到一个专用目录，比如/opt/myapp/或/usr/local/bin/，方便管理，不推荐散落在root家目录里。
登录服务器并给它执行权限
上传完成后,SSH登录服务器：
ssh root@你的服务器IP
进入存放目录,先加执行权限：
chmod +x myapp
如果不加,直接运行会提示Permission denied，这一步新手很容易漏。
前台运行测试
直接执行：
./myapp
程序开始跑,所有输出打印在屏幕上，如果程序需要传参，就带上参数，比如./myapp -s 8080，测试通过后，Ctrl + C可以终止它，这时候程序已经成功在服务器上运行了，但它是前台进程，关掉SSH窗口程序就会死掉。
让c程序在服务器上后台运行的办法
实际生产环境里,没人会开着SSH窗口盯一个程序，你需要把进程挂到后台，或者交给守护进程管理。
用nohup快速后台运行
nohup命令的作用是忽略挂断信号,即使你退出SSH，程序依然活着，用法：
nohup ./myapp > app.log 2>&1 &
这条命令把标准输出和错误都重定向到app.log文件，最后的&表示后台运行，以后想看日志：
tail -f app.log
想停掉这个程序,先ps -ef | grep myapp找到进程号，再用kill -9 进程号结束。
用systemd托管实现开机自启
如果你的c程序是一个web服务或常驻任务,推荐用systemd管理，创建一个服务文件：
vim /etc/systemd/system/myapp.service
大致如下：
[Unit] Description=My C App Service After=network.target [Service] ExecStart=/opt/myapp/myapp Restart=always User=root [Install] WantedBy=multi-user.target
保存后执行：
systemctl daemon-reload systemctl enable myapp systemctl start myapp
从此程序开机自动拉起,崩溃自动重启，这是目前Linux服务器上最正规的c程序运行方式，比nohup可靠。
配合crontab定时执行
如果程序是定时任务型,比如每天凌晨统计日志，那就用crontab：
crontab -e
添加一行：
0 3 /opt/myapp/myapp
表示每天凌晨3点执行一次,注意crontab环境变量很少，程序里如果需要引用外部配置文件，最好写绝对路径。
c程序在服务器上运行时的常见坑
跑起来很容易,但跑得稳不容易，下面几个问题，是我见过最多的。
找不到动态库或者版本冲突
编译时动态链接了某个.so库，但服务器上没有，运行时报错：
./myapp: error while loading shared libraries: libxxx.so.1
解决办法：要么apt install或yum install对应库，要么在编译时全部用静态链接：
gcc -o myapp myapp.c -static
静态编译出来的文件大一点,但移植性最好，拷到任何同架构Linux上都能跑。
端口被占或权限不足
程序要监听8080端口,但启动失败，先用lsof -i:8080看谁占着，如果端口小于1024，比如80端口，必须用root运行，或者用setcap给程序绑定低端口的权限。
段错误和日志定位
程序崩了,输出Segmentation fault，不知道哪行代码出错，编译的时候加-g参数，然后用gdb调试：
gdb ./myapp core
在gdb里输入bt就能看到调用栈，这个技巧对排查c程序崩溃问题非常实用。
服务器资源监控和性能调优
程序跑起来之后,得看它有没有吃光CPU或内存，用top命令或者ps aux --sort=-%cpu查看进程资源占用，如果你的c程序是网络服务，还要关注文件描述符限制，并发高的时候默认1024不够，需要改ulimit -n。
关于c程序在服务器上运行的几个高频疑问解答
c程序能不能每天自动重跑一遍？
能,用crontab设置固定时间点，或者写一个shell循环加sleep控制间隔，注意程序自己需要处理重复启动的资源冲突，比如端口占用，否则可能起不来。
服务器重启后c程序还会在吗？
前台运行和nohup启动的程序,重启后都会消失，只有写进systemd服务并执行了systemctl enable，重启后才会自动拉起，这是运维上最正规的做法。
本地能编译，上传到服务器就提示无法执行？
大概率是架构不匹配,比如你本地是ARM架构的Mac，服务器是x86的Linux，或者反过来，解决办法是在服务器上重新编译源码，或者用目标架构的编译器做交叉编译，用uname -m查看服务器架构，确认一致再传二进制。
c程序在服务器上运行,核心链路始终是“编译、上传、授权、启动”这四步，后台运行用小技巧可以临时解决，长期稳定还是得靠systemd，第一次跑通之后，你会发现这个流程比想象中简单，而且非常机械，多操作几次，就能形成肌肉记忆了。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/683260.html
