Existe uma maneira de executar systemctl daemon-reload no modo de recuperação. (Debian) Se sim, como?

Eu estava tentando mudar o ponto de montagem de uma das minhas unidades, então editei meu arquivo fstab para o local desejado. Então, tentei executar systemctl daemon-reload, mas não funcionou. Não consigo lembrar do erro que ele me deu, mas imaginei que se eu reiniciasse meu computador ele se consertaria sozinho...

GRANDE PROBLEMA

Depois que reiniciei, não consegui passar da tela de inicialização. A verificação do sistema de arquivos falharia naquela unidade, então eu ficaria preso em uma tela repetida. Entrei no modo de recuperação para descobrir qual é o problema e, pelo que entendi, simplesmente preciso executar o daemon-reload, mas como a única maneira de usar meu sistema é pelo modo de recuperação, não consigo executar o comando. Pelo que entendi, ele não será executado no modo de recuperação porque 1. Estou pedindo para ele reiniciar sozinho e ele não consegue fazer isso, ou 2. O systemd não está sendo executado no modo de recuperação.

2 é improvável para mim porque por que ele não estaria em execução, mas recebo o seguinte erro que me faz pensar que ele não está em execução.

Executando em chroot, ignorando o comando 'daemon-reload'

Então com sudo eu consigo um melhor

não é possível alocar pty: nenhum dispositivo desse tipo

Estou assumindo que o pty não existe no modo de recuperação, daí 2.

Meu entendimento do problema está correto? Alguém tem alguma sugestão sobre o que eu posso tentar fazer para executar o daemon-reload?

Tenho uma rede de máquinas Linux que são todas, para os propósitos do que estou fazendo, clones umas das outras. Há um nó "mestre" do qual todos os outros sincronizam um diretório em intervalos regulares usando rsync(revezando-se, não simultaneamente). Cada máquina tem seu rsyncdpróprio rsyncd.conf.

Minha rotina de sincronização faz com que cada nó cliente chame o rsynccliente assim:

$ rsync -a --delete masternode::syncdir/ /path/to/local/syncdir/

Observe que esta é uma conexão direta com o mestre rsyncd, não usando ssh.

Minha pergunta é: como já estou rsyncdexecutando em cada cliente, a operação de sincronização repetida seria mais eficiente invocando a instância local em vez de um caminho de arquivo como o argumento de destino? Ou seja

$ rsync -a --delete masternode::syncdir/ localhost::syncdir/

Nunca vi um exemplo de rsyncuso assim entre duas rsyncdinstâncias; não há nada que indique que não seja permitido/suportado, mas não tenho certeza de como (ou se) funcionaria nessa configuração de dois servidores mais um cliente mediando a operação entre eles.

Presumo que o tráfego ainda passe pelo processo do cliente (não que isso importe quando o servidor de destino é local), mas ambos os servidores " veem " um servidor na outra extremidade e fazem alguma eficiência de acordo, como aproveitar metadados de arquivo que eles podem ter armazenado em cache de execuções anteriores? (Ou isso acontece de qualquer maneira, independentemente de eles " saberem " que estão falando com outra instância do servidor?)

Esperando por uma resposta que possa aprofundar o " como ".

Vi outras respostas neste site, li um artigo e assisti a um vídeo sobre o assunto, mas ainda não consigo conectar meu namespace de rede ao mundo externo.

Configurar

Criei um namespace chamado "foo" e um par de vethinterfaces e movi uma para o namespace.

ip netns add foo
ip link add veth-foo type veth peer name veth-out
ip link set dev veth-foo netns foo

Atribuí um endereço IP a cada interface e verifiquei se ambas estavam ativas.

ip -n foo addr add 192.168.15.1 dev veth-foo
ip addr add 192.168.15.2 dev veth-out
ip -n foo link set dev veth-foo up
ip link set dev veth-out up

# Just in case, I made sure the loopback interfaces, too, are up, though they still show "UNKNOWN".
ip link set dev lo up
ip -n foo link set dev lo up 

Adicionei entradas às tabelas de roteamento dos namespaces global e "foo", para que eles possam se comunicar entre si.

ip route add 192.168.15.1 via 192.168.15.2
ip -n foo route add default via 192.168.15.1

Agora, posso alcançar "foo" do namespace global e o namespace global de "foo".

$ traceroute -n 192.168.15.1
traceroute to 192.168.15.1 (192.168.15.1), 30 hops max, 60 byte packets
 1  192.168.15.1  0.257 ms  0.209 ms  0.194 ms

$ ip netns exec foo traceroute -n 192.168.15.2
traceroute to 192.168.15.2 (192.168.15.2), 30 hops max, 60 byte packets
 1  192.168.15.2  0.046 ms  0.009 ms  0.008 ms

Também posso acessar a interface Ethernet que conecta a VM ao mundo externo de dentro de "foo".

# I ran this after I finished setting up IP forwarding, packet forwarding,
# and IP masquerading, so I'm not sure if it would work at this stage.
$ ip netns exec foo traceroute -n 10.0.2.15
traceroute to 10.0.2.15 (10.0.2.15), 30 hops max, 60 byte packets
 1  10.0.2.15  0.065 ms  0.010 ms  0.008 ms

Por fim, configurei o encaminhamento de IP, o encaminhamento de pacotes e o mascaramento de IP.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -o enp1s0 -i veth-out -j ACCEPT
iptables -A FORWARD -i enp1s0 -o veth-out -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.15.1/24 -o enp1s0 -j MASQUERADE

Como resultado, meu sistema fica assim:

$ sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0

$ iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 102 packets, 6816 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    enp1s0  192.168.15.0/24      anywhere

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:c3:cd:ac brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp1s0
       valid_lft 83383sec preferred_lft 83383sec
    inet6 fec0::11b8:4b3b:59ba:bae4/64 scope site dynamic noprefixroute 
       valid_lft 86026sec preferred_lft 14026sec
    inet6 fe80::f3fd:90f2:d15f:d570/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: veth-out@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:a2:13:05:c4:f5 brd ff:ff:ff:ff:ff:ff link-netns foo
    inet 192.168.15.2/32 scope global veth-out
       valid_lft forever preferred_lft forever
    inet6 fe80::d8a2:13ff:fe05:c4f5/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip -n foo addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
4: veth-foo@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:84:e6:16:92:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.15.1/32 scope global veth-foo
       valid_lft forever preferred_lft forever
    inet6 fe80::7c84:e6ff:fe16:928e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

$ ip route
default via 10.0.2.2 dev enp1s0 proto dhcp src 10.0.2.15 metric 100 
10.0.2.0/24 dev enp1s0 proto kernel scope link src 10.0.2.15 metric 100 
192.168.15.1 via 192.168.15.2 dev veth-out

$ ip -n foo route
default via 192.168.15.1 dev veth-foo

Testando

Neste ponto, espero conseguir alcançar o mundo exterior, mas não.

$ ip netns exec foo traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.15.1  3067.680 ms !H  3067.655 ms !H  3067.650 ms !H

$ sudo ip netns exec foo ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.15.1 icmp_seq=1 Destination Host Unreachable
From 192.168.15.1 icmp_seq=2 Destination Host Unreachable
From 192.168.15.1 icmp_seq=3 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2077ms

É claro que a própria VM está conectada à Internet.

$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.2.2  0.719 ms  0.691 ms  0.676 ms
 2  192.168.100.1  1.913 ms  2.593 ms  5.264 ms
 3  31.146.255.37  18.493 ms  18.740 ms  19.041 ms
 4  188.123.128.85  19.384 ms  19.658 ms  19.925 ms
 5  188.123.128.96  20.275 ms  21.787 ms 188.123.128.84  21.773 ms
 6  192.178.69.213  47.953 ms  53.145 ms  53.127 ms
 7  192.178.69.212  53.116 ms  51.893 ms 188.123.128.33  51.293 ms
 8  192.178.107.87  48.513 ms 192.178.107.135  43.582 ms 192.178.107.203  43.391 ms
 9  72.14.237.137  43.195 ms 8.8.8.8  43.207 ms  43.200 ms

$ ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=40.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=37.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=38.0 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 37.859/38.698/40.205/1.067 ms

Tcpdump

Aqui está a saída de tcpdump -n -i veth-out icmp. Ele capturou pacotes quando eu mirei 192.168.15.2& 10.0.2.15, mas não obteve nada quando eu mirei 8.8.8.8.

listening on veth-out, link-type EN10MB (Ethernet), snapshot length 262144 bytes

# This is the output when I ran `traceroute -n 192.168.15.2` (the address
# of "veth-out") in another terminal window (from inside "foo", of course).
12:44:19.172007 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port traceroute unreachable, length 68
12:44:19.172029 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port mtrace unreachable, length 68
12:44:19.172046 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33436 unreachable, length 68
12:44:19.172063 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33437 unreachable, length 68
12:44:19.172102 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33438 unreachable, length 68
12:44:19.172119 IP 192.168.15.2 > 192.168.15.1: ICMP 192.168.15.2 udp port 33439 unreachable, length 68

# And this is when I ran the same command but addressed 10.0.2.15 (the
# ethernet interface to the outside world).
12:44:35.305689 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port traceroute unreachable, length 68
12:44:35.305715 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port mtrace unreachable, length 68
12:44:35.305733 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33436 unreachable, length 68
12:44:35.305750 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33437 unreachable, length 68
12:44:35.305766 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33438 unreachable, length 68
12:44:35.305783 IP 10.0.2.15 > 192.168.15.1: ICMP 10.0.2.15 udp port 33439 unreachable, length 68
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

Nem capturou tcpdump -n -i lo icmpnenhum tcpdump -n -i enp1s0 icmppacote, independentemente do alvo de traceroute—sim, mesmo quando "foo" alcançou com sucesso a interface "enp1s0" (endereçada 10.0.2.15).

Informações do sistema

Isso foi feito dentro de uma VM (GNOME Boxes), no Fedora 41, versão do kernel 6.11.4-301.fc41.x86_64.

Minha máquina host também está executando o Fedora 41, embora o kernel esteja na versão 6.13.5-200.fc41.x86_64.

Edição: Só para garantir que isso fosse um problema do Fedora, testei em uma VM Mint e aconteceu exatamente a mesma coisa.

Recentemente, quando li um QA , ele apresentou alguns comportamentos inesperados para mim:

~/findtest % echo three > file\ with\ \"double\ quotes\"
~ % find findtest -type f -exec sh -c 'set -x;cat "{}"' \;
+ cat 'findtest/file with double' quotes
cat: findtest/file with double: No such file or directory
cat: quotes: No such file or directory

IMHO quando a substituição estiver concluída, ela funcionará 'cat findtest/file\ with\ \"double\ quotes\"'se apenas substituir o nome do arquivo acima, file\ with\ \"double\ quotes\"o que funcionará. Se mantivermos o wrapper de citação, ele mostrará:

$ cat "findtest/file\ with\ \"double\ quotes\""
cat: 'findtest/file\ with\ "double\ quotes"': No such file or directory

P:

O que essa substituição realmente faz, causando o comportamento um pouco estranho acima com 2 substr 'findtest/file with double' e 'quotes', mas não 'findtest/file with' e 'double quotes' "como delimitador?

Por que essa sintaxe entre colchetes funciona?

$ for (( i=0; i<3; ++i )) { echo $i; }
0
1
2

quando a página de manual diz que a sintaxe é

for (( expr1 ; expr2 ; expr3 )) ; do list ; done

$ bash --version | head -1   # on linux mint virginia (ubuntu jammy)
GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

Se esta é uma adição de sintaxe que ainda não foi documentada, quando foi adicionada?

Tenho lido muito conteúdo na web sobre os modos de suspensão, hibernação e suspensão de um computador, mas não encontrei nenhuma discussão sobre esta questão aparentemente simples:

Qual é a diferença, se houver, entre

1. apenas saindo de um computador Linux , executando, digamos, Ubuntu 22.4 LTS, mas realmente poderia ser qualquer distribuição e versão, e
2. invocando explicitamente o comando suspend , seja pela linha de comando ou por uma interface gráfica?

Ambos os casos devem permitir que você volte ao computador mais tarde, clique com o mouse ou digite uma tecla e "acorde-o".

Se há uma diferença, qual é? Se não há diferença, por que o comando suspend é necessário?

E, a propósito, existe um nome para "simplesmente ir embora"? É isso que "dormir" significa?

Vejo esses termos sendo usados ​​sem nenhuma definição precisa do que cada um significa.

Atualização: Por que estou perguntando isso?

A maioria do material que encontro em relação às diferentes formas de sono, suspensão ou hibernação do computador assume que a principal preocupação de qualquer um que pergunte é o consumo de energia. Essa não é minha preocupação.

Minha preocupação é que quando eu sair do computador, eu possa voltar a ele com segurança e não precise reiniciá-lo.

Minha preocupação é que comprei um laptop bem caro da Lenovo, com uma placa de vídeo nVidia (não vou entrar em detalhes técnicos aqui) da qual não posso me afastar e assumir com segurança que o sistema acordará quando eu voltar a ele e pressionar uma tecla ou clicar com o mouse. Às vezes funciona, às vezes não. Parece que invocar explicitamente a suspensão é um pouco mais confiável, não trava com tanta frequência, mas não é 100% confiável, talvez 90%. No meu computador anterior, um laptop Lenovo de 10 anos, eu não precisava me preocupar com nada disso.

Atualização 2: corrigindo o original para mencionar "livrar-se do Secure Boot no UEFI" em vez de "livrar-se do UEFI" como um pré-requisito para atingir a hibernação.

A hibernação se sugere como a maneira mais confiável de conseguir o que estou procurando, mas não está disponível no meu computador que usa Secure Boot sob UEFI. Então uma opção é desabilitar o Secure Boot. Eu estava relutante em fazer isso, mas parece ser o caminho que tenho que seguir.

Minha principal preocupação é a confiabilidade, não o consumo de energia.

Há um artigo de 2022 escrito por um cara que é um desenvolvedor sênior, e lá ele tem o seguinte alias em sua configuração zsh:

alias which='type -a'

Mas o zsh tem whichpor padrão, e se usarmos assim which, which cpa saída será

/bin/cp

Enquanto a saída de type -a cpé

cp is /bin/cp

A diferença é muito sutil para fazer um alias. Então, qual pode ser a diferença prática que eu negligenciei?

Mudei o prompt no meu .bashrc para mostrar o horário atual. Este era o prompt original (de uma instalação nova do MX Linux)

PS1="$PURPLE\u$nc@$CYAN\H$nc:$GREEN\w$nc\\n$GREEN\$$nc "

e eu mudei para isso

PS1="$PURPLE\u$nc@$CYAN\H$nc $YELLOW$(date '+%Y-%m-%d %H:%M:%S')$nc $REEN\w$nc\\n$GREEN\$$nc "

Quando abro um terminal, vejo a data e a hora atuais no prompt. Novos prompts não são exibidos com o horário em que foram gerados. Eles sempre mostram o mesmo horário do primeiro prompt. O que estou fazendo errado?

Estou trabalhando em um menu multinível e quero implementar a capacidade de submenus e sub-submenus retornarem ao menu anterior ou irem diretamente de volta ao menu principal. Veja abaixo...

[Menu]
1 - Option 1
2 - Option 2
3 - Quit (exit command)

Please choose option:

#Under Option 1
1 - Sub-Option 1
2 - Sub-Option 2
3 - back to main menu

#Under Sub-Option 1
1 - Sub-sub Option 1
2 - Sub-sub Option 2 
3 - back to Sub-option menu
4 - back to main menu 

Meu código atual mantém cada menu em uma função separada. Incluí meu menu Sub-Option abaixo...

suite_menu() {
    show_suite_menu

    read -p "Pick Number> " choice

    case $choice in

        1)  echo "1 selected."
            fullsuite_menu ;;
        2)  echo "2 selected."
            fullsuite_menu ;;
        3)  echo "3 selected."
            fullsuite_menu ;;
        0)  break;;
        *) echo "Invalid choice, please try again";;
    esac
}

Como eu poderia codificar meu sub-sub-menu de opções para ter a opção 3 indo para o menu acima, e a opção 0 indo para o menu principal? Obrigado antecipadamente <3

Para adicionar algo ao $PATH em fish, eu uso

fish_add_path -a ~/foo/bar

Então o peixe acrescenta ~/foo/barao meu ~/.config/fish/fish_variables:

SETUVAR fish_user_paths:/Users/john/foo/bar

Então, é correto dizer que para remover /Users/john/foo/barde $PATH, tenho duas opções:

• para editar o fish_variablesarquivo

• para usar a seguinte função:

  // https://github.com/fish-shell/fish-shell/issues/8604#issuecomment-1169638533
  function remove_path
    if set -l index (contains -i "$argv" $fish_user_paths)
      set -e fish_user_paths[$index]
      echo "Removed $argv from the path"
    end
  end
  

E a segunda parte da pergunta: Como usar corretamente essa função? Eu salvei como remove_from_path.fish, executei como remove_from_path.fish "/Users/john/foo/bar", mas ela não parece remover /Users/john/foo/barde $PATH. O que estou fazendo errado?