sudo를 사용한 Bash 스크립트 - 신뢰할 수 없는 백그라운드 복구(bg)

test.sh루트 디렉터리의 디스크 사용량을 표시하는 다음 과 같은 간단한 bash 스크립트( 라고 함)가 있습니다 . sudo모든 디렉토리가 나열되어야 합니다(그리고 sudo비밀번호를 입력할 필요가 없습니다).

#!/bin/bash
sudo du -h --max-depth=1 / 2> /dev/null

디렉터리가 내 경로에 있고 다음과 같은 스크립트를 실행합니다(출력을 텍스트 파일로 출력하기 위해).

$ ./test.sh >> ./test.txt

Ctrl이제 +pause로 작업하면 다음과 같은 결과를 Z얻습니다.

^Z
[1]+  Stopped                 ./test.sh >> ./test.txt

그런 다음 백그라운드에서 다시 시작하면 다음과 같은 결과 bg가 나타납니다.

$ bg
[1]+ ./test.sh >> ./test.txt &

[1]+  Stopped                 ./test.sh >> ./test.txt

$ jobs
[1]+  Stopped                 ./test.sh >> ./test.txt

(추가 시도로 bg인해 실제로 2~3회 시도 후 백그라운드에서 스크립트가 다시 시작될 수 있지만 이는 산발적인 것 같습니다...)

그러나 continue 를 사용하면 fg스크립트가 포그라운드에서 실행됩니다.

$ fg
./test.sh >> ./test.txt

결과는 다음과 같이 작성됩니다 test.txt.

3.8M    /root
4.0K    /authentic-theme
4.0K    /srv
72K     /tmp
3.2G    /snap
4.0K    /media
8.4M    /etc
0       /proc
0       /sys
4.0K    /cdrom
16K     /opt
16K     /lost+found
24K     /dev
4.3M    /run
263G    /mnt
14M     /home
19G     /var
245M    /boot
3.8G    /usr
297G    /

스크립트를 다음과 같이 수정하면아니요sudo대신 run 스크립트를 사용하면 Normal sudo을 사용하여 백그라운드로 다시 시작 bg하고 스크립트를 실행할 수 있습니다.

$ sudo ./test.sh >> ./test.txt 
^Z
[1]+  Stopped                 sudo ./test.sh >> ./test.txt

$ bg
[1]+ sudo ./test.sh >> ./test.txt &

$ jobs
[1]+  Running                 sudo ./test.sh >> ./test.txt &

다음을 사용하여 전체 명령을 실행하면 sudo동일한 일이 발생합니다 .

$ sudo du -h --max-depth=1 / 2> /dev/null >> ./test.txt
^Z
[1]+  Stopped                 sudo du -h --max-depth=1 / 2> /dev/null >> ./test.txt

$ bg
[1]+ sudo du -h --max-depth=1 / 2> /dev/null >> ./test.txt &

$ jobs
[1]+  Running                 sudo du -h --max-depth=1 / 2> /dev/null >> ./test.txt &

무슨 일인지 설명해 줄 수 있는 사람 있나요? sudo명령과 스크립트를 사용하여 백그라운드에서 재개할 수 있는데 스크립트에 정확히 동일한 명령을 사용하는 명령이 포함되어 있으면 sudo백그라운드 재개가 bg분명히 작동하지 않는 이유는 무엇입니까 ?

저는 Ubuntu 22.04.1을 사용하고 있으며 기본 Bash 버전은 5.1.16입니다.

편집 #1:명령이 다른 별칭을 alias sudo='sudo '사용할 수 있도록 설정했다는 알림을 받을 수 있습니다 . sudo그러나 이 별칭을 사용하거나 사용하지 않고 테스트한 결과 bg모든 경우에 동일한 불규칙한 복구 동작이 나타났습니다. *

편집 #2: jobs -l다음과 같은 일반적인 정보를 제공합니다.

jobs -l
[1]+ 1074808 Stopped                 ./test.sh >> ./test.txt

편집 #3:나는 보통 에서 실행 tmux하지만 없이도 테스트했는데 tmux문제가 지속됩니다.

편집 #4:SuperMicro 서버 외에도 노트북(Aorus X5)에서 테스트하기 위한 Raspberry Pi와 Ubuntu VM도 있습니다. 이건 정말 이상해요:

• 내 Ubuntu VM(Windows 10의 VMWare)에 이 문제가 있습니다.확실히모두에게 일어납니다. 모든 경우에 bg처음에는 올바르게 복구됩니다.
• 내 Raspberry Pi에서 문제가 지속됩니다. 일반적으로 bg올바르게 복구하려면 2-3번의 시도가 필요합니다.

가상 머신이 아닌 메인 서버와 Raspberry Pi에서 실행되는 소프트웨어를 테스트해야 한다는 생각이 들기 시작했습니다.

편집 #5:stty -tostop불행히도 스크립트를 실행하기 전에 설정해도 실제로 문제가 해결되지는 않습니다. 대부분의 경우 올바르게 복구하려면 여전히 2~3번의 시도가 필요합니다. 첫 시도에 성공했던 경우도 몇 번 있었지만, 그 어떤 것보다 좋은 기회라고 생각해요.

편집 #6:내 Raspberry Pi에서 실행되는 서비스는 다음과 같습니다.

$ systemctl --type=service --state=running
  UNIT                             LOAD   ACTIVE SUB     DESCRIPTION                                            
  atd.service                      loaded active running Deferred execution scheduler
  containerd.service               loaded active running containerd container runtime
  cron.service                     loaded active running Regular background program processing daemon
  dbus.service                     loaded active running D-Bus System Message Bus
  docker.service                   loaded active running Docker Application Container Engine
  [email protected]               loaded active running Getty on tty1
  irqbalance.service               loaded active running irqbalance daemon
  ModemManager.service             loaded active running Modem Manager
  networkd-dispatcher.service      loaded active running Dispatcher daemon for systemd-networkd
  packagekit.service               loaded active running PackageKit Daemon
  polkit.service                   loaded active running Authorization Manager
  prometheus-node-exporter.service loaded active running Prometheus exporter for machine metrics
  rsyslog.service                  loaded active running System Logging Service
  [email protected]       loaded active running Serial Getty on ttyS0
  smartmontools.service            loaded active running Self Monitoring and Reporting Technology (SMART) Daemon
  snapd.service                    loaded active running Snap Daemon
  ssh.service                      loaded active running OpenBSD Secure Shell server
  systemd-journald.service         loaded active running Journal Service
  systemd-logind.service           loaded active running User Login Management
  systemd-networkd.service         loaded active running Network Configuration
  systemd-timesyncd.service        loaded active running Network Time Synchronization
  systemd-udevd.service            loaded active running Rule-based Manager for Device Events and Files
  udisks2.service                  loaded active running Disk Manager
  unattended-upgrades.service      loaded active running Unattended Upgrades Shutdown
  unbound.service                  loaded active running Unbound DNS server
  [email protected]                loaded active running User Manager for UID 1000

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
26 loaded units listed.

나는 이것이 내가 설치하고 활성화한 것이라고 생각합니다(그리고 SuperMicro 및 Raspberry Pi에서 실행):

  containerd.service               loaded active running containerd container runtime
  docker.service                   loaded active running Docker Application Container Engine
  prometheus-node-exporter.service loaded active running Prometheus exporter for machine metrics
  smartmontools.service            loaded active running Self Monitoring and Reporting Technology (SMART) Daemon
  unbound.service                  loaded active running Unbound DNS server

테스트할 사항:

• sudo구성을 확인 하여 NOPASSWD영향이 있는지 확인하세요.
• SuperMicro 서버와 Raspberry Pi 간에 공통으로 설치된 서비스를 비활성화합니다.