frankfalse's questions

Meu problema é decodificar a saída do comando file -s /dev/sdXno meu sistema (onde /dev/sdXestá o arquivo de dispositivo associado a uma chave USB).
Abaixo, mostrarei a saída do comando file -s /dev/sdXem que o arquivo de dispositivo /dev/sda1é uma partição formatada com um FAT32sistema de arquivos, enquanto o dispositivo /dev/sdbé uma partição formatada com um NTFSsistema de arquivos.

Saída de filecomando para um FAT32sistema de arquivos

No caso do FAT32sistema de arquivos, a saída do filecomando é:

> file -s /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 31, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1920, reserved 0x1, serial number 0x4ba3ff5b, unlabeled

Na saída está presente a informação , FAT (32 bit), sectors/FAT 1920,que poderia ser suficiente para dizer que o tipo de sistema de arquivos é FAT32, mas no próximo parágrafo mostrarei que a string FATtambém está presente na saída do filecomando no caso de um NTFSsistema de arquivos.

Saída de filecomando para um NTFSsistema de arquivos

No caso de um NTFSsistema de arquivos, a saída do filecomando é:

> file -s /dev/sdb 
/dev/sdb: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 15654911, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 030fcd5a9fcd56a1c; contains bootstrap BOOTMGR

Nesta saída está presente a informação, ; NTFS,mas também está presente a string FAT.

A questão

A partir das saídas anteriores do file -scomando, como determinar o sistema de arquivos das duas partições com certeza?

EDITAR
Adiciono a saída do file -scomando para uma exfatpartição e para uma ext4partição.

Saída de fileparaexfat

> file -s /dev/sdf
/dev/sdf: DOS/MBR boot sector

Neste caso exfatnão está presente na saída.

Saída de fileparaext4

file -s /dev/sdb1
/dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=38bc3d5b-381e-4f19-8640-c77d9483882b (needs journal recovery) (extents) (64bit) (large files) (huge files)

Neste caso está presente a informação ext4 filesystem data,.

Nestes 4 exemplos (FAT32, NTFS, EXFAT, EXT4), a saída do filecomando parece muito diferente para diferentes tipos de sistema de arquivos, por isso é difícil encontrar uma regra simples para decidir o tipo de sistema de arquivos por essa saída.

Preciso montar um pendrive antigo formatado com o sistema de arquivos FAT. A montagem deve ser executada automaticamente por uma udevregra que execute um script bash.

Quando a chave USB é inserida na porta USB, o script executa o comando:

blkid -o udev /dev/sda1 

onde /dev/sda1está a partição presente dentro do USB e formatada com o sistema de arquivos FAT32. A saída do comando anterior para o pendrive está vazia .

A saída do mesmo comando ( blkid) para outras chaves USB contém a udevvariável ID_FS_TYPE; os valores possíveis ID_FS_TYPEsão: vfat, ntfs, exfat.

Diferentes opções de mountcomando se o sistema de arquivos forvfat

Se o valor da variável ID_FS_TYPEfor vfato script deve executar o seguinte mountcomando:

> mount -o rw,relatime,users,gid=100,umask=000,shortname=mixed,utf8=1,flush /dev/sda1 /mount/point

Enquanto que se o sistema de arquivos não estiver, vfatas opções para o mountcomando podem ser as seguintes:

mount -o rw,relatime /dev/sda1 /mount/point

Com a chave USB específica (1 GB e muito antiga), o script não consegue saber qual é o tipo de sistema de arquivos, vfatentão ele executa o segundo mountcomando; o resultado é que as permissões para o diretório do ponto de montagem (chamado /media/sda1) são:

> ls -l /media/    
total 16
drwxr-xr-x 3 root root 16384 Jan  1  1970 sda1

enquanto eu preciso:

# ls -l /media/    
total 16
drwxrwxrwx 3 root root 16384 Jan  1  1970 sda1

Preciso dessas permissões porque todos os usuários devem poder escrever no USB e não apenas o proprietário (que é rooto meu contexto).

Encontre o tipo de sistema de arquivo por outros comandos

Este link dá outras dicas para descobrir o tipo de sistema de arquivos deste pendrive específico. Então, tentei outros comandos:

• lsblk -n -o FSTYPE /dev/sda1: também neste caso, para minha chave USB específica, a saída do comando está vazia
• a saída do comando file -sL /dev/sda1é muito longa; mostro esta saída abaixo:

> file -sL /dev/sda1
/dev/sda1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "MSDOS5.0", sectors/cluster 32, reserved sectors 8, root entries 512, Media descriptor 0xf8, sectors/FAT 240, sectors/track 63, heads 255, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), reserved 0x1, serial number 0xa4906b9d, unlabeled, FAT (16 bit)

Nesta saída, a informação está presente FAT (16 bit), mas não fica claro se o sistema de arquivos da partição do pendrive está formatado vfat. Se eu executar o comando anterior file -sLem um pendrive formatado com o sistema de arquivos NTFS, a saída do comando será:

> file -sL /dev/sda
/dev/sda: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 15654911, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 030fcd5a9fcd56a1c; contains bootstrap BOOTMGR

Nesta saída está presente a string NTFS, mas também está presente a string FAT, então com esta saída não é fácil estabelecer se o sistema de arquivos é vfate não ntfs.

A questão

Existe algum comando além dos anteriores que possa fornecer o sistema de arquivos de uma partição antes de montá-la?

Para habilitar a montagem de uma chave USB formatada com sistema de arquivos, ntfscriei o seguinte fragment.cfgarquivo:

CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

e compilei o kernel com o comando:

bitbake -C compile virtual/kernel

Com essa modificação na configuração do kernel minha distribuição consegue executar a montagem de um ntfsUSB pelo comando:

> mount /dev/sda /media/sda

onde /dev/sdaestá o dispositivo associado à chave USB e /media/sdaé o ponto de montagem.

O sistema de arquivos é montado, mas somente leitura. Isso é mostrado pelo comando a seguir:

# mount | grep media
/dev/sda on /media/sda type ntfs (ro,relatime,uid=0,gid=0,fmask=0177,dmask=077,nls=iso8859-1,errors=continue,mft_zone_multiplier=1)

No arquivo de fragmento que configurei CONFIG_NTFS_RW=y, então por que o ntfssistema de arquivos de uma chave USB é montado somente leitura?

EDITAR

Se eu executar o comando dmesgobtenho a seguinte mensagem:

> dmesg
...
(device sda): load_system_files(): Volume is dirty.  Mounting read-only.  Run chkdsk and mount in Windows.

Eu segui as informações escritas na mensagem anterior:

• Eu inseri o USB em um sistema Windows
• O sistema Windows executou um scanfix do USB

Depois disso executei corretamente a montagem R/W do USB no meu sistema Linux:

> mount -t ntfs /dev/sda /media/sda
> mount | grep media
/dev/sda on /media/sda type ntfs (rw,relatime,uid=0,gid=0,fmask=0177,dmask=077,nls=iso8859-1,errors=continue,mft_zone_multiplier=1)

Neste ponto, se eu tentar escrever no USB, recebo o seguinte erro:

> touch /media/sda/write_ntfs.txt
touch: cannot touch '/media/sda/write_ntfs.txt': Permission denied

O mesmo se eu tentar alterar a permissão de um arquivo presente no USB:

> chmod 777 /media/sda/filename.csv
chmod: changing permissions of '/media/sda/filename.csv': Operation not supported

Então, apesar da saída do comando mount, parece que a montagem do USB ainda é somente leitura!

Na minha distribuição Yocto não consigo montar a chave USB com exfato sistema de arquivos.

Se eu executar o comando:

> blkid /dev/sda         
/dev/sda: LABEL="my-label" UUID="FC4D-5949" BLOCK_SIZE="512" TYPE="exfat"

Então tenho certeza que o sistema de arquivos USB é exfat, mas quando tento executar o mountcomando recebo o seguinte erro:

> mount /dev/sda /media
mount: /media: unknown filesystem type 'exfat'.

Se eu executar o comando cat /proc/filesystems( aqui encontrei o catcomando), a lista de sistemas de arquivos suportados é:

> cat /proc/filesystems 
nodev   sysfs
nodev   tmpfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   cgroup2
nodev   cpuset
nodev   devtmpfs
nodev   debugfs
nodev   tracefs
nodev   securityfs
nodev   sockfs
nodev   bpf
nodev   pipefs
nodev   ramfs
nodev   hugetlbfs
nodev   rpc_pipefs
nodev   devpts
        ext3
        ext2
        ext4
        vfat
        msdos
        iso9660
nodev   nfs
nodev   nfs4
nodev   cifs
nodev   smb3
nodev   autofs
nodev   overlay
nodev   efivarfs
nodev   mqueue
        btrfs

exfatestá faltando.

Alguém poderia me explicar como posso montar um exfatUSB na minha distribuição yocto?

Meu serviço atual e script de shell

Eu tenho um arquivo de serviço systemd chamado myservice.service. O serviço é iniciado na inicialização. O serviço inicia o script de shell /usr/bin/myscript.shcomo você pode ver abaixo na seção [Service]:

...
[Service]
Type=forking
ExecStart=/usr/bin/myscript.sh
PIDFile=/dev/shm/myscript.pid
...

O conteúdo do script é:

#!/bin/sh
/usr/bin/script-python.py > /dev/null &
echo $! > /dev/shm/myscript.pid

O script shell myscript.shinicia o script Python: script-python.py. Pelo redirecionamento, > /dev/nulla saída padrão de script-python.pyé enviada para /dev/nulle, portanto, é perdida.

Alterações para usar Service->StandardOutput=null

Na documentação do systemd do StandardOutput li a seguinte frase:

null conecta a saída padrão a /dev/null, ou seja, tudo escrito nele será perdido.

Então estou pensando em executar as seguintes alterações nos meus arquivos:

1. myservice.servicetorna-se (adicionar StandardOutput=null):

...
[Service]
Type=forking
ExecStart=/usr/bin/myscript.sh
PIDFile=/dev/shm/myscript.pid
StandardOutput=null
...

2. myscript.shtorna-se (remover >/dev/null):

#!/bin/sh
/usr/bin/script-python.py &
echo $! > /dev/shm/myscript.pid

Minha pergunta

Minha pergunta é: se eu fizer as modificações mostradas acima o resultado é exatamente o mesmo da minha situação atual: todas as saídas de script-python.pysão perdidas? Não há nenhuma diferença?

Estou usando o yocto para construir minha distribuição Linux personalizada. Preciso adicionar hiredisà minha distribuição. Hiredis é uma biblioteca cliente C minimalista para o banco de dados Redis e preciso dela para acessar o Redis por meio de um aplicativo C.

A receitahiredis_0.14.0.bb

No meu sistema de compilação yocto há a receita hiredis_0.14.0.bbarmazenada na pasta meta-openembedded/meta-oe/recipes-extended/hiredise na meta camada meta-openembedded.

O conteúdo da receita é o seguinte:

DESCRIPTION = "Minimalistic C client library for Redis"
HOMEPAGE = "http://github.com/redis/hiredis"
LICENSE = "BSD-3-Clause"
SECTION = "libs"
DEPENDS = "redis"

LIC_FILES_CHKSUM = "file://COPYING;md5=d84d659a35c666d23233e54503aaea51"
SRCREV = "685030652cd98c5414ce554ff5b356dfe8437870"
SRC_URI = "git://github.com/redis/hiredis;protocol=git \
           file://0001-Makefile-remove-hardcoding-of-CC.patch"

S = "${WORKDIR}/git"

inherit autotools-brokensep pkgconfig

EXTRA_OEMAKE = "PREFIX=${prefix} LIBRARY_PATH=${baselib}"

# By default INSTALL variable in Makefile is equal to 'cp -a', which preserves
# ownership and causes host-user-contamination QA issue.
# And PREFIX defaults to /usr/local.
do_install_prepend() {
  export INSTALL='cp -r'
}

O Git Fetcher baixa a versão 0.14.0do Hiretedis

Se eu executar o comando:

> bitbake hiredis

o hirediscódigo é obtido pelo GitHub e compilado corretamente. A versão no código baixado do GitHub é a 0.14.0, enquanto está SRC_URIdefinida como:

SRC_URI = "git://github.com/redis/hiredis;protocol=git \
           file://0001-Makefile-remove-hardcoding-of-CC.patch"

Este valor SRC_URIsignifica que está usando o Git Fetcher e não há parâmetros especificados branchou reve isso significa que os valores desses parâmetros são master.

A única referência à versão 0.14.0está no nome da receita (hiredis_ 0.14.0.bb) então escolhe-se a versão 0.14.0porque o valor da PVvariável é 0.14.0(o PVvalor é definido pelo nome da receita).

Minha pergunta

Por que a versão buscada da biblioteca Hiretedis é 0.14.0e não a mais recente?

Estou usando 3 perfis de conexão NetworkManager em uma distribuição Linux e todos os perfis de conexão referem-se à mesma interface Ethernet: enp3s0. Estou usando essas conexões para gerenciar:

• a configuração de IP estático padrão
• definir uma nova configuração de IP estático
• solicitar um endereço DHCP

No restante da pergunta usarei o termo connection para significar o termo connection profile .

Para alterar a configuração Ethernet, altero a prioridade da conexão, portanto, se eu quiser ativar a configuração de IP estático padrão, defino uma prioridade maior que a configuração de IP estático e a configuração de DHCP.
Leia o parágrafo “Definir propriedades das 3 conexões” na continuação da pergunta para obter detalhes sobre a configuração da prioridade de uma conexão.

A questão

Se eu criar conexões na inicialização por um script bash iniciado por um systemdserviço, tudo funcionará corretamente, mas se eu executar o script bash após a conclusão da inicialização, a configuração IP não será gerenciada corretamente pelo NetworkManager e seus perfis de conexão. Vá para o parágrafo “O problema” no final da pergunta para obter uma descrição detalhada do erro.

O restante da pergunta fornece todos os detalhes necessários para entender o problema.
Peço desculpas pela extensão da pergunta, mas há muitas informações necessárias.

Criação de 3 perfis de conexão NetworkManager

Para criar as conexões estou utilizando o comando nmcliconforme mostrado abaixo:

# for default static
nmcli c add ifname enp3s0 type ethernet con-name ethernet_default_ipstatic
# for ethernet_ipstatic
nmcli c add ifname enp3s0 type ethernet con-name ethernet_ipstatic
# for ethernet_dhcp
nmcli c add ifname enp3s0 type ethernet con-name ethernet_dhcp

Após a execução dos comandos anteriores no caminho /etc/NetworkManager/system-connections, estarão presentes 3 arquivos chamados:

• ethernet_default_ipstatic.nmconnection
• ethernet_ipstatic.nmconnection
• ethernet_dhcp.nmconnection

Defina as propriedades das 3 conexões

Os comandos anteriores criam 3 conexões com propriedades padrão, portanto após criá-las é necessário definir suas propriedades. Para esse objetivo ainda utilizei o comando nmcliconforme mostrado abaixo.

Para ethernet_default_ipstaticdefinir as seguintes propriedades para a conexão:

nmcli con mod ethernet_default_ipstatic ipv4.method manual ipv4.addresses 192.168.1.1/24 ipv6.method disabled

O comando anterior definiu as seguintes propriedades para a conexão:

• ipv4.method = manual (este conjunto IP estático e não DHCP)
• endereço IP 192.168.1.1, máscara de rede 255.255.255.0 (sem gateway)
• IPV6 desativado
• a propriedade de conexão automática permanece como padrão sim
• a propriedade de prioridade permanece com o padrão 0

Para as ethernet_ipstaticpropriedades são:

nmcli con mod ethernet_ipstatic ipv4.method manual ipv4.addresses 192.168.1.1/24 ipv4.gateway 192.168.1.100 ipv4.may-fail no ipv6.method disabled connection.autoconnect no connection.autoconnect-priority -1

O comando anterior definiu as seguintes propriedades para a conexão:

• ipv4.method = manual (este conjunto IP estático e não DHCP)
• endereço IP 192.168.1.1, máscara de rede 255.255.255.0, gateway 192.168.1.100
• IPV6 desativado, conexão automática não, prioridade -1

Para as ethernet_dhcppropriedades são:

nmcli con mod ethernet_dhcp ipv4.method auto ipv4.addresses '' ipv4.gateway '' ipv4.may-fail no ipv4.dhcp-timeout 20 ipv6.method disabled connection.autoconnect no connection.autoconnect-priority -1 connection.autoconnect-retries 3

O comando anterior definiu as seguintes propriedades para a conexão:

• ipv4.method = auto (este conjunto DHCP e não endereço IP estático)
• endereço IP '', gateway ''
• IPV6 desativado, conexão automática não, prioridade -1

Configuração padrão

Pelos comandos anteriores a conexão ethernet_default_ipstatictem prioridade sobre as demais portanto a interface ethernet enp3s0é configurada com um IP estático 192.168.1.1/24.

Execução de nmclicomandos por um serviço

Todos funcionam corretamente se eu executar nmclicomandos anteriores na inicialização pelo seguinte serviço ( my_custom_nm_service.service):

[Unit]
Description=Init NetworkManager Ethernet Connections
Requires=NetworkManager.service
After=NetworkManager.service
Before=network.target

[Service]
Type=oneshot
ExecStart=/home/<username>/script_services/init_connections.sh
User=<username>

[Install]
WantedBy=multi-user.target

onde init_connections.shexecuta comandos anteriores nmcli.

Observação. No arquivo da unidade observe a presença das opções:

• Requer=NetworkManager.service
• Depois=NetworkManager.service
• Antes = rede.target

O problema

Se após o término do boot eu remover todas as conexões, pelo comando nmcli con del, e executar o script init_connections.shobtenho uma configuração de IP imprevisível para o sistema.
A configuração incorreta típica que ocorre é a seguinte:

• a conexão ativa (mostrada pelo nmcli concomando) é ethernet_default_ipstaticentão o sistema deve ter o endereço IP estático192.168.1.1/24
• mas o sistema obteve um endereço IP do servidor DHCP

Quando o script init_connections.shé executado pelo serviço, ele é executado antes do network.target , mas sinceramente não sei se essa diferença pode ser importante para entender o problema ou não.

Comando de descriptografia GPG

Estou tentando descriptografar um arquivo gpge para isso estou executando (com sucesso) o seguinte comando:

gpg --passphrase "12345678" --batch --yes --no-symkey-cache filename.tar.gz.gpg

O resultado da execução do comando é:

• o arquivo filename.tar.gz.gpgé descriptografado corretamente e é criado o arquivo filename.tar.gz;
• pelas opções --passphrase "12345678" --batch --yes a GUI para inserção da senha não está aberta.

--quietAviso e opção GPG

Mas há um problema: a gpgexecução do comando anterior produz o seguinte aviso:

gpg: WARNING: no command supplied.  Trying to guess what you mean ...

e a saída correta:

gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

Por este post , sei que pela opção --quieto comando anterior gpgnão produz nenhuma mensagem de saída.

O aviso parece dizer que no meu comando não está presente a solicitação para descriptografar o arquivo filename.tar.gz.gpg.

Minha pergunta

Então, minha pergunta é:
existe uma maneira de saber gpgse é necessário descriptografar um arquivo para evitar o aviso no command supplied.?

Eu sei disso pela execução do comando:

nmcli con show

Recebo a lista de todos os perfis de conexão presentes no sistema Linux. Por exemplo, se eu executar o comando anterior em meu sistema Linux Mint, obtenho:

$ nmcli con show
NAME             UUID                                  TYPE      DEVICE   
lan0             b89ebc2f-8702-32d1-8dbf-e8d4cf226ce1  ethernet  enp0s25  
lan1             bd0a02cf-65e9-3cf5-8b51-ef05aa204e7c  ethernet  enp5s0f0 
lan2             4b5d75d9-cab9-3ac5-95e5-cbeddf257cc5  ethernet  enp5s0f1 
lan1 with space  63b628f9-7671-41a4-8d2a-be5cfa34c454  ethernet  --       
lan2 with space  1cd1fb7d-0c5d-4105-ba27-c7e6ce7b6ecb  ethernet  --      

No exemplo o NOME dos perfis de conexão contém espaços (ver lan1 with spacee lan2 with space).

Minha necessidade é executar o comando anterior e obter apenas a lista da NAMEconexão sem a coluna UUID, TYPE, DEVICE.

No exemplo anterior, minha saída desejada seria:

lan0
lan1
lan2
lan1 with space
lan2 with space

Existe uma opção para o comando nmclique fornece exatamente a saída anterior?

Na minha distribuição lubuntu 18.04, instalei o google-chrome versão 114.

Por um script bash, a cada inicialização, o Chrome é iniciado e se conecta a um URL específico. A URL é sempre a mesma, mas às vezes o conteúdo do site muda, então preciso limpar o cache do google-chrome a cada inicialização.
Essa necessidade vem do fato de que meu sistema está sempre desligado (sem um desligamento correto) quando o chrome está em execução para que o navegador não seja fechado corretamente e seu cache na próxima inicialização não esteja vazio. Se o navegador fosse fechado corretamente eu poderia selecionar a opção do Google-Chrome Clear cookies and site data when you quit Chromeconforme explicado por exemplo neste link .

Meu problema é o mesmo descrito por este post .

Para limpar o cache segui as dicas deste link e criei um script bash que contém os seguintes comandos:

• rm -rf /home/myuser/.cache/google-chrome/*
• rm -rf /home/myuser/.config/google-chrome/Default/*

O script é executado na inicialização antes de iniciar o Google Chrome.

Às vezes, mesmo que muito raramente, notei algum mau funcionamento do Google Chrome que pode depender da presença de dados em cache, apesar da exclusão das pastas anteriores.

Devido a estas avarias, pergunto se os comandos anteriores são suficientes para eliminar todos os dados da cache ou se devo executar outras operações.

EDIT: Também é útil para mim saber a função das 2 pastas (in .cachee in .config) que estou excluindo na inicialização.

Preciso remover todos os dados de um disco rígido onde está instalado o lubuntu 22.04. Eu estava pensando em inicializar a partir de uma imagem liveUSB do Ubuntu e, a partir de um terminal, usar o comando:

# the Hard Disk is the device file /dev/sda
> sudo dd if=/dev/zero of=/dev/sda

Mas este link diz:

Esteja ciente de que isso removerá todas as informações da partição, mas não é uma "limpeza de disco" ou "exclusão segura". Se você deseja realmente ter certeza de que os dados não podem ser recuperados, a ferramenta mais eficaz a ser usada é um martelo.

Antes de ler essas frases, tive a impressão de que o ddcomando poderia excluir com segurança todos os dados de um disco rígido.

O ddcomando sozinho não é suficiente para apagar com segurança um disco rígido?

Eu trabalho na distribuição linux baseada em yocto. Não sou especialista em systemde nem em systemd-journald.
Meu programa C my_c_programé iniciado na inicialização pelo script my_script.sh. Abaixo segue o arquivo my_script.sh:

my_c_program &
echo $! > /dev/shm/my_c_program.pid

O script anterior é iniciado por um serviço. O arquivo de unidade do serviço é chamado start_c_program.service. Abaixo segue o atendimento da unidade:

[Unit]
Description=Start my_c_program
Requires=...
After=...
Before=...

[Service]
Type=forking
ExecStart=/usr/bin/my_script.sh
PIDFile=/dev/shm/my_c_program.pid

[Install]
WantedBy=multi-user.target

Com esta configuração, todas as instruções printf("message")presentes em my_c_programadicionam a string "message"a systemd-journald. Eu sei que se eu modificar my_script.shpara:

my_c_program > /dev/null &
echo $! > /dev/shm/my_c_program.pid

a mensagem on journaldé suprimida, mas a questão é:
por que toda a saída do meu programa C direcionada para stdout é enviada para journald?

Obrigado

Eu estava pensando que para enviar mensagem para journaldeu tinha que usar a instrução C syslog(), por exemplo por um código conforme abaixo:

#include<syslog.h>
int main(int argc, char** argv) {
    syslog(LOG_INFO, "Start logging");
}

Descrição do contexto

Uma distribuição Linux contém redis-server 6.0.5. O Redis está configurado para usar persistência AOF(Append Only File) e a RDBpersistência está desabilitada.

Na inicialização, um script solicita ao servidor redis a execução do BGREWRITEAOFcomando. Esta solicitação inicia um processo (com PID= <pid>) que cria um arquivo temp-rewriteaof-<pid>.aofno mesmo caminho de dados do Redis onde está escrito o appendonly.aofarquivo.

Este é o funcionamento normal do BGREWRITEAOFcomando. A utilidade deste comando é comprovada pelo que está escrito neste post .

Qual é o problema

O problema surge quando o sistema é desligado enquanto o BGREWRITEAOFnão está concluído. Nesse caso, o arquivo temp-rewriteaof-<pid>.aofainda está presente na reinicialização e ocupa espaço no disco.

Como o sistema pode ser desligado a cada momento, corro o risco de que meu disco fique cheio.
Na minha opinião, a solução exclusiva para esse problema é criar um script que remova todos os arquivos temp-rewriteaof-*.aofda pasta de dados do Redis.

Pergunta

Alguém conhece uma solução melhor? O Redis tem um procedimento/comando limpo para resolver este problema?

Estou desenvolvendo uma distribuição Linux baseada em yocto por zeus yocto release. Preciso adicionar um cliente NTP à distribuição, mas não preciso instalar o servidor NTP dentro da imagem.

Eu encontrei a receita:
meta-openembedded/meta-networking/recipes-support /ntp/ntp_4.2.8p15.bb
que é relativa ao Network Time Protocol (NTP).

A receita contém as seguintes informações sobre ele:

SUMMARY = "Network Time Protocol daemon and utilitys"
DESCRIPTION = "O Network Time Protocol (NTP) é usado para sincronizar a hora de um computador cliente ou servidor com outro servidor ou fonte de hora de referência, como um rádio ou receptor de satélite ou modem. "

As informações anteriores não explicam se a receita instala um servidor NTP ou um cliente NTP ou ambos.

O que eu preciso é de um aplicativo cliente NTP que seja capaz de se conectar a um servidor NTP configurável e obter a data e hora atuais.

A seguinte instrução:

IMAGE_INSTALL += "ntp"

não é adequado porque adiciona à imagem yocto o servidor NTP que é chamado ntpd.

Qual é o pacote que tenho que adicionar na imagem para incluir um cliente NTP? Está incluído na receita anterior ou tenho que encontrar uma receita diferente?

Obrigado

Eu preciso praticar com LDAP , então acho que é uma boa ideia instalar um servidor LDAP apenas para fazer alguns testes.

Para o lado do cliente estou usando uma distribuição LInux Mint e instalei todos os pacotes de software que encontrei neste link . Na minha empresa está disponível um serviço Active Directory, mas obviamente meu usuário não possui privilégios de administrador necessários para o seguinte comando:

sudo realm join domain.tld -U domain_administrator --verbose

Então eu estava pensando em instalar um servidor LDAP para fazer testes.

Alguém conhece um servidor LDAP adequado para meus propósitos?

Obrigado.

Neste link encontrei um tutorial para instalar OpenLDAP Server e OpenLDAP Client no Linux Mint.

A instalação do Servidor OpenLDAP é possível, como sempre, por apt:

sudo apt update
sudo apt -y install slapd ldap-utils 

Depois disso o servidor deve ser configurado e o link dá alguns detalhes. Obviamente este artigo é apenas uma introdução, mas é suficiente para começar a estudar um servidor LDAP.

Estou estudando LDAP e na minha empresa existe um Active Directory Server. Na minha estação de trabalho está instalado o Linux Mint.

Eu tento mostrar o contexto que surge minha pergunta:

• abra uma nova janela para navegar no sistema de arquivos da estação de trabalho;
• no menu Fileda janela aberta ( desculpe mas neste momento não consigo adicionar uma imagem desta janela aberta ), existe a opção Connect to Server;
• por esta opção posso selecionar Type: Windows sharee autenticar com uma conta registrada em um domínio Windows;
• depois disso posso navegar em alguns diretórios de rede onde minha conta está habilitada.

Explicado o contexto posso fazer a pergunta: por Connect to Servereu ter usado LDAP ou outra coisa? É possível a mesma autenticação por linha de comando?

Obrigado