一、背景
由于产品是Java程序，之前都是通过封装的start.sh运行即可。但是出于架构调整，改换为Ansible进行自动化部署，同时改用Systemd service的方式来对程序进行管理。
但不知道为啥原因，使用systemctl启动这个程序，就会无脑报错。 报错信息看起来像是我们使用到nacos，一直停留在无法创建新的线程、堆内存溢出:
晚上申请割接窗口时间进行排查，排查了2天都没排查出个所以然。 更奇怪的是，我们直接使用start.sh的方式能正常启动，但是使用systemctl 启动服务的方式就是死活起不来，这才是最坑的地方。
从报错信息，我们以为是ulimit设置的文件句柄限制太小，查看了一下ulimit -a， 发现限制量是100w， 应该不是这个问题。
也看了下nacos的端口可以正常访问，程序给了40G堆内存。并且是服务启动就报错咯，而不是运行起来才报错。 也没有生成dump文件。jstack分析了下线程运行情况，也正常。 百思不得其解。
最后，我们根据现象大概率判断可能是我们的systemd service哪里出了问题，要不然无法解释为啥同样的程序，通过start.sh启动可以正常，但是通过systemd的方式起不来。
二、排查过程
1、查看service文件，发现参数LimitNOFILE
刚开始我们发现service文件存在这个参数LimitNOFILE=81920, 以为是这个参数导致的。后面尝试把这个参数注释掉，重新启动发现还是一样起不来。
那根本原因还是没找到，只能继续排查。
2、TasksMax参数
后面使用systemctl start service, 直接通过systemcl status service观察服务的运行状态，看下是什么原因挂掉的。 此时发现了一个有趣的现象:
这里有一个limit的限制，还没修复之前是512, Tasks的数量一直在涨，大于>=limit 512以后，整个service也挂了。
很符合我们观察到的启动现象。
查询了一下资料，这个参数的含义:
systemd的TasksMax参数用于限制systemd管理的服务的并发线程数。当服务的线程数达到这个限制时，新线程的创建将会失败，并可能导致服务出现错误或不稳定。TasksMax参数可以在系统级别或进程级别进行设置。系统级别的设置影响所有systemd管理的服务，而进程级别的设置则只影响特定的服务。TasksMax参数的作用和设置方法主要包括以下几点：限制并发线程数：TasksMax参数设定了一个服务可以创建的线程数的上限。这有助于防止因线程过多而导致的资源耗尽和服务崩溃。
系统级别设置：在系统级别，TasksMax参数可以在/etc/systemd/system.conf文件中进行设置。例如，可以将DefaultTasksMax的值修改为5120，以允许服务创建更多的线程。原来是systemd限定了进程的并发线程数量， 超过了则这个service会被systemd干掉。 顺藤摸瓜，我们看下这个默认值limit是不是512? 怎么修改参数值?
systemctl show --property=DefaultTasksMax
还真是512.对应得上了。 那么我们尝试修改下这个service的TaskLimit参数限制，调整到了10000.再尝试启动程序看是否正常，此时发现程序已经正常启动，不会挂了。
三、总结
针对systemd的配置信息，需要我们详细的去了解相关参数，才能写出较少的坑的sevrice文件。
我们可以直接通过systemctl --show | grep 的方式来过滤一些关键词，从而学习这些配置项的含义，要不然遇到这种坑真的难以排查。
