Action par defaut de SIGALRM

Le
rixed
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);
return 0;
}
^D
$ gcc -o toto toto.c
$ toto&
$ cat /proc/`pidof toto`/status
Name: toto
State: S (sleeping)
SleepAVG: 87%
Tgid: 635
Pid: 635
PPid: 32072
TracerPid: 0
Uid: 1004 1004 1004 1004
Gid: 1005 1005 1005 1005
FDSize: 256
Groups: 1005
VmSize: 1300 kB
VmLck: 0 kB
VmRSS: 268 kB
VmData: 12 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 1140 kB
VmPTE: 6 kB
Threads: 1
SigQ: 0/1024
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000002000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

$ grep SIGALRM /usr/include/*/*.h
/usr/include/asm/signal.h:#define SIGALRM 14

C'est génant parceque du coup ntp{d,date} ne fonctionnent pas, de même que
certains tests d'autoconf

Savez vous si :

- c'est normal ?
- il y a une bonne raison à cela ?
- je pourrais changer ce masque pour tout le système sans recompiler un kernel ?

Merci !
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #16380391
wrote in message
- 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.
Stephane CHAZELAS
Le #16381821
2008-07-21, 09:29(+00), :
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 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
rixed
Le #16382391
On 2008-07-21, Nicolas George
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.
rixed
Le #16382381
On 2008-07-21, Xavier

- 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.
rixed
Le #16382531
On 2008-07-21, Stephane CHAZELAS
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.
Nicolas George
Le #16382641
wrote in message
$ grep SigBlk /proc/1/status
SigBlk: 0000000000002000

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



Pas chez moi. Tu utilises quoi, comme init ?
rixed
Le #16383421
On 2008-07-21, Nicolas George
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
Publicité
Poster une réponse
Anonyme