LINUX.ORG.RU

Странное поведение dd

 


0

2

Глюк, поломали или чего? Первый раз с таким сталкиваюсь. Привык я посматривать сколько он копирует так, как это в хелпе к dd описано

Sending a USR1 signal to a running 'dd' process makes it
print I/O statistics to standard error and then resume copying.

  $ dd if=/dev/zero of=/dev/null& pid=$!
  $ kill -USR1 $pid; sleep 1; kill $pid
  18335302+0 records in
  18335302+0 records out
  9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s

но чего-то не получается, похоже после & он просто спит.

 $ dd if=/dev/zero of=/dev/null& pid=$!
   [1] 3246
 $ kill -USR1 $pid; sleep 1; kill $pid
 $ 
[1]+  Terminated              dd if=/dev/zero of=/dev/null

Если dd на реальной операции что-то долго с диском делает, посылка kill -USR1 ничего не дает.

Что за глюки, впервые столкнулся с таким, даже не понимаю куда копать.

Вдобавок его ещё и по Ctrl+C не снять, а после Ctrl+C не снимается ни по kill, ни по kill -9

$ uname-a 
3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 GNU/Linux

$ dd --version
$ dd (coreutils) 8.21

Update:

Проблема решена. Дело было в том, что gdm3 блокирует SIGUSR, обновление до версии 3.12.2-4 избавляет от этого бага.

★★★★★

Последнее исправление: anonymous_incognito (всего исправлений: 3)

Ответ на: RTFM от anonymous

Во первых, в хелпе к самому dd всегда было -USR1 и это реально работало.

Во вторых, SIGUSR1 не помогает.

В третьих, какого-то хрена dd, если строго следовать примеру из его же хелпа, похоже, что отправляется в спячку после вызова.

В четвертых, его ещё и вообще прибить сложно. Внезапно устойчивый к Ctrl+C, kill и kill -9

Я даже не знаю, это dd виноват или каким-то боком это с systemd связано.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

В третьих, какого-то хрена dd, если строго следовать примеру из его же хелпа, похоже, что отправляется в спячку после вызова.

Тут я ошибся, в спячку не отправляется, но все остальные странности налицо.

anonymous_incognito ★★★★★
() автор топика

Может у тебя что-то с эмулятором терминала? Например, хитровычурные настройки PS1 съедают вывод от команды? Пробовал под strace запустить и поглазеть, чего он делает? Пробовал под gdb запустить и поглазеть, чего он по USR1 делает?

i-rinat ★★★★★
()
Ответ на: комментарий от reprimand

Запущенный от юзера снимается, если закрыть терминал (процесс) в котором он вызван. Если от рута, то переживает закрытие с TTY=?

Я с такими фокусами впервые сталкиваюсь, в принципе, так может себя вести процесс самого ядра, но не обычная же программа.

То ли проделки systemd, то ли dd бажный, то ли я даже не знаю чего ещё.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Может у тебя что-то с эмулятором терминала? Например, хитровычурные настройки PS1 съедают вывод от команды?

Ага! Похоже собака где-то рядом порылась. Я сейчас попробовал Ctrl+Alt+F1 и в текстовом терминале всё работает без странностей.

Блин гномоделы похоже нахимичили!

Признаться, я что-то как-то PS1 вообще не настраивал, просто меня обычно устраивало поведение и приглашение по умолчанию. Вот тут нет ли ереси?

$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

Вот тут нет ли ереси?

У меня с такой PS1 всё нормально работает.

Блин гномоделы похоже нахимичили!

А попробуй: unset COLORTERM, вдруг оно как-то влияет.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Понял, что точно тут гномоделы постарались и чего-то нахимичили.

Поставил нарочно xterm. Если запустить xterm из под гномотерминала - всё тоже самое. Если запустить xterm из под текстовой консоли

$xterm -display :0

То в таком терминале уже всё нормально работает. Мда-а. Понять бы ещё - это специфика gnome-terminal или вообще среда Gnome пакостит.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Ну они разные. А на что внимание обращать?

Вообще, не пойму причём тут env. Очень ведь похоже, что кто-то съедает сигналы для dd.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

Сейчас прогнал под strace. Очень интересно.

Под гномотерминалом SIGUSR просто не попадает в dd. Хотя если послать самому strace, то сам strace вываливается.

Под xterm SIGUSR нормально доходит до dd.

anonymous_incognito ★★★★★
() автор топика

используй цифры, а не мнемоники
kill -l

bl ★★★
()
Ответ на: комментарий от anonymous_incognito

если kill -9 не работает, это однозначно проблема в ядре

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Спасибо!

Обновился до gdm3 версии 3.12.2-4 и вроде заработало правильно. Хотя критиковать проще, чем делать, но решение гномеров из-за которого проблема возникла довольно сомнительное.

anonymous_incognito ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.