Ações destrutivas do kernel

Algumas ações são destrutivas para todo o sistema. Essas ações obviamente devem ser usadas com muito cuidado, pois elas irão afetar todos os processos no sistema e qualquer outro sistema que dependa implicita ou explicitamente dos serviços de rede do sistema afetado.

breakpoint()

void breakpoint(void)

A ação breakpoint() induz a um ponto de interrupção do kernel, fazendo com que o sistema pare e transfira o controle para o depurador do kernel. O depurador do kernel emitirá uma seqüência indicando o teste do DTrace que acionou a ação. Por exemplo, se a seguinte ação fosse realizada:

# dtrace -w -n clock:entry'{breakpoint()}'
dtrace: allowing destructive actions
dtrace: description 'clock:entry' matched 1 probe

No Solaris em execução no SPARC, a seguinte mensagem poderia aparecer no console:

dtrace: breakpoint action at probe fbt:genunix:clock:entry (ecb 30002765700)
Type  'go' to resume
ok

No Solaris em execução no x86, a seguinte mensagem poderia aparecer no console:

dtrace: breakpoint action at probe fbt:genunix:clock:entry (ecb d2b97060)
stopped at      int20+0xb:      ret
kmdb[0]:

O endereço após a descrição do teste é o endereço do bloco de controle de ativação (ECB) no DTrace. Você pode usar esse endereço para determinar mais detalhes sobre a ativação do teste que induziu a ação de ponto de interrupção.

Um erro na ação breakpoint() pode fazer com que ela seja chamada mais vezes do que o pretendido. Esse comportamento pode, por sua vez, impedir até mesmo que você encerre o consumidor do DTrace que está acionando as ações de ponto de interrupção. Nessa situação, defina a variável de inteiro do kernel dtrace_destructive_disallow como 1. Essa configuração irá impedir todas as ações destrutivas na máquina. Aplique essa configuração somente nessa situação em particular.

O método exato para a definição de dtrace_destructive_disallow dependerá do depurador do kernel que você está usando. Se estiver usando o PROM de OpenBoot em um sistema SPARC, use w!:

ok 1 dtrace_destructive_disallow w!
ok

Confirme que a variável foi definida usando-se w?:

ok dtrace_destructive_disallow w?
1
ok

Continue digitando go:

ok go

Se estiver usando kmdb(1) em sistemas x86 ou SPARC, use o modificador de gravação de 4 bytes (W) com o dcmd de formatação /:

kmdb[0]: dtrace_destructive_disallow/W 1
dtrace_destructive_disallow:    0x0             =       0x1
kmdb[0]:

Continue usando :c:

kadb[0]: :c

Para reativar ações destrutivas após prosseguir, você precisará redefinir explicitamente dtrace_destructive_disallow de volta para 0 usando mdb(1):

# echo "dtrace_destructive_disallow/W 0" | mdb -kw
dtrace_destructive_disallow:    0x1             =       0x0
#

panic()

void panic(void)

A ação panic () causa um aviso grave no kernel quando acionada. Essa ação deve ser usada para forçar um despejo de memória do sistema quando for necessário. Você pode usar essa ação junto com o buffer de anel e a análise post mortem para compreender um problema. Para obter mais informações, consulte o Capítulo 11Buffers e armazenamento em buffer e o Capítulo 37Rastreio post-mortem respectivamente. Quando a ação panic é usada, uma mensagem é exibida indicando o teste que causou o aviso grave. Por exemplo:

  panic[cpu0]/thread=30001830b80: dtrace: panic action at probe
  syscall::mmap:entry (ecb 300000acfc8)

  000002a10050b840 dtrace:dtrace_probe+518 (fffe, 0, 1830f88, 1830f88,
    30002fb8040, 300000acfc8)
    %l0-3: 0000000000000000 00000300030e4d80 0000030003418000 00000300018c0800
    %l4-7: 000002a10050b980 0000000000000500 0000000000000000 0000000000000502
  000002a10050ba30 genunix:dtrace_systrace_syscall32+44 (0, 2000, 5,
    80000002, 3, 1898400)
    %l0-3: 00000300030de730 0000000002200008 00000000000000e0 000000000184d928
    %l4-7: 00000300030de000 0000000000000730 0000000000000073 0000000000000010

  syncing file systems... 2 done
  dumping to /dev/dsk/c0t0d0s1, offset 214827008, content: kernel
  100% done: 11837 pages dumped, compression ratio 4.66, dump
  succeeded
  rebooting...

syslogd(1M) também emitirá uma mensagem na reinicialização:

  Jun 10 16:56:31 machine1 savecore: [ID 570001 auth.error] reboot after panic:
  dtrace: panic action at probe syscall::mmap:entry (ecb 300000acfc8)

O buffer de mensagem do despejo de memória também contém o teste e o ECB responsável pela ação panic().

chill()

void chill(int nanoseconds)

A ação chill () faz com que o DTrace gire para o número especificado de nanossegundos. chill() é principalmente útil para explorar problemas que possam estar relacionados ao tempo. Por exemplo, você pode usar essa ação para abrir janelas de condição de corrida ou para colocar ou tirar eventos periódicos de fase entre si. Como as interrupções são desativadas durante o contexto de teste do DTrace, qualquer uso de chill() irá induzir à latência de interrupção, latência de agendamento e latência de distribuição. Portanto, chill() pode causar efeitos sistêmicos não esperados e não deve ser usada indiscriminadamente. Como a atividade do sistema depende de uma manipulação periódica de interrupção, o DTrace irá se recusar a executar a ação chill() por mais de 500 milissegundos de cada intervalo de um segundo em uma determinada CPU. Se o intervalo máximo de chill() for excedido, o DTrace irá relatar um erro de operação ilegal, conforme mostrado no seguinte exemplo:

# dtrace -w -n syscall::open:entry'{chill(500000001)}'
dtrace: allowing destructive actions
dtrace: description 'syscall::open:entry' matched 1 probe
dtrace: 57 errors
CPU     ID                    FUNCTION:NAME
dtrace: error on enabled probe ID 1 (ID 14: syscall::open:entry): \
  illegal operation in action #1

Esse limite é aplicado mesmo que o tempo seja distribuído entre várias chamadas para chill() ou vários consumidores de DTrace de um único teste. Por exemplo, o mesmo erro seria gerado pelo seguinte comando:

# dtrace -w -n syscall::open:entry'{chill(250000000); chill(250000001);}'