Ubuntu 16.04. Depois de jogar com algo novo (napp-it, um ZFS gui), estou tendo um problema onde o sudo trava após o prompt da senha. Strace relevante para o sudo segue ...
open("/dev/null", O_WRONLY|O_CREAT|O_APPEND, 0666) = 8
lseek(8, 0, SEEK_END) = 0
umask(022) = 077
fcntl(8, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_CUR, l_start=0, l_len=0}
Se eu rm / dev / null e recrio-o (apropriadamente com mknod e permissões apropriadas), o sudo roda bem. No entanto, isso só vale até uma reinicialização, quando o sudo trava novamente.
Editar ... devo acrescentar que, imediatamente após a reinicialização, as permissões em / dev / null aparecem corretas. ls -l / dev / null produz o seguinte (o mesmo que depois de excluí-lo e recriá-lo)
crw-rw-rw- 1 root root 1, 3 Feb 8 20:58 /dev/null
A saída de sudo -l indicou que o sudo logging estava sendo direcionado para / dev / null.
Um exame de / etc / sudoers mostrou as seguintes linhas.
## supress Console messages from sudo
Defaults logfile=/dev/null
Defaults !syslog
##
Não tenho certeza quando (ou por que) eles foram adicionados ao arquivo sudoers, mas comentá-los resolveu o problema.
Estou escrevendo um manipulador de syslog e estou matando o daemon syslog padrão. Aparentemente, pelo menos com base nesse strace, meu palpite é que as funções glibc syslog() parecem travar em uma chamada de sistema sendto() .
Eu estou sempre atordoado quando algo como esse núcleo funciona em um sistema faz algo assim. Talvez isso por design? Apenas parece uma má ideia.
read(9, "", 4096) = 0
close(9) = 0
munmap(0x7f461335d000, 4096) = 0
read(8, "", 4096) = 0
close(8) = 0
munmap(0x7f461335e000, 4096) = 0
socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
connect(8, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0
sendto(8, "<85>Sep 11 16:53:56 sudo: ro"..., 92, MSG_NOSIGNAL, NULL, 0
Então - se você tiver esse problema, verifique seu daemon syslog e veja se ele funciona, e /dev/log existe.
Tags sudo