Что может вызвать в системном журнале одно предупреждение «rcu_sched обнаружил остановку процессора»?
Один из способов сделать это - указать, что ваша служба запускается раньше другой службы, используя Before=. В данном случае, поскольку нет графического интерфейса, и вы хотите предотвратить вход в консоль, вам нужно использовать getty@.service. (Обратите внимание, однако, что это параметризованный сервис, и в данном случае часть после @ указывает, на каком устройстве запускать getty). Например:
[Unit]
Description=Run script to set up environment
Before=getty@tty1.service getty@tty2.service getty@tty3.service getty@tty4.service getty@tty5.service getty@tty6.service
[Service]
Type=oneshot
ExecStart=/bin/myscript
Это обеспечит запуск вашего скрипта до того, как getty запустится на TTY 1-6.
В качестве альтернативы, вы можете создать (пустой) файл, который будет указывать getty@.service not на запуск. Преимущество этого способа в том, что он автоматически добавит условие ко всем экземплярам getty, а не только к 1-6.
Чтобы сделать это, сначала создайте файл до запуска вашей службы:
[Unit]
Description=Run script to set up environment
[Service]
Type=oneshot
ExecStartPre=/bin/touch /etc/no-login-console
ExecStart=/bin/myscript
ExecStopPost=/bin/rm /etc/no-login-console
Затем выполните systemctl edit getty@.service. Это откроет ваш редактор и создаст файл "override", который будет фактически добавлен к основному файлу службы. Таким образом, вы сможете внести свои собственные изменения в сервис, но при этом сможете использовать последние версии сервисного файла CentOS. В открывшемся редакторе введите:
[Unit]
ConditionPathExists=!/etc/no-login-console
Это указывает службе запускаться, только если /etc/no-login-console не существует. Сохраните и выйдите из редактора. Когда вы запустите systemctl cat getty@.service, вы увидите основной файл службы, за которым следует ваше переопределение.
Редактирование: Похоже, что systemctl edit и systemctl cat недоступны в версии systemd, поставляемой в CentOS 7.1. Вместо этого выполните sudo vim /lib/systemd/system/getty@.service.d/condition-path.conf (где /lib/systemd/system/getty@.service - путь к служебному файлу) и добавьте в файл приведенный выше текст. Затем выполните systemctl daemon-reload, а затем systemctl status getty@. В выводе должно быть указано, что был прочитан загруженный файл.
Скорее всего, это вызвано одной из трех причин:
- Очень сложно вызвать ошибку ядра. Я не думаю, что это вероятно, так как материал RCU настолько важен для ядра, что любые ошибки, вероятно, затронуты почти всеми.
- Плохое ОЗУ. Повреждение памяти, вызванное плохим модулем памяти, может довольно легко привести к странным вещам, подобным этому.
- Временная ошибка памяти, вызванная чем-то другим, кроме самой памяти. Аналогично предыдущему, но вряд ли появится снова. Это тип вещей, от которых память ECC пытается защитить (, но не может полностью, потому что вполне возможно, что что-то пойдет не так в логике ECC ).
Если это не повторится, вы, вероятно, можете предположить, что это случай 3, и просто двигаться дальше. Если это произойдет снова, поищите сходство в окружающих сообщениях ядра и/или проверьте свою оперативную память.
Я столкнулся с такой ошибкой (Задержка процессора )на плате NVidia Jetson.
Пообщавшись с NVidia и поработав над нашими Jetsons, я обнаружил, что некоторые из наших карт получают около 80 000 прерываний в секунду только от устройства Bluetooth. Отключение соответствующего модуля этого устройства предотвратило остановку процессора.
Чтобы узнать, сколько прерываний вы получаете, посмотрите на /proc/interrupts. Обратите внимание, что мои зависания происходили из-за того, что также использовался RJ45, и с таким количеством прерываний я попадал в тупик ядра Linux (. Обратите внимание, что это, вероятно, не само ядро, а драйверы, обрабатывающие Bluetooth и RJ45 ).
Вот пример, в котором мы видим, что несколько функций ссылаются на «net» или «ip». Мы также видим el1_irq, который говорит нам, что мы обрабатываем IRQ.
Итак, согласно списку Остина, я столкнулся с проблемой, как определено в (1 ).
Feb 1 08:53:16 ve5 kernel: [ 1459.074481] INFO: rcu_preempt self-detected stall on CPU
Feb 1 08:53:16 ve5 kernel: [ 1459.074646] 0-...: (8 GPs behind) idle=ea9/140000000000001/0 softirq=32059/32059 fqs=2112
Feb 1 08:53:16 ve5 kernel: [ 1459.074794] (t=5250 jiffies g=10249 c=10248 q=48)
Feb 1 08:53:16 ve5 kernel: [ 1459.074906] Task dump for CPU 0:
Feb 1 08:53:16 ve5 kernel: [ 1459.074926] ksoftirqd/0 R running task 0 3 2 0x00000002
Feb 1 08:53:16 ve5 kernel: [ 1459.074943] Call trace:
Feb 1 08:53:16 ve5 kernel: [ 1459.074963] [<ffffff800808bdb8>] dump_backtrace+0x0/0x198
Feb 1 08:53:16 ve5 kernel: [ 1459.074972] [<ffffff800808c37c>] show_stack+0x24/0x30
Feb 1 08:53:16 ve5 kernel: [ 1459.074983] [<ffffff80080ecf70>] sched_show_task+0xf8/0x148
Feb 1 08:53:16 ve5 kernel: [ 1459.074991] [<ffffff80080efc70>] dump_cpu_task+0x48/0x58
Feb 1 08:53:16 ve5 kernel: [ 1459.075001] [<ffffff80081c1acc>] rcu_dump_cpu_stacks+0xb8/0xec
Feb 1 08:53:16 ve5 kernel: [ 1459.075012] [<ffffff8008132450>] rcu_check_callbacks+0x728/0xa48
Feb 1 08:53:16 ve5 kernel: [ 1459.075020] [<ffffff8008138cac>] update_process_times+0x34/0x60
Feb 1 08:53:16 ve5 kernel: [ 1459.075030] [<ffffff800814a218>] tick_sched_handle.isra.5+0x38/0x70
Feb 1 08:53:16 ve5 kernel: [ 1459.075037] [<ffffff800814a29c>] tick_sched_timer+0x4c/0x90
Feb 1 08:53:16 ve5 kernel: [ 1459.075044] [<ffffff80081399e0>] __hrtimer_run_queues+0xd8/0x360
Feb 1 08:53:16 ve5 kernel: [ 1459.075051] [<ffffff800813a330>] hrtimer_interrupt+0xa8/0x1e0
Feb 1 08:53:16 ve5 kernel: [ 1459.075061] [<ffffff8008bffe98>] arch_timer_handler_phys+0x38/0x58
Feb 1 08:53:16 ve5 kernel: [ 1459.075071] [<ffffff8008126f10>] handle_percpu_devid_irq+0x90/0x2b0
Feb 1 08:53:16 ve5 kernel: [ 1459.075078] [<ffffff80081214f4>] generic_handle_irq+0x34/0x50
Feb 1 08:53:16 ve5 kernel: [ 1459.075085] [<ffffff8008121bd8>] __handle_domain_irq+0x68/0xc0
Feb 1 08:53:16 ve5 kernel: [ 1459.075092] [<ffffff8008080d44>] gic_handle_irq+0x5c/0xb0
Feb 1 08:53:16 ve5 kernel: [ 1459.075099] [<ffffff8008082c28>] el1_irq+0xe8/0x194
Feb 1 08:53:16 ve5 kernel: [ 1459.075108] [<ffffff8008231de4>] kmem_cache_alloc+0x114/0x2c0
Feb 1 08:53:16 ve5 kernel: [ 1459.075118] [<ffffff8008db94a4>] dst_alloc+0x6c/0xb0
Feb 1 08:53:16 ve5 kernel: [ 1459.075127] [<ffffff8008df6a2c>] rt_dst_alloc+0x74/0xe8
Feb 1 08:53:16 ve5 kernel: [ 1459.075134] [<ffffff8008df7ca0>] ip_route_input_noref+0x3c0/0x8f8
Feb 1 08:53:16 ve5 kernel: [ 1459.075144] [<ffffff8008e34a00>] arp_process+0x3e8/0x708
Feb 1 08:53:16 ve5 kernel: [ 1459.075152] [<ffffff8008e34e70>] arp_rcv+0x118/0x1a8
Feb 1 08:53:16 ve5 kernel: [ 1459.075161] [<ffffff8008da9c20>] __netif_receive_skb_core+0x3b8/0xad8
Feb 1 08:53:16 ve5 kernel: [ 1459.075169] [<ffffff8008dad010>] __netif_receive_skb+0x28/0x78
Feb 1 08:53:16 ve5 kernel: [ 1459.075175] [<ffffff8008dad08c>] netif_receive_skb_internal+0x2c/0xb0
Feb 1 08:53:16 ve5 kernel: [ 1459.075182] [<ffffff8008dadcb4>] napi_gro_receive+0x15c/0x188
Feb 1 08:53:16 ve5 kernel: [ 1459.075192] [<ffffff800894dd90>] eqos_napi_poll_rx+0x358/0x430
Feb 1 08:53:16 ve5 kernel: [ 1459.075199] [<ffffff8008daf2e4>] net_rx_action+0xf4/0x358
Feb 1 08:53:16 ve5 kernel: [ 1459.075206] [<ffffff8008081054>] __do_softirq+0x13c/0x3b0
Feb 1 08:53:16 ve5 kernel: [ 1459.075215] [<ffffff80080baf38>] run_ksoftirqd+0x48/0x58
Feb 1 08:53:16 ve5 kernel: [ 1459.075225] [<ffffff80080e07c8>] smpboot_thread_fn+0x160/0x248
Feb 1 08:53:16 ve5 kernel: [ 1459.075232] [<ffffff80080dbe64>] kthread+0xec/0xf0
Feb 1 08:53:16 ve5 kernel: [ 1459.075239] [<ffffff80080838a0>] ret_from_fork+0x10/0x30