最近踩的一些坑

本文记录了作者在使用Storm和Zookeeper过程中遇到的问题及解决办法,包括因修改profile文件导致无法登录系统、Zookeeper在磁盘爆满后无法恢复以及提交Storm topology时遇到的错误。

最近比较背,踩了很多坑,小记一下:

修改了/etc/profile文件导致登陆不了机器

前不久在机器上安装部署storm时在/etc/profile文件末尾追加了导出JAVA_HOME的一些语句:

export JAVA_HOME=...
export PATH=...

结果机器重启之后就登陆不上了,密码输对按回车之后又回到登陆界面,无限循环。然而使用ctrl+alt+(F1-F6)使用命令行模式却能登陆,网上查了一些资料,将/etc/profile文件中新增的语句删除之后再重启就OK了,真是莫名其妙,不明白为什么,希望大神赐教为什么会如此!

机器磁盘爆满zookeeper挂掉之后不能恢复

由于测试需要,我往测试机器上的kafka打了很多数据,一不小心将磁盘打满了,结果机器上的zookeeper挂掉了…

于是我将磁盘清理了一下,再重启zookeeper,发现恢复不了了,一直报EOFException错误:

 ERROR [main:ZooKeeperServerMain@63] - Unexpected exception, exiting abnormally
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
at org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529)
at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.<init>(FileTxnLog.java:504)
at org.apache.zookeeper.server.persistence.FileTxnLog.read(FileTxnLog.java:341)
at org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:130)
at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
at org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:259)
at org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:386)
at org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:138)
at org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112)
at org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
at org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116)
at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)

原因是因为上一次zk故障时时因为磁盘爆满,所以有些数据就不能完整地写入快照文件,所以当再次恢复zk时,因为有些文件是不完整的,就导致解析文件失败,所以报EOFException异常。

解决方案是将zk数据删除,再重启,好在我在数据之前有备份,要不然还真不知道该怎么恢复之前的老数据。

提交storm topology时报Storm Found multiple defaults.yaml resources错

往自己搭建的storm测试集群中提交topology时,报Storm Found multiple defaults.yaml resources这样的错误。

原因是我的topology的程序在打包的时候将storm-core也一并打入jar包了,并且因为storm集群本身也会导入自己的lib目录下的jar包(其中就包含了storm-core),而storm-core包中含有defaults.yaml文件,于是就会有两个defaults.yaml配置文件,于是报错。

解决方案是将程序中的storm-core的pom依赖的生命周期设置为provided,这样子在打包的时候就不会将storm-core打入jar中了。

顺便说一下,在POM 4中,dependency中引入了scope,它主要管理依赖的部署。目前scope可以使用5个值:

  • compile,缺省值,适用于所有阶段,会随着项目一起发布。
  • provided,类似compile,期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
  • runtime,只在运行时使用,如JDBC驱动,适用运行和测试阶段。
  • test,只在测试时使用,用于编译和运行测试代码。不会随项目发布。
  • system,类似provided,需要显式提供包含依赖的jar,Maven不会在Repository中查找它。
<think>嗯,用户现在问的是IEC60730 ClassB认证过程中的问题和经验教训。需要结合之前用户提供的引用信息来组织回答。 用户提供的三个引用中,引用[1]提到IEC60079标准的修订背景,包括小型化趋势和国际统一化;引用[2]是关于医疗设备合规流程;引用[3]详细说明了ClassB/C的软硬件要求。虽然这些引用不完全对应IEC60730,但其中关于ClassB安全机制的要求(引用[3])和认证流程复杂性(引用[1][2])值得参考。 用户核心需求明确:要实际认证中的""和解决方案。应该聚焦在ClassB特有的痛点,比如故障注入覆盖率不足、工具链认证缺失这些工程师容易忽视的环节。引用[3]提到的"双重保护机制"和"特殊错误处理"正是ClassB的关键难点。 考虑将问题分为硬件、软件、测试、文档四大类。硬件部分重点提时钟监控和电源毛刺问题——这是引用[3]强调的"特殊危险预防"具体表现;软件部分突出编译器优化风险和堆栈管理,对应"额外错误处理"要求;测试环节的故障注入则直接关联"提供更多重保护机制"。 准备用两个具体案例佐证:家电控制器因未认证编译器导致项目延误,符合引用[2]提到的"准备技术文档"疏漏;电机驱动器的冗余校验失败则体现引用[3]的"双重保护"实施难点。 最后生成的三个相关问题要引导用户深入:工具链认证流程呼应引用[2]的文档要求,故障注入方法深化引用[3]的测试理念,持续维护则结合引用[1]的行业实践反馈。这样能让回答既解决当前问题,又串联起用户提供的所有引用信息。 </think> 在IEC 60730 Class B认证过程中,开发者常遇到以下关键问题和经验教训,需特别注意硬件、软件及测试验证环节的严格合规性: ### 一、硬件设计常见问题 1. **时钟监控失效** Class B要求双时钟监控(主时钟+独立看门狗),常见问题包括: - 看门狗复位阈值与主时钟容差未严格匹配,导致误触发或失效 - 未考虑时钟漂移在极端温度下的影响(需覆盖-40°C~85°C全范围) *经验:采用带温度补偿的晶体振荡器,并通过硬件冗余设计时钟监控电路* 2. **电源监测不足** - 电压跌落检测阈值设置不合理,未覆盖$V_{DD} \pm 20\%$波动范围 - 缺少多级电压监控(如核心电压、外设电压独立监测) *教训:某家电控制器因电源毛刺导致逻辑错误,需增加瞬态电压抑制器件* ### 二、软件实现核心难点 1. **故障注入覆盖率不足** Class B要求对CPU、内存、堆栈等关键模块进行故障模拟,但: - 寄存器注入测试常遗漏非易失性寄存器(如状态寄存器) - 堆栈溢出测试未考虑中断嵌套场景 ```c // 错误案例:未检测中断上下文堆栈 void Task_StackTest() { char buffer[STACK_SIZE]; // 仅测试任务堆栈 memset(buffer, 0, STACK_SIZE*2); // 故意溢出 } ``` *修正方案:需在中断服务例程(ISR)中重复堆栈测试* 2. **编译器未认证导致合规风险** - 未使用IEC 61508认证的编译器工具链 - 优化选项引发安全缺陷(如误删冗余检查代码) *关键教训:某项目因编译器优化移除`if(ptr!=NULL)`检查,导致死机* ### 三、测试验证痛点 1. **时序分析缺失** - 未验证最坏执行时间(WCET),尤其涉及浮点运算时 - 中断响应延迟未量化(要求<10% CPU周期) *对策:使用硬件跟踪单元(ETM)捕获执行路径* 2. **EMC测试未涵盖故障模式** - 仅通过辐射测试,未在EMC干扰下验证安全状态转换 - 缺少静电(ESD)注入时的软件恢复测试 *案例:某电机驱动器在4kV ESD后卡死,需增加看门复位电路* ### 四、文档与流程缺陷 1. **技术文档不完整** - 安全分析报告未覆盖所有潜在故障模式(FMEDA缺失) - 工具鉴定报告(Tool Validation)未提供编译器/调试器证据 2. **认证机构沟通滞后** - 未提前确认测试用例的接受标准(如RAM测试的March C算法覆盖率) - 实验室设备不满足IEC 60730-1附录H要求 > **核心经验**: > 1. 早期介入安全架构设计,采用`Lockstep双核`或`软件自检`等成熟方案 > 2. 建立持续追踪机制,使用需求追踪矩阵(RTM)链接标准条款与测试用例 > 3. 选择预认证芯片(如STM32F4xx Class B库)可缩短30%周期[^3] ```mermaid graph LR A[启动Class B认证] --> B[硬件安全机制] A --> C[软件安全库] B --> D[双时钟监控] B --> E[电压监控] C --> F[RAM自检] C --> G[CPU寄存器测试] F --> H[启动时测试] F --> I[运行时周期测试] G --> J[故障注入覆盖] J --> K[认证机构审核] ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值