All perguntas(unix)

Desculpe se isso tiver uma resposta em outro lugar, não tenho ideia de como procurar meu problema.

Eu estava executando algumas simulações em um servidor HPC linux redhat, e meu código para manipular a estrutura de pastas para salvar a saída teve um erro infeliz. Meu código matlab para criar a pasta foi:

folder = [sp.saveLocation, 'run_', sp.run_number, '/'];

onde sp.run_numberera um número inteiro. Esqueci de convertê-lo em uma string, mas por algum motivo a execução mkdir(folder);(no matlab) ainda foi bem-sucedida. Na verdade, as simulações foram executadas sem problemas e os dados foram salvos no diretório correspondente.

Agora, quando a estrutura de pastas é consultada/impressa, recebo as seguintes situações:

• Quando tento tab autocomplete:run_ run_^A/ run_^B/ run_^C/ run_^D/ run_^E/ run_^F/ run_^G/ run_^H/ run_^I/
• Quando eu uso ls: run_ run_? run_? run_? run_? run_? run_? run_? run_? run_? run_?.
• Quando eu transfiro para o meu mac usando o rsync, a --progressopção mostra: run_\#003/etc. com (suponho) o número correspondente ao inteiro sp.run_numberpreenchido com três dígitos, então a 10ª execução érun_\#010/
• Quando vejo as pastas no localizador, vejorun_ run_ run_ run_ run_ run_ run_ run_ run_ run_?
• Olhando para esta pergunta e usando o comando ls | LC_ALL=C sed -n lrecebo:

run_$
run_\001$
run_\002$
run_\003$
run_\004$
run_\005$
run_\006$
run_\a$
run_\b$
run_\t$
run_$

Não consigo cdentrar nas pastas usando nenhuma dessas representações.

Eu tenho milhares dessas pastas, então vou precisar corrigir isso com um script. Qual destas opções é a representação correta da pasta? Como posso me referir programaticamente a essas pastas para renomeá-las com um nome formatado corretamente usando um script bash? E eu acho que por curiosidade, como diabos isso aconteceu em primeiro lugar?

Dado que o podman está instalado em um sistema linux e uma unidade systemd chamada baz.service:

# /etc/systemd/system/baz.service
[Service]
ExecStart=/usr/bin/podman run --rm --tty --name baz alpine sh -c 'while true; do date; sleep 1; done'
ExecStop=/usr/bin/podman stop baz

E o baz.service começou:

# systemctl daemon-reload
# systemctl start baz.service

Então, quando eu verifico o status da unidade, não vejo o shou sleepprocesso no cgroup /system.slice/baz.service

# systemctl status baz
● baz.service
   Loaded: loaded (/etc/systemd/system/baz.service; static; vendor preset: enabl
   Active: active (running) since Sat 2019-08-10 05:50:18 UTC; 14s ago
 Main PID: 16910 (podman)
    Tasks: 9
   Memory: 7.3M
      CPU: 68ms
   CGroup: /system.slice/baz.service
           └─16910 /usr/bin/podman run --rm --tty --name baz alpine sh -c while
# ...

Eu esperava ver o shand sleepchildren no meu status baz.service porque ouvi pessoas da redhat dizerem que o podman usa um modelo tradicional de fork-exec.

Se podman fizesse fork e exec, então my she sleepprocess não seriam filhos de podman e estariam no mesmo cgroup que o processo podman original?

Eu esperava poder usar o systemd e o podman para poder gerenciar meus contêineres sem que os filhos fossem para um pai diferente e escapassem da minha unidade ssystemd baz.service.

Olhando para a saída de pseu posso ver isso she sleepna verdade são filhos de um processo diferente chamado conmon. Não tenho certeza de onde veio o conmon ou como foi iniciado, mas o systemd não o capturou.

# ps -Heo user,pid,ppid,comm
# ...
root     17254     1   podman
root     17331     1   conmon
root     17345 17331     sh
root     17380 17345       sleep

A partir da saída, fica claro que minha unidade baz.service não está gerenciando a cadeia conmon -> sh -> sleep.

• Como o podman é diferente do modelo de servidor cliente do docker?
• Como o conmon do podman é diferente do containerd do docker?

Talvez ambos sejam tempos de execução de contêiner e o dockerddaemon seja o que as pessoas querem se livrar.

Então, talvez o docker seja como:

• daemon dockerd
• docker cli
• tempo de execução do contêiner containerd

E o podman é como:

• podman cli
• tempo de execução do contêiner comum

Então, talvez o podman use um modelo tradicional de fork exec, mas não é o podman cli que é bifurcação e exec, é o processo comum.

Eu me sinto confuso.

Abro um terminal xterm (80 colunas x 24 linhas), depois executo $ bash --norc --noprofilee, em seguida, $ ttypara obter o nome do arquivo do terminal: a saída é /dev/pts/9.

De outro terminal eu corro:

$ printf foo >/dev/pts/9

fooé impresso na linha de comando do shell no primeiro terminal.
Se eu pressionar C-upara executar unix-line-discard(nome da função dado por $ bind -P | grep -i c-u), foonão é removido.
Se eu inserir 11 espaços e pressionar C-u, os espaços serão removidos, mas não foo.
Se eu inserir 12 espaços e pressionar C-u, os espaços serão removidos assim como foo.

Por que não consigo remover fooquando pressiono C-uenquanto meu cursor está logo após e por que preciso inserir 12 caracteres para removê-lo?

Meio Ambiente:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:        16.04
Codename:       xenial

$ bash --version | head -n1
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)

$ xterm -version
XTerm(322)

Muitas vezes, especialmente ao mexer com carregadores de inicialização, vejo números numéricos de unidade e partição usados. Por exemplo, no meu /boot/grub/grub.cfgI see set root='hd0,gpt2', minhas entradas de inicialização UEFI geralmente fazem referência a números de unidade/partição e parece surgir em quase qualquer contexto em que os carregadores de inicialização estejam envolvidos.

Agora que temos UUID e PARTUUID, endereçar partições dessa maneira parece incrivelmente instável (afaik, não é garantido que as unidades sejam montadas sempre na mesma ordem, um usuário pode mover a ordem das unidades conectadas em sua mobo, etc.)

Minhas perguntas, portanto, são duas:

1. Esse esquema de endereçamento é tão instável quanto descrevi acima? Estou faltando algo no padrão que significa que esse esquema é muito mais confiável do que eu esperava, ou esse esquema de endereçamento realmente tornará seu sistema não inicializável (até que você corrija suas entradas de inicialização pelo menos) como resultado de suas unidades simplesmente serem reconhecidas em um ordem diferente ou conectá-los em slots diferentes na sua placa-mãe?

2. Se a resposta para a pergunta acima for sim, então por que esse esquema de endereçamento continua a ser usado? Usar UUID ou PARTUUID para tudo não seria muito mais estável e consistente?

Em sua página da web sobre o truque do tubo automático , Dan Bernstein explica uma condição de corrida select()e sinaliza, oferece uma solução alternativa e conclui que

Claro, a Coisa Certa seria ter fork()retornado um descritor de arquivo, não um ID de processo.

O que ele quer dizer com isso - é algo sobre poder select()nos processos filho manipular suas mudanças de estado em vez de ter que usar um manipulador de sinal para ser notificado dessas mudanças de estado?

Usando Bash,

Arquivo:

<?xml version="1.0" encoding="UTF-8"?>
<blah>
    <blah1 path="er" name="andy" remote="origin" branch="master" tag="true" />
    <blah1 path="er/er1" name="Roger" remote="origin" branch="childbranch" tag="true" />
    <blah1 path="er/er2" name="Steven" remote="origin" branch="master" tag="true" />

</blah>

Eu tentei o seguinte:

grep -i 'name="andy" remote="origin" branch=".*\"' <filename>

Mas ele retorna a linha inteira:

<blah1 path="er" name="andy" remote="origin" branch="master" tag="true" />

Eu gostaria de combinar a linha com base no seguinte:

name="andy"

Eu só quero que ele retorne:

master

Eu tentei atualizar meu sistema Debian usando apt, o repositório está configurado para "testing", então eu esperava que ele mudasse para a próxima versão "Bullseye" de "Buster" automaticamente, mas desde que "Buster" mudou, eu recebo:

404  Not Found [IP: 151.101.12.204 80]

ao correr apt update.

O security.debian.orgendereço não parece ter arquivos de lançamento, o endereço mudou?

E: The repository 'http://security.debian.org testing/updates Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

estas são as entradas relevantes do meu /etc/apt/sources.list:

deb http://ftp.ch.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ testing main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

# jessie-updates, previously known as 'volatile'
deb http://ftp.ch.debian.org/debian/ testing-updates main contrib non-free
deb-src http://ftp.ch.debian.org/debian/ testing-updates main contrib non-free

Verifiquei, man apt-securemas não consegui encontrar ou entender as informações relevantes.

Atualização: Eu tenho duas respostas até agora, ambas se referindo à página oficial do debian.org , mas sugiro uma solução completamente diferente. Alguém pode explicar, já que decidi não remover as security.debian.orgentradas, mas alterei o formato do atributo de versão.

Eu li sobre RNGs na Wikipedia e $RANDOMfunciono no TLDP , mas isso realmente não explica esse resultado:

$ max=$((6*3600))
$ for f in {1..100000}; do echo $(($RANDOM%max/3600)); done | sort | uniq -c
  21787 0
  22114 1
  21933 2
  12157 3
  10938 4
  11071 5

Por que os valores acima são cerca de 2x mais inclinados a serem 0, 1, 2 do que 3, 4, 5, mas quando eu mudo o módulo máximo, eles estão quase igualmente distribuídos por todos os 10 valores?

$ max=$((9*3600))
$ for f in {1..100000}; do echo $(($RANDOM%max/3600)); done | sort | uniq -c
  11940 0
  11199 1
  10898 2
  10945 3
  11239 4
  10928 5
  10875 6
  10759 7
  11217 8

O Linux Mint me diz que tenho apenas 622 MB de espaço livre em disco, mas deve haver alguns gigabytes restantes.

Olhando para as partições, me disseram que há cerca de dez gigabytes não utilizados. Pesquisei o problema no Google e não encontrei uma solução, mas encontrei a dica de que deveria verificar o uso do disco com df -h.

sudo df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p8  189G  178G  622M 100% /home

A saída não faz sentido para mim: a diferença entre Sizee Usedé de 11 GB, mas só aparece 622Mcomo Disponível.

O SSD não é antigo, então eu não esperaria tal discrepância.

O que devo fazer?

Eu gostaria de controlar o brilho da tela no i3 , em laptops Intel que vêm com teclas Fn para o efeito. Estas teclas funcionam com qualquer outro DE.

Primeiro, certifique-se de que os dispositivos disponíveis sejam Intel:

$ ls -l /sys/class/backlight/
total 0
lrwxrwxrwx 1 root root 0 juin  24 18:26 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight

Em outro fórum o programa xbacklighté sugerido como meio de controlar o brilho no i3 . No entanto, ele falha nos laptops que tentei até agora:

$ xbacklight -inc 10
No outputs have backlight property

Existe alguma outra maneira de controlar o brilho no i3 ?