o controle de trabalho não funciona quando tento configurar o getty via serial

Não são os comandos, mas o ambiente em que eles são executados que faz a diferença.

Normalmente getty é gerado diretamente do gerenciador de serviços do sistema (init) - tanto no systemd, onde é um .service, quanto no mundo SysV, onde possui uma entrada inittab (e não um script init.d!). Isso tem várias diferenças em relação a ser gerado em outro terminal.

Principalmente, um processo iniciado a partir de um terminal o herda como seu terminal de controle, que é o parâmetro mais importante para o controle do shell job. Você pode ver isso em ps auxor ps -ef– os processos de serviço não têm ctty inicialmente, então quando getty abre o terminal indicado, ele se torna seu terminal de controle para controle de trabalho assim que o shell for executado. Mas um getty que foi iniciado a partir do seu xterm continuará a ter esse xterm pty como seu controlador tty, apesar de sua entrada/saída agora ser roteada para a porta serial.

$ ps -C agetty
  PID TTY          TIME CMD
 1136 tty1     00:00:00 agetty
14022 pts/22   00:00:00 agetty
      ^-- should be ttyS0!

O terminal de controle define /dev/tty; define para quais processos os sinais de controle de trabalho são enviados; ele define quais processos são eliminados (SIGHUP'd) quando o terminal fecha. Se o seu shell herdou um tty de controle diferente do tty stdin/out, todos os tipos de coisas estranhas podem acontecer.

Existem maneiras pelas quais um processo pode se desconectar de seu terminal anterior, como chamar setsid(), mas o getty não as utiliza automaticamente porque não espera ser executado dessa maneira. (Existe uma setsidferramenta que pode ser usada, mas você também não deveria usá-la aqui.)

Idealmente, você deve apenas systemctl start serial-getty@ttyAMA0deixar o getty rodar em um ambiente limpo. Se forem necessárias opções personalizadas, edite esse serviço usando o 'systemctl edit' normal, mas nunca execute o getty diretamente. (Se o systemd não for usado, edite /etc/inittab; geralmente inclui um exemplo.)

Existem muitas outras diferenças relativamente pequenas entre processos iniciados a partir de um shell e através de um gerenciador de serviços:

• O processo herdará seu terminal como stdin/stdout/err. O Getty simplesmente os fechará e reabrirá para o que for necessário, mas muitos outros programas não o farão, e eu até vi serviços que mudam o comportamento com base nisso (... sem nenhuma boa razão, mas ainda assim).

• O processo herdará diversas variáveis ​​de ambiente que podem ser relevantes ou inúteis. Por exemplo, porque você iniciou via sudo, ele terá SUDO_USER em seu ambiente (e algumas ferramentas realmente mudam seu comportamento quando veem que estão sendo chamadas via sudo).

• O processo herdará seu contexto SELinux, se houver (por exemplo, no Fedora/RHEL), e poderá não ser permitido alterá-lo novamente. Ele também herda coisas como "uid de login" encontrado em /proc/PID/loginuid e não pode ser redefinido depois de definido (sendo usado para registro de auditoria). Em certas distribuições, também pode herdar perfis AppArmor, rótulos SMACK, etc.

• O processo estará em seu cgroup de "usuário" original, mesmo que um usuário diferente efetue login. Systemd-logind adiciona um conceito de "sessões de usuário" ao Linux e as baseia em cgroups do Linux: quando um processo de serviço, como sshd ou agetty, processa seu login através do PAM, ele se registra no systemd-logind e é movido de seu cgroup de "serviço" para um cgroup de "usuário", como user-1002.slice. No entanto, um processo que já é executado dentro de um cgroup de "usuário" não tem permissão para fazer o mesmo novamente - mesmo que tenha privilégios de root.

Tudo isso para dizer que existem muitas diferenças invisíveis e que no Linux você não deve iniciar serviços via sudo como prática geral; especialmente serviços que aceitam logins de usuários.