Action par defaut de SIGALRM

rixed@apc.happyleptic.org wrote in message
<slrng88ltj.r5l.rixed@apc.happyleptic.org>:

- c'est normal ?

Probablement pas.

- je pourrais changer ce masque pour tout le système sans recompiler un kernel ?

Il vaudrait mieux commencer par trouver d'où ça vient. Donc essentiellement
regarder /proc/$PID/status pour tous les processus parents jusqu'à voir où
ça change.

2008-07-21, 09:29(+00), rixed@apc.happyleptic.org:

Bonjour !

J'ai un système GNU/Linux sur une archi ARM dont l'état par défaut
du signal SIGALRM semble être bloqué (vérifié en regardant dans
/proc/xxx/status).

Démonstration :

$ cat > toto.c
#include <stdlib.h>
int main(void) {
sleep(60);

[...]

Tu es sur que ton sleep(3) ne fait rien de dodgy avec ALRM?

Quelle version de Linux et libc?

Tu as essayé strace?

Et regardé /proc/1/status et /proc/$$/status?

--
Stéphane

On 2008-07-21, Nicolas George <nicolas$george@salle-s.org> wrote:

Il vaudrait mieux commencer par trouver d'où ça vient. Donc essentiellement
regarder /proc/$PID/status pour tous les processus parents jusqu'à voir où
ça change.

Facile :

$ grep SigBlk /proc/1/status
SigBlk: 0000000000002000

Donc init déjà présente ce défaut.

On 2008-07-21, Xavier <xavier@groumpf.org> wrote:

<rixed@apc.happyleptic.org> wrote:

- c'est normal ?

Probablement

Ah !?

D'après l'évangile selon Saint Stevens pourtant le comportemant par défaut
de SIGALRM serait de terminer le programme.

Il y a des macros autoconf qui comptent là dessus d'ailleurs.

Pour tout le système, je ne connais pas assez Linux pour ça, mais pour
une appli donnée, sigprocmask(2) ne ferait-il pas l'affaire ?

Si, cela fonctionne et je viens de recompiler ntpd comme ça. Mais je me
dis que ce ne sera pas toujours aussi simple à remarquer que pour ntpd.

Merci.

On 2008-07-21, Stephane CHAZELAS <stephane_chazelas@yahoo.fr> wrote:

Tu es sur que ton sleep(3) ne fait rien de dodgy avec ALRM?

J'ai fait des grep dans /proc/* et la grande majorité des process sont
dans le même état (en fait tous sauf ntpd, inetd et le VI ici présent).

Quelle version de Linux et libc?

linux 2.6.13-rc7, libc-2.3.6.so.

Tu as essayé strace?

Tient tiens, si je refait un programme toto qui sleep(1000), j'obtient
ceci :

execve("./toto", ["./toto"], [/* 31 vars */]) = 0
brk(0) = 0x11000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size4593, ...}) = 0
old_mmap(NULL, 34593, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "177ELF111a3(1Hl1004"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size‡83356, ...}) = 0
old_mmap(NULL, 1132872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0x40028000
mprotect(0x4012f000, 55624, PROT_NONE) = 0
old_mmap(0x40136000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x106000) = 0x40136000
old_mmap(0x4013b000, 6472, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4013b000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40016000
mprotect(0x40136000, 8192, PROT_READ) = 0
mprotect(0x4001d000, 4096, PROT_READ) = 0
munmap(0x4001f000, 34593) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [ALRM], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [ALRM], NULL, 8) = 0
nanosleep({1000, 0},

Il y a bien du code pour ignorer ALRM !
Et si je remplace le sleep par une boucle infinie je n'ai pas ces trois
rt_sig*(). Mais j'ai quand même le signal bloqué :

$ grep SigBlk `pidof toto`
SigBlk: 0000000000002000

Zarb.

rixed@happyleptic.org wrote in message
<slrng89ac1.8ro.rixed@apc.happyleptic.org>:

$ grep SigBlk /proc/1/status
SigBlk: 0000000000002000

Donc init déjà présente ce défaut.

Pas chez moi. Tu utilises quoi, comme init ?

On 2008-07-21, Nicolas George <nicolas$george@salle-s.org> wrote:

Donc init déjà présente ce défaut.

Pas chez moi. Tu utilises quoi, comme init ?

Heu... Celui qui était livré avec la machine :-)
strings me révèle ceci :

init 2.86 31-Jul-2004 miquels@cistron.nl