Linux如何应对闰秒导致的死锁问题？ (linux处理闰秒死锁)

近年来，由于全球协调时间（UTC）需要不定期地增加一秒的闰秒，导致许多操作系统都出现了类似于死锁的问题，其中Linux操作系统也不例外。那么，Linux如何应对闰秒导致的死锁问题呢？

闰秒会导致系统时钟的不连续性，从而引发一系列的问题。在Linux中，闰秒问题通常表现为系统进程或线程卡死（Deadlock）、网络服务不可用或运行异常等现象，从而导致系统失去响应。

针对这一问题，Linux系统进行了多方面的优化和升级，以更大程度地避免闰秒问题的出现。

防止时间错误的累积

为了避免时间错误的累积，Linux内核会监控系统时间，并在发现时间累积一秒时，立即进行调整，保证系统时间的正确性。

但是，如果闰秒的处理不当，可能会导致时间错误的累积。例如，当系统时钟出现倒退时，可能会触发操作系统的时间戳倒退检查（Time stamp counter retracing check），从而引发死锁问题。

因此，Linux内核会对时钟进行多轮的同步，确保系统时间的准确性。同时，还会对系统时钟的调整进行限制，避免频繁进行调整，从而导致时间错误的累积。

优化升级版本

Linux的各个版本也在不断地进行优化和升级，以更大程度地避免闰秒问题的出现。

例如，早期的Linux内核版本中，存在时间累积的问题，会导致系统时间出现明显的偏差。而在Linux 4.1版本中，内核对时钟进行了优化，避免了时间错误的累积问题。同时，内核还添加了timerslack参数，可以调整系统时钟的频率，防止时间错误的累积。

此外，Linux还对操作系统的各项服务进行了优化和改进。例如，对于NTP（网络时间协议）服务，Linux会自动进行时钟同步，并将时钟误差定为“时钟漂移”。当闰秒出现时，系统会自适应地将时钟漂移进行调整，避免时间错误的累积。

总而言之，Linux系统采取了多种措施来应对闰秒导致的死锁问题。内核会监控系统时间，并在发现时间累积一秒时，立即进行调整，以保证系统时间的正确性。通过优化和升级版本，避免了时间错误的累积问题。对于各项服务进行了优化和改进，自动进行时钟同步，并自适应地调整时钟漂移，避免时间错误的累积。

虽然闰秒问题可能导致一些操作系统的死锁等问题，但通过Linux系统的多方面优化和升级，已经在很大程度上解决了这一问题，为系统的高可用性和可靠性提供了保障。

相关问题拓展阅读：

• 请教linux下用户态进程调度问题

请教linux下用户态进程调度问题

在进行Linux系统操作的时候，有时候会遇到一次用户态进程死循环，即系统反应迟钝、进程挂死等问题，那么遇到这些问题又该如何解决呢？下面小编就给大家介绍下一次用户态进程死循环的问题该如何处瞎颤理。

Linux下如何处理一次用户态进程死循环问题

　　1、问题现象

　　业务进程（用户态多线程程序）挂死，操作系统反应迟钝，系统日志没有任何异常。从进程的内核态堆栈看，看似所有线程都卡在了内核态的如下堆栈流程中：

　　［root@vmc116 ~］# cat /proc/27007/task/11825/stack

　　［《ffffffff8100baf6》］ retint_careful+0x14/0x32

　　［《ffffffffffffffff》］ 0xffffffffffffffff

　　2、喊兄问题分析

　　1）内核堆栈分析

　　从内核堆栈看，所有进程都阻塞在 retint_careful上，这个是中断返回过程中的流程，代码（汇编）如下：

　　entry_64.S

　　代码如下：

　　ret_from_intr：

　　DISABLE_INTERRUPTS（CLBR_NONE）

　　TRACE_IRQS_OFF

　　decl PER_CPU_VAR（irq_count）

　　/* Restore saved previous stack */

　　popq %rsi

　　CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */

　　leaq ARGOFFSET-RBP（%rsi）， %rsp

　　CFI_DEF_CFA_REGISTER rsp

　　CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET

　　。。。

　　retint_careful：

　　CFI_RESTORE_STATE

　　bt $TIF_NEED_RESCHED，%edx

　　jnc retint_signal

　　TRACE_IRQS_ON

　　ENABLE_INTERRUPTS（CLBR_NONE）

　　pushq_cfi %rdi

　磨渗败　SCHEDULE_USER

　　popq_cfi %rdi

　　GET_THREAD_INFO（%rcx）

　　DISABLE_INTERRUPTS（CLBR_NONE）

　　TRACE_IRQS_OFF

　　jmp retint_check

　　这其实是用户态进程在用户态被中断打断后，从中断返回的流程，结合retint_careful+0x14/0x32，进行反汇编，可以确认阻塞的点其实就在

　　SCHEDULE_USER

　　这其实就是调用schedule（）进行调度，也就是说当进程走到中断返回的流程中时，发现需要调度（设置了TIF_NEED_RESCHED），于是在这里发生了调度。

　　有一个疑问：为什么在堆栈中看不到schedule（）这一级的栈帧呢？

　　因为这里是汇编直接调用的，没有进行相关栈帧压栈和上下文保存操作。

　　2）进行状态信息分析

　　从top命令结果看，相关线程实际一直处于R状态，CPU几乎完全耗尽，而且绝大部分都消耗在用户态：

　　［root@vmc116 ~］# top

　　top – 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62

　　Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie

　　Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st

　　Mem：k total，k used，k free，k buffers

　　Swap：k total， 38644k used，k free，k cached

　　PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

rootm 163m 14m R 10.2 0.5 321:06.17 z_itask_templat

rootm 163m 14m R 10.2 0.5 296:23.37 z_itask_templat

rootm 163m 14m R 10.2 0.5 337:57.26 z_itask_templat

rootm 163m 14m R 10.2 0.5 327:31.93 z_itask_templat

rootm 163m 14m R 10.2 0.5 306:49.44 z_itask_templat

rootm 163m 14m R 10.2 0.5 310:47.41 z_itask_templat

rootm 163m 14m R 10.2 0.5 283:03.37 z_itask_templat

rootm 163m 14m R 10.2 0.5 283:49.67 z_itask_templat

rootm 163m 14m R 10.2 0.5 261:24.46 z_itask_templat

rootm 163m 14m R 10.2 0.5 150:24.53 z_itask_templat

rootm 163m 14m R 10.2 0.5 100:26.77 z_itask_templat

rootm 163m 14m R 9.9 0.5 337:18.77 z_itask_templat

rootm 163m 14m R 9.9 0.5 314:24.17 z_itask_templat

rootm 163m 14m R 9.9 0.5 336:32.78 z_itask_templat

rootm 163m 14m R 9.9 0.5 338:55.08 z_itask_templat

rootm 163m 14m R 9.9 0.5 306:46.08 z_itask_templat

rootm 163m 14m R 9.9 0.5 316:49.51 z_itask_templat

　　。。。

　　3）进程调度信息

　　从相关线程的调度信息看：

　　［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat

　　［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat

　　［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat

　　［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat

　　［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat

　　发现相关线程的调度统计一直在增加，说明相关线程一直是在被调度运行的，结合其状态也一直是R，推测很可能在用户态发生了死循环（或者非睡眠死锁）。

　　这里又有问题：为什么从top看每个线程的CPU占用率只有10%左右，而不是通常看到的死循环进程导致的100%的占用率？

　　因为线程数很多，而且优先级都一样，根据CFS调度算法，会平均分配时间片，不会让其中一个线程独占CPU。结果为多个线程间轮流调度，消耗掉了所有的cpu。。

　　另一个问题：为什么这种情况下，内核没有检测到softlockup？

　　因为业务进程的优先级不高，不会影响watchdog内核线程（更高优先级的实时线程）的调度，所以不会产生softlockup的情况。

　　再一个问题：为什么每次查看线程堆栈时，总是阻塞在retint_careful，而不是其它地方？

　　因为这里（中断返回的时候）正是调度的时机点，在其它时间点不能发生调度（不考虑其它情况~），而我们查看线程堆栈的行为，也必须依赖于进程调度，所以我们每次查看堆栈时，正是查看堆栈的进程（cat命令）得到调度的时候，这时正是中断返回的时候，所以正好看到的阻塞点为retint_careful。

　　4）用户态分析

　　从上面的分析看，推测应该是用户态发生了死锁。

　　用户态确认方法：

　　部署debug信息，然后gdb attach相关进程，确认堆栈，并结合代码逻辑分析。

　　最终确认该问题确为用户态进程中产生了死循环。

关于linux处理闰秒死锁的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。

香港服务器首选树叶云，2H2G首月10元开通。
树叶云（shuyeidc.com）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。