简介：Synopsys工具license配置学习文档面向需要搭建本地学习测试环境的IC设计初学者与工程师，围绕license文件生成、路径指向与feature缺失排错等常见问题展开，帮助读者理解license管理的基本流程，并明确仅限学习使用。资源包仅含1个docx文档，大小约269KB，以文字说明形式集中整理关键概念与注意事项，便于在单篇文档内检索查阅。目前已有602人学习，说明该主题在工具入门阶段具有较高关注度。文档内容覆盖scl_keygen生成license时的hostid、hostname与port参数设置，snpslmd本地路径修改，fix.bat执行失败后的手动补全思路，以及时间戳调整、特征回填和project_id核对等排错方向；对license文件结构、格式转换与常见报错处理均给出了可参考的线索，适合希望快速建立整体认知、减少配置试错的读者按需查阅。
1. license 服务显示 UP，工具却报 checkout 失败：先分清断在哪一层
晚上十点，lmgrd 起来了，lmstat也老老实实打印License server UP，工具一跑还是弹Unable to checkout license for feature xxx。这种故障比装不上更磨人——报错分散在 lmgrd 启动输出、Synopsys.dat.log和客户端弹窗三个地方，任何一处对不上，前面的功夫都白费。给离线环境配 synopsys license 的人基本都经历过这个循环：改一行、重启、再试、再失败，来回十几轮。下面按「服务起不来 → 服务起来但 checkout 失败 → 跑一段时间偶发失效」的顺序拆，每一步都落到具体文件和具体命令上，适合正在给测试机配 license、被日志绕晕的同学。
2. lmgrd 启动就退：DAEMON 路径、端口占用与日志三处排查
守护进程是最先起、也最先死的那个。命令行敲下去回车，没有输出、没有报错，ps -ef | grep lmgrd一看进程已经没了；或者进程还活着，日志里孤零零一行FATAL。多数人第一反应是「license 生成坏了，重来一遍」，实际上九成问题落在三个地方：DAEMON 指向的可执行文件在目标机上根本不存在、端口被别的服务占着、日志压根没开所以什么都看不到。把这三处排干净，剩下的才轮到讨论 license 内容对不对。
2.1 DAEMON 那一行：路径必须是目标机器上真实存在的绝对路径
生成工具在 Windows 下跑完之后，会把Synopsys.dat拷到 Linux 上用，这时候要改第二行，补一条DAEMON记录，指向本机 scl 安装目录里的snpslmd。翻车点在于：文档里的路径带着具体的版本年份，而每个人机器上装的 scl 版本号不一样，照抄过去就是一个不存在的路径。lmgrd 启动时不会立刻因为这一行死掉，它会在第一次被请求 feature 时才去 fork 这个守护进程，失败的表现就是lmstat里 feature 全部not available，看起来像 license 没授权，实际是路径指错。
先把路径确认清楚，再回头看文件头两行长什么样：
# 列出本机所有 scl 版本下的 snpslmd，确认到底装了哪一版 ls -l /usr/Synopsys/scl/*/linux64/bin/snpslmd # 确认路径存在后，再看 license 文件的前三行结构 head -n 3 /opt/lic/Synopsys.dat正常应该看到类似这样的内容：
SERVER myhost 001122334455 27000 DAEMON snpslmd /usr/Synopsys/scl/2021.03/linux64/bin/snpslmd USE_SERVERSERVER行是三段式：主机名、hostid、端口号；DAEMON行也是三段式：守护进程名、可执行文件的绝对路径、可选参数。守护进程名必须写snpslmd，写错或者大小写不一致，lmgrd 会认不出来；路径必须是绝对路径，写相对路径等于没写；USE_SERVER是可选项，加上它表示客户端拿到 license 文件后直接去问服务端要 feature，而不是在本地解析。路径改完不要急着重启，先ls -l一遍确认文件在、并且当前用户有执行权限，权限不对同样起不来，而且报错信息非常含蓄。
2.2 端口被占：默认 27000 段冲突的两种不同表现
lmgrd 默认监听 27000，同一台机器上跑两套 license 服务、或者别的软件恰好占了这个端口，就会出现两种完全不同的现象。一种是启动瞬间直接退出，日志里写Address already in use或者Cannot open port，这种好办；另一种是进程起来了，但客户端连过去一直转圈，最后超时，lmstat也连不上，因为端口确实是通的，只是通到了别人身上。第二种最容易误判成网络问题，尤其是机器在机房、中间隔着几层跳板的时候。
排查分两步，先看端口有没有被占，再确认占它的是谁：
# 查看 27000-27019 这一段有没有被监听，输出里带进程名和 PID ss -tunlp | grep -E '2700[0-9]|2701[0-9]' # 如果已经被占用，换一个空端口，同步改 SERVER 行的最后一段 sed -i 's/27000/27001/' /opt/lic/fix_Synopsys.datss -tunlp里的-t是 TCP、-u是 UDP、-n是显示数字端口不解析服务名、-l只看监听态、-p带上进程信息。改完端口只改服务端是不够的，客户端那边指向 license 的环境变量也得跟着改，通常写成端口@主机名的形式，比如27001@myhost。这一步漏掉的话，服务端日志干干净净，客户端一直报连不上，两边各说各话。
提示：如果机器上还留着旧版本 lmgrd 的启动脚本，用 systemd 或 rc.local 开机自启时可能把旧端口那套又拉起来，两套服务抢同一个端口，表现出来就是「昨天还好、今天突然不行」。
2.3 把日志留下来：-l参数决定你有没有黑匣子
不带-l启动 lmgrd，日志默认往终端和系统日志里散，进程一崩就什么都不剩，这是最消耗时间的一种状态。启动时强制指定日志文件，出问题第一时间有东西可看：
# -c 指定 license 文件，-l 指定日志；-2 -p 让前台和日志都保留详细输出 /usr/Synopsys/scl/2021.03/linux64/bin/lmgrd \ -c /opt/lic/fix_Synopsys.dat \ -l /opt/lic/lmgrd.log \ -2 -p-c后面跟的是最终生效的那份 license，注意不是你用 keygen 第一次生成的原始Synopsys.dat，而是手工补完 SIGN 段之后的fix_Synopsys.dat；-l后面跟日志的绝对路径，该目录必须对启动用户可写，否则 lmgrd 会静默退出；-2 -p是让日志保留更详细的诊断信息，排障阶段开着，稳定之后可以去掉。
日志里高频出现的几类内容，对照着看能省很多时间：Failed to open the TCP port是端口问题；Cannot find file后面跟一个路径，基本就是 DAEMON 行写错了；Wrong hostid说明 SERVER 行里的 hostid 和本机对不上；Invalid license key或者license key does not match则是 SIGN 段的问题，得回到第 3 章去看。看到(snpslmd) EXITING反复刷屏，说明守护进程起来又被踢掉，重点查 feature 表。
3. 报 feature not found 或 Invalid license key：feature 表与 SIGN 段的两类错
服务起来了，lmstat也能连上，但客户端还是过不去，这时候错误信息会明确很多，值得逐字读。最常见的是两类：一类是Feature not found或者说某个 feature 未授权，本质是 license 文件里压根没这条 feature；另一类是Invalid license key、Wrong hostid、SIGN相关的报错，本质是签名段不完整或者被工具改坏了。两者的处理路径完全不同，先看报错里到底是 feature 名，还是 key/sign 这类字眼，别一上来就推倒重来。
3.1 feature 不在表里：补Synopsys.src再重生成，比重启一百次有用
Synopsys.src是生成 license 时的特征来源文件，生成器按里面的条目逐条产出 FEATURE 行。工具报某个 feature 找不到，说明这个 feature 名不在 src 里，或者拼写和工具请求的不一致。反复重启 lmgrd 没有任何意义，因为文件里本来就没有这条内容，得回去改源文件再重新生成。
先把日志里报的 feature 名抠出来，然后在 src 里搜一遍：
# 假设报错是 "Feature not found: Verdi"，先把名字记下来 grep -n -i "verdi" /path/to/synlic.gen/Synopsys.src # 没有输出说明确实缺条目，按 src 里已有条目的格式补一行 # 格式一般是：FEATURE 名 守护进程名 版本号 ...看日志时注意，客户端报的名字和服务端日志里的名字可能不完全一致，有的工具会带上版本后缀。以服务端日志里的名字为准，那个才是真正被请求的 feature。补条目的时候严格照着 src 里相邻条目的格式来，冒号、空格、字段顺序都不能乱，src 解析器对格式很敏感，多一个空格可能整行被跳过，而跳过是没有任何提示的——生成出来的 license 里少一条，你又得再来一轮。
补完之后必须回到生成流程的第一步重跑 keygen，重新产出Synopsys.dat，再走一遍改 DAEMON 行、执行fix.bat的完整流程。这里有个血泪经验：只补 src 不重生成，等于什么都没做；重生成之后忘了补 SIGN 段，等于回到原点。
注意：如果目标工具里明确提到了 project_id，
Synopsys.src里的 PID 字段要一起改掉。PID 和工具版本对不上时，表现往往是 feature 明明存在却 check 不出来，日志里也不会直说 PID 有问题。
3.2fix.bat跑失败之后：手动补 SIGN 与 SN 的规则
生成器产出的 license 里，每条 feature 行结尾缺少签名段，fix.bat的作用就是把这些行批量补上。在 Windows 上双击执行，成功的话会得到一个fix_Synopsys.dat。如果执行失败，或者执行完lmgrd仍然报 key 相关错误，就得手动改，规则不难，但细节很容易错。
核心是两件事：把每行结尾的) }替换成带 SIGN 段的完整形式，以及给第 7 行补一个 SN 段。动手之前先备份，改坏了还能回退：
# 先备份，手动改 license 是最容易改废的操作之一 cp Synopsys.dat Synopsys.dat.bak # 把每行结尾的 ") }" 补上 SIGN 段；SIGN 的值以生成器实际输出的一串为准 # 注意 SIGN 前面必须有一个空格，这是最容易漏掉的地方 sed -i 's| ) }| SIGN="<你的SIGN串>" ) }|g' Synopsys.dat # 第 7 行本来没有 ") }"，所以是直接在最前面插 SN 段，同样注意空格 sed -i '7s|^|SN=RK:0:0:1 SIGN="<你的SIGN串>" |' Synopsys.datsed的s|A|B|g是全局替换，|只是分隔符，换成/也行，用|是因为串里可能带斜杠。第二条命令里的7s|^|...|表示只在第 7 行行首插入，^是行首锚点。改完拿head -n 8 Synopsys.dat看一眼前八行，重点确认三件事：每条 feature 结尾都有 SIGN 段、SIGN 和前面的内容之间有一个空格、第 7 行的 SN 段在最前面且格式正确。
原文里那串0000 1111 2222 ...是格式示意，不是真实可用的值，实际要用生成器给出的那串，长度和分段方式一致但内容不同。有人图省事直接抄示意串，结果lmgrd起得来、feature 也在，checkout 的时候一律被拒，日志只说 key 不匹配，不告诉你哪里不匹配——这种排查成本极高。
提示：
fix.bat重复执行会出问题。第一次跑完) }已经变成SIGN="..." ) }，第二次再跑，匹配模式可能把新的结尾又替换一遍，结果一条 feature 尾巴上挂了两个 SIGN 段。改之前先grep -c 'SIGN='数一下，数量应该和 feature 行数对得上。
3.3 时间戳 2004 与 2018：偶发「有时能用有时不能用」的根因
这是最玄学的一类：同样的操作，早上跑通了，下午再跑就 check 不到；换台机器又能用。很多人以为是网络或者并发问题，查了半天没头绪。生成器配置里有个时间字段，默认值是 2004，把它改成 2018 之后，这类偶发问题基本消失，这是踩过很多次之后总结出来的稳定做法。
具体操作就是打开Synopsys.src，找到那个 2004，全部替换成 2018，然后从生成那一步重新走一遍。不要只改生成的 license 文件里的日期，源文件不改，下次重新生成又回到 2004，问题原样复现。改完之后用grep -n "2018" Synopsys.src | head确认真的改到了，有的人只改了一处，文件里还有别的年份字段没动。
至于为什么 2004 不稳定，不必深究到某个内部字段的语义，实际经验就是：某些工具版本在读取老时间戳的 license 时，校验行为不一致，有时放行有时拒绝。换成 2018 之后校验路径变得确定，虽然没人能给出官方解释，但复现次数足够多，就值得当成一条规则固定下来。
顺手把过期时间也一起设好，生成时留出足够的余量，别设成一周后到期。测试环境跑到一半 license 过期，报错信息往往不含「过期」两个字，只报 feature 不可用，又得从头查一遍。
4. Windows 生成、Linux 运行：跨平台搬运 license 的四个断点
整套流程是在 Windows 上跑生成器，产出的文件拷到 Linux 上用，中间隔着一次文件系统搬运和两种操作系统的编码习惯。多数莫名其妙的失败就发生在这段路上：在 Windows 上看着一切正常，拷过去就不认了。这四个断点，按踩坑频率从高到低排。
4.1 hostid 抓错：MAC、hostname 与 SERVER 行必须三方一致
生成 license 时要填 hostid 和 hostname，这两个值最终会写进SERVER行。填错的表现是lmgrd日志里直接甩一句Wrong hostid，或者更隐蔽一点——服务能起，所有 feature 都 check 不出来。
Windows 上抓 hostid 用ipconfig /all，找物理地址那一行，去掉横杠，得到 12 位十六进制串；Linux 上用cat /sys/class/net/eth0/address或者ip link show eth0都能拿到。关键在于：生成时填的必须是最终运行 license 服务的那台 Linux 机器的 hostid，很多人图省事在 Windows 本机上抓了一个，拷到服务器上自然对不上。
# 确认本机 hostid，注意去掉冒号，得到 12 位无分隔的十六进制 cat /sys/class/net/eth0/address | tr -d ':' # 和 license 文件 SERVER 行里的值逐字符比对 head -n 1 /opt/lic/fix_Synopsys.dattr -d ':'是删掉冒号，license 文件里的 hostid 不带分隔符。比对的时候注意大小写，有的工具对大小写敏感。
虚拟机环境还有一个额外变量：网卡是动态分配的，重启或者迁移之后 MAC 会变，昨天能用的 license 今天直接失效。常见做法是在虚拟化平台里把网卡 MAC 固定下来，或者干脆用一个稳定的物理网卡地址。hostname 同理，SERVER行写的是主机名而不是 IP 时，/etc/hosts里必须有对应的解析，否则 lmgrd 启动时会卡在解析上，表现是启动很慢然后失败。
4.2 换行符与编码：CRLF 让守护进程读不完整
Windows 上编辑过的文本文件默认是 CRLF 换行，拷到 Linux 上，每行末尾多一个不可见的\r。对普通配置文件影响不大，但对 license 文件是致命的：DAEMON 行末尾的\r会被当成路径的一部分，lmgrd 去找一个名字里带回车符的文件，当然找不到；SIGN 段也可能因为\r导致解析中断，报错却是 key 不匹配，完全指不到真正的原因。
# 看一眼是不是 CRLF，输出里有 \r 就是 file /opt/lic/fix_Synopsys.dat # 批量清掉行尾回车符，改完再启动服务 sed -i 's/\r$//' /opt/lic/fix_Synopsys.dat # 或者用 dos2unix，语义更直观 dos2unix /opt/lic/fix_Synopsys.datsed -i 's/\r$//'里的\r$匹配行尾的回车符，-i是原地修改。改完再file一次，输出从with CRLF line terminators变成普通 ASCII text 就对了。
编码问题同样隐蔽。Windows 记事本保存时可能选成 GBK，Linux 下按 UTF-8 解析就乱码，注释里的中文会变成一堆问号，严重的时候整行结构解析失败。养成习惯：在 Windows 上改 license 文件用支持指定编码的编辑器，保存时明确选 UTF-8 无 BOM。BOM 头更坑，它在文件最前面加三个字节，第一行SERVER前面多了东西，解析器直接识别不出这是 license 文件。
4.3 过期时间与系统时钟：改日期是最常见的自伤
生成时可以自己设过期时间，有人为了「保险」设成很久以后，有人为了「先试试」设成几天。前者问题不大，后者容易在调试到一半时过期，而过期报错通常不含「过期」字样，只说 feature 不可用，排查方向直接跑偏。
比过期更麻烦的是系统时钟被动过。测试机为了复现某个问题把日期往前调，license 看起来又「复活」了，但日志里的时间戳全乱，和其他服务的证书、缓存、定时任务互相打架，最后谁也说不清哪条日志是哪个时间点的。我一般不在跑 license 服务的机器上动系统时间，需要调时间就在容器或者一次性虚拟机里做。
lmstat的输出里带剩余时间，随时可以确认：
# -a 显示所有 feature 的详细状态，包括到期时间 /usr/Synopsys/scl/2021.03/linux64/bin/lmstat -c 27000@myhost -a-c后面是端口@主机名的形式，-a会逐条列出每个 feature 的授权数量、已用数量、到期日期。这个命令是后面快速定位的核心工具，值得先跑通再谈别的问题。
4.4 project_id 没替换：PID 不匹配导致的「feature 存在但用不了」
生成器配置里，PID 字段对应工具的 project_id。这个东西平时不起眼，一旦目标工具明确要求了某个 project_id 而 src 里没改，就会陷入一种尴尬境地：lmstat里 feature 明明白白列着，客户端就是 check 不出来，日志里既不报 feature not found，也不报 key 错误，只给一句含糊的拒绝。
处理办法是回Synopsys.src，找到 PID 字段，替换成目标工具要求的那个值，然后从生成那一步完整重跑。改完拿grep -n "PID" Synopsys.src确认，有的 src 里 PID 出现在多行配置里，只改一处不够。这类问题排查顺序上应该排得比较靠后——先确认 feature 名对不对、SIGN 段完整不完整，最后才怀疑 PID，因为它出问题的概率低，但一旦命中就很难自己想到。
5. 五个反复踩到的坑：从现象到处理
这一节记录的是排查顺序之外、但反复出现的具体问题。它们的共同点是：报错信息指向的位置和真正的原因不在同一个地方。每条按「现象 → 原因 → 解决」写，方便对照自己的情况。
5.1 改完 license 没重启服务，日志里还是旧内容
现象：改完fix_Synopsys.dat，补了 SIGN 段，重新跑客户端，报错和改之前一模一样。看日志，时间戳还是半小时前的。原因：lmgrd 只在启动时读一次 license 文件，运行期间不会重新加载，文件改了进程不知道。很多人改完直接试客户端，试不通就以为改错了，回头反复折腾文件内容。解决：每次改完文件，先pkill -f lmgrd或者用启动脚本的 stop 命令把进程停干净，确认ps -ef | grep lmgrd没有残留，再重新启动。注意snpslmd是 lmgrd 的子进程，父进程停了子进程通常也跟着退，但偶尔有僵死的，一并清掉。
5.2 日志目录不可写，lmgrd 启动后静默退出
现象：命令行敲下去，没有任何输出，ps一看进程没了，日志文件也没生成。原因：-l指定的日志路径对当前用户不可写，lmgrd 打开日志失败后直接退出，退出时不打印任何东西。用 root 跑过一次成功、换成普通用户就失败，往往就是这个。解决：确认目录属主和权限，ls -ld /opt/lic看一眼，必要时chown或chmod到启动用户可写。排查阶段可以先用-l /tmp/lmgrd.log，/tmp一般都能写，先确认服务本身没问题，再换回正式路径处理权限。
5.3 客户端环境变量还指着旧的端口或旧路径
现象：服务端日志干干净净，lmstat在服务器上跑一切正常，客户端就是连不上，报连不上 license server。原因：客户端指向 license 的环境变量有好几处可能生效，shell 里 export 的、.bashrc里写的、工具自己的配置文件里指定的，优先级还不一样。改端口时只改了服务端，客户端某一处漏改，就一直往旧端口连。解决：先env | grep -i license把所有相关变量列出来，再检查工具安装目录下的 license 配置文件，逐个对齐成同一个端口@主机名。改完开一个新终端验证，别在旧 shell 里试。
5.4fix.bat被执行了两次，一条 feature 挂了两个 SIGN 段
现象：lmgrd能起，lmstat里 feature 也在，checkout 一律失败，日志说 key 不匹配但看不出哪里不匹配。原因：fix.bat在同一份文件上跑了两次，第一次把) }换成SIGN="A" ) }，第二次又匹配到新的结尾再补一遍，变成SIGN="A" SIGN="B" ) }。这种结构解析器不会报格式错，只会认为签名无效。解决：grep -c 'SIGN=' Synopsys.dat数一下 SIGN 出现次数，应该和 feature 行数大致对得上。数量翻倍就说明重复执行了，从备份恢复，重新走一遍生成流程，这次只执行一次fix.bat。
5.5 用记事本改文件，改出了 BOM 头
现象：从 Windows 拷过去，lmgrd报找不到文件或者解析失败，但ls看文件明明在。原因：编辑器保存时加了 UTF-8 BOM，文件最前面多了三个不可见字节，第一行的SERVER前面挂着这三个字节，解析器识别不出这是 license 文件。解决：head -c 3 Synopsys.dat | xxd看前三个字节，如果是ef bb bf就是 BOM。用sed -i '1s/^\xEF\xBB\xBF//'去掉，或者干脆换一个明确支持「UTF-8 无 BOM」的编辑器重写一遍。跨平台传文本文件，这件事最好一次做对，别每次都靠事后清。
6. 三分钟定位：从lmstat到日志的排查顺序
出问题的时候最怕的是到处乱试，顺序错了，改一处引入一个新问题，最后连原始报错都找不回来。我现在的固定顺序是：先看进程活不活，再看端口通不通，然后lmstat看 feature 状态，最后才翻日志。前三步加起来不到一分钟，能排除掉八成的可能性。
# 第一步：进程在不在，有没有僵死的子进程 ps -ef | grep -E 'lmgrd|snpslmd' | grep -v grep # 第二步：端口通不通，能不能连上 ss -tunlp | grep 27000 # 第三步：从这个端口能拿到哪些 feature，到期时间是什么时候 /usr/Synopsys/scl/2021.03/linux64/bin/lmstat -c 27000@myhost -a三步的输出对应三种判断。进程不在，去查 DAEMON 路径和日志目录权限；进程在但端口不通，查端口冲突；端口通、lmstat能连上但列表里没有你要的 feature，问题就锁定在 license 文件内容上，回Synopsys.src补条目重生成。只有前三步都正常、客户端仍然报错，才去怀疑环境变量和编码这类外围因素。
把常见现象和首查位置对成一张表，出问题时照着看比凭记忆靠谱：
| 现象 | 首查位置 | 具体动作 |
|---|---|---|
| lmgrd 启动即退出，无输出 | 日志目录权限 | 换-l /tmp/lmgrd.log重试 |
日志报Cannot find file | DAEMON 行路径 | ls -l确认snpslmd存在 |
日志报Wrong hostid | SERVER 行 | 比对cat /sys/class/net/eth0/address |
日志报Address already in use | 端口占用 | ss -tunlp找占用进程，改端口 |
lmstat能连但 feature 缺失 | Synopsys.src | 补条目，重跑生成流程 |
| feature 在但 checkout 失败 | SIGN 段 | 数 SIGN 数量，检查是否有重复或缺失 |
| Windows 改完拷过去失效 | 换行符与 BOM | sed -i 's/\r$//'并清 BOM |
还有一个容易被忽略的验证动作：在服务端本机用lmstat试通之后，一定要换一台机器、用客户端实际跑一次工具。服务端本机通、客户端不通，问题必然在环境变量或者网络路径上，不用再回头折腾 license 文件内容。这个分界线划清楚，能省掉大量无效改动。
最后说个习惯。我以前改 license 文件从不备份，觉得反正能重新生成，直到有一次改到一半发现原始文件被覆盖，fix.bat也跑过了，只能从生成那一步从头再来，白白耗掉一个下午。从那以后我每次动手前都强制走一遍cp 文件名 文件名.bak.日期，改完先用head -n 8把前八行看一遍再启动服务。这套动作加起来不到二十秒，但救回来的时间远不止这些。资源里的生成脚本、示例文件和批处理都在，按上面这条顺序走一遍，基本能把自己环境里那点问题排干净。希望帮到你。
本文还有配套的精品资源，点击获取
