Но по некоторым причинам это неинтересно, так-же как и вызов утилит типа reboot или shutdown.

Давай-ка озвучь. Ну и man 2 reboot

я так понимаю речь идет о некоем подобии watchdog-а? что userspace может подохнуть по какой то причине и надо делать резет на самом низком уровне?

Какого «определенного»? Есть software watchdog.

Вроде Alt+SysRQ+B?

А собственно… почитать исходники shutdown? И если он взывает с чему-то поверх ядра, прочитать исходники того, к чему он взывает. Там много строчек быть не должно.

/proc/sysrq-trigger

kexec? Или какой тебе програмній ресет?

Из ядра одной известной ОС:

null_idtr:
    .word   0
    .long   0

Entry(cpu_shutdown)
        lidt    null_idtr       /* disable the interrupt handler */
        xor     %ecx,%ecx       /* generate a divide by zero */
        div     %ecx,%eax       /* reboot now */
        ret                     /* this will "never" be executed */

Смешно.
Но почему-то я думаю что для перезагрузки нужно выполнять этот код в нулевом кольце.
В пользовательском пространстве divide by zero приведёт только к выгрузке из памяти приложения поделившего на ноль.

конечно так и будет - просто завершится программа

sudo init 6, не?

но shutdown работает корректно, производит деинициализацию и лишь потом резет, так что не вариант

зато я попробовал Alt+SysRQ+B =))) специально выгрузил все программы и рискнул - сработало :) так что я бы посмотрел что именно так срабатывает и как, и именно эти исходники читал

но вообще, тут довольно странная хотелка: если что-то произойдёт плохое в железке, в оперативке, например, разве ядро не прекратит свою работу? Тогда где будет этот ресет-эт-паник выполняться? Подойдёт разве что для рестарта всей системы при падении одной программы, но это тоже не выход же, можно просто запустить программу ещё раз, принцип вачдога же.

Так что резюмирую: на софтину - собачку, на железку - функцию биоса аль ефи - рестарт при железной ошибке или потере питания. и не нужны тут встроенные велосипеды, пускаемые от рута.

http://ru.wikipedia.org/wiki/SysRq

Можно через контроллер клавиатуры. В порт 0x64 записать 0xFE

согласен - аппаратная собачка надежнее всего на свете

Гипервизор может помочь

Грамотные инженеры делают так: перед установкой основной операционной системы устанавливается программный гипервизор, в котором выделяется одно из ядер для «сторожевой» операционной системы, которая будет следить за остальными операционными системами и ядрами процессора. При «зависании» основной операционной системы, «сторожевая» операционная система продолжает работать, так как это обеспечивает гипервизор и даёт сигнал на перезагрузку основной операционной системы. Вуаля! О том, как это сделано на процессорах от «Фрискейла» можно посмотреть здесь: QorIQ P4080 Embedded Hypervisor

1. Как оказалось, ФС /proc очень слабо зависит от работы конроллера дисков и самих дисков. Был проведен следующий эксперимент: на работающем дебиане 6 был «нагорячую» извлечен PCI-ATA контроллер, через который был подключен основной ЖД и смотрирована корневая ФС. /proc остался доступным как для чтений, так и для записи.

2. Соответсвенно, в качестве метода перезагрузки линукса практически всегда можно использовать запись ключевых значений в файлы/proc/sys/kernel/sysrq и /proc/sysrq-trigger.

3. Здесь было высказано правильное предположение о том, что мне нужен software watchdog. Правда всё ограничилось туманными «волшебными фразами». Чтобы развеять этот туман, привожу пару скриптиков, которые я накатал для работы в качестве сторожевого пса.

#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# dog.py
#

import socket
import commands

status,result = commands.getstatusoutput("ps aux | grep pinger.py | grep -v grep ")
if status!=0 or result=="":
    print "pinger not running. stopping watchdog"
    exit()

countdown_init_value = 5
countdown_counter = countdown_init_value

serversocket = socket.socket( socket.AF_INET, socket.SOCK_DGRAM, socket.SOL_UDP )
serversocket.settimeout(10)
serversocket.bind( ( '127.0.0.1', 7777 ) )

while True: # recvfrom блокирующий, поэтому не беспокоимся из-за бесконечного цикла
    try:
        tmp=serversocket.recvfrom( 100 )
    except socket.timeout:
        countdown_counter-=1
        print 'timeout occured',countdown_counter
    else:
        countdown_counter = countdown_init_value
    if countdown_counter <= 0:
        print "boom!"
        f1 = open( '/proc/sys/kernel/sysrq', 'w' )
        f2 = open( '/proc/sysrq-trigger', 'w' )
        f1.write('1')
        f1.close()
        f2.write('b')
        f2.close()

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# pinger.py
#

import os
import mmap
import socket
import time

def io_process(): # осуществляет небуферизированный (O_DIRECT) ввод-вывод в тестовый файл
    f = os.open('/watchdog_detector', os.O_CREAT | os.O_DIRECT | os.O_TRUNC | os.O_RDWR)
    m = mmap.mmap(-1, 1024 * 1024)  # с помощью модуля mmap выделяет буфер в ОЗУ, размером в 1Кб
    s = '+' * 1024 * 1024           # опция O_DIRECT требует чтобы записываемые данные были выровнены
                                    # по границе 512 байт. выделение буфера через mmap позволяет провернуть такой трюк
                                    # поскольку mmap размещает буфера в выровненных 4-байтных страницах
    m.write(s)
    os.write(f, m)
    os.close(f)

def send_heartbeat():
    s = socket.socket( socket.AF_INET, socket.SOCK_DGRAM, socket.SOL_UDP )
    s.sendto( "ping", ("127.0.0.1",7777) )


while True: # большую часть поток времени, поток будет в спячке через time.sleep, поэтому не смущаемся использованием бесконечного цикла
    io_process() # если отвалился дисковый ввод-вывод то в этом месте произойдёт блокировка, причём надолго. Если файловая система перемонтировалась на чтение, то здесь возникнет эксепшн, который уронит весь скрипт, что нас как раз устроит
    send_heartbeat() # функция отправки UDP-пакета неблокирующая, поэтому уснём после отправки сообщения
    time.sleep(5)

Грамотные инженеры делают так: многа букафф...

Грамотные инженеры делают так:
паяют маленькую схемку с 1 микрухой, в speeaker втыкают считалку бипов (генерирует система 1 в секунду) и при отсутствии бипов в течение 5-8 секунд (повисла система) - замыкают хардварный reset.

себестоимость такой штучки копеечная, работает безотказно, дрова для бипера в открытом виде валяются по интернету, встречал в нескольких вариациях.

А что, хороший вариант для случая, когда нет аппаратного watchdog'а. Вот только говорят, что он есть везде.

Какой ты толстый, прямо как на картинке!

8)

Я читал что можно инициировать программную перезагрузку записав определенные значения в системные файлы в proc.Но по некоторым причинам это неинтересно, так-же как и вызов утилит типа reboot или shutdown.

Ну если относительно прямой метод (sysrq через /proc) тебя не интересует, то можно загрузить модуль ядра softdog, затем инициализировать watchdog из юзерспейса, но не посылать ему сигналы как при нормальной работе (запустить watchdogd и сделать pkill -STOP watchdogd).

Грамотные инженеры делают так:
паяют маленькую схемку с 1 микрухой, в speeaker втыкают считалку бипов (генерирует система 1 в секунду) и при отсутствии бипов в течение 5-8 секунд (повисла система) - замыкают хардварный reset.

Ещё более грамотные инженеры знают про существование параллельного порта, RS232 и других интерфейсов, которые для этой задачи более подходят.

А ънтерпрайзные инженеры знают про готовые аппаратные watchdog'и, которые часто встроены в другое серверное железо.