Madoc Comadrin's questions

Estou usando Fedora Linux 41 (Workstation Edition)com o desktop Gnome.

Onde posso encontrar logs de atualizações de pacotes mostrando o horário da alteração e a alteração da versão de cada pacote que foi atualizado?

Deixo o Softwareaplicativo atualizar meu computador sempre que ele me avisa que há atualizações disponíveis. Na próxima inicialização, recebo uma notificação informando que os pacotes foram atualizados. Mas onde posso encontrar essa informação depois?

Procurei em arquivos do /var/log/dnf*.logJournal e do Journal, mas não consegui encontrar essas informações.

Algumas fontes sugerem o uso do comando sudo dnf history list. Mas este mostra apenas os pacotes que alterei manualmente.

user@host:~ $ dnf history list
ID Command line                Date and time       Action(s) Altered
10 dnf install podman          2025-03-22 19:30:50                33
 9 dnf remove podman           2025-03-22 19:28:15                33
 8 dnf install odt2txt         2025-03-20 19:48:49                 1
 7 dnf install pdfgrep         2025-02-24 16:10:16                 1
 6 dnf install git-filter-repo 2025-02-06 18:40:01                 1
 5 dnf install python3.12      2025-01-18 16:28:12                 3
 4 dnf install python3.8       2025-01-14 10:25:39                 3
 3 dnf remove python3.12*      2025-01-14 10:24:30                 2
 2 dnf install python3.12      2025-01-13 12:02:36                 2
 1 dnf install 1password       2024-12-03 21:51:57                 5
user@host:~ $ dnf history info 2
Transaction ID : 2
Begin time     : 2025-01-13 12:02:36
Begin rpmdb    : e7a735605a2fd46f438ab398979091536caf0c2065c383b27be5ead0a877c8ce
End time       : 2025-01-13 12:02:47
End rpmdb      : 3088d9d71b2b98054a7bfc26ee602f7d2cd0668b970528156c12ea4beef7c0c9
User           : 1000 user
Status         : Ok
Releasever     : 41
Description    : dnf install python3.12
Comment        : 
Packages altered:
  Action  Package                                Reason     Repository
  Install python3.12-0:3.12.8-2.fc41.x86_64      User       updates
  Install python3.12-libs-0:3.12.8-2.fc41.x86_64 Dependency updates

Espero encontrar informações semelhantes às /var/log/apt/history.logdisponíveis sobre sistemas baseados em Debian.

Tenho um computador executando o Fedora Workstation 40 e o Systemd 255. Por algum motivo, as mensagens de log do kernel ficam disponíveis no Diário por muito menos tempo do que outras mensagens de log.

user@host:~ $ journalctl -k | head
Sep 07 22:15:28 host kernel: Linux version 6.10.6-200.fc40.x86_64 (mockbuild@f1069ead281040288cd8d3761ad1265a) (gcc (GCC) 14.2.1 20240801 (Red Hat 14.2.1-1), GNU ld version 2.41-37.fc40) #1 SMP PREEMPT_DYNAMIC Mon Aug 19 14:09:30 UTC 2024
Sep 07 22:15:28 host kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.10.6-200.fc40.x86_64 root=UUID=800307e3-abdf-4cc6-a111-b068a8bb22a9 ro rootflags=subvol=root rd.luks.uuid=luks-5da2f27b-d221-4a68-a150-648d03962ac0 rhgb quiet
Sep 07 22:15:28 host kernel: BIOS-provided physical RAM map:
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000059000-0x000000000009cfff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x000000000009d000-0x00000000000fffff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003fffffff] usable
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000040000000-0x00000000403fffff] reserved
Sep 07 22:15:28 host kernel: BIOS-e820: [mem 0x0000000040400000-0x0000000075477fff] usable

user@host:~ $ journalctl | head
Aug 19 17:53:26 host systemd-journald[1079]: /var/log/journal/645eb9bfb5a942db9945b658805a08a5/user-1000.journal: Journal file uses a different sequence number ID, rotating.
Aug 19 17:53:26 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=user@42 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 19 17:53:26 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=user@1000 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 19 17:53:26 host audit[1718]: USER_START pid=1718 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=host addr=? terminal=/dev/tty1 res=success'
Aug 19 17:53:26 host audit[1675]: USER_START pid=1675 uid=0 auid=1000 ses=2 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1675]: CRED_REFR pid=1675 uid=0 auid=1000 ses=2 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1679]: USER_START pid=1679 uid=0 auid=1000 ses=3 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_systemd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1679]: CRED_REFR pid=1679 uid=0 auid=1000 ses=3 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1799]: USER_ACCT pid=1799 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_access,pam_unix acct="th" exe="/usr/bin/crontab" hostname=? addr=? terminal=cron res=success'
Aug 19 17:53:26 host audit[1799]: CRED_ACQ pid=1799 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="th" exe="/usr/bin/crontab" hostname=? addr=? terminal=cron res=success'

Usar o comando journalctl com sudo não faz diferença. De acordo com journalctl --verifytodos os arquivos do Journal, eles estão OK.

A configuração do Journald está usando os valores padrão:

user@host:~ $ systemd-analyze cat-config systemd/journald.conf
# /usr/lib/systemd/journald.conf
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=no
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes
#Audit=yes

Há espaço livre suficiente em disco disponível:

user@host:~ $ du -hs /var/log/journal/
465M    /var/log/journal/


user@host:~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-0       237G   23G  212G  10% /
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.7G   14M  7.7G   1% /dev/shm
efivarfs        154K   55K   95K  37% /sys/firmware/efi/efivars
tmpfs           3.1G  2.2M  3.1G   1% /run
/dev/dm-0       237G   23G  212G  10% /home
/dev/nvme0n1p2  974M  353M  554M  39% /boot
tmpfs           7.7G  3.4M  7.7G   1% /tmp
/dev/nvme0n1p1  599M   20M  580M   4% /boot/efi
tmpfs           1.6G   72K  1.6G   1% /run/user/0
tmpfs           1.6G  228K  1.6G   1% /run/user/1000

O que pode estar causando isso e como fazer com que as mensagens do kernel permaneçam no Journal tanto tempo quanto outras mensagens?

Eu tentei fazer backup do meu Crontab para arquivo usando o seguinte comando: crontab -l > backup/crontab. Mas isso cria apenas um arquivo vazio no diretório backupe nenhuma saída é impressa no terminal. O código de saída desse comando é 0.

Se eu fizer crontab -lsem redirecionamento, recebo a saída esperada:

/5 * * * * /path/to/script
...

Por que meu comando está falhando ao gravar meu conteúdo do Crontab no arquivo e o que devo fazer para que isso funcione?

Estou usando o Centos 7.7e as seguintes versões dos pacotes Cron instalados:

crontabs-1.11-6.20121102git.el7.noarch
cronie-1.4.11-23.el7.x86_64
cronie-anacron-1.4.11-23.el7.x86_64

Shell que eu uso é GNU bash, version 4.2.46.

EDITAR:

[user@host ~]$ crontab -l > backup/crontab
[user@host ~]$ ll backup
total 248K
drwx------. 28 user user 4,0K 31.10. 09:30 .
drwxr-xr-x.  7 user user 4,0K  1.10. 12:58 ..
-rw-rw-r--.  1 user user 0    31.10. 09:30 crontab
...

Backup é um diretório local e tem a seguinte política Selinux: staff_u:object_r:user_home_t:s0.

EDIT2:

crontab -l > /tmp/crontabfunciona e outros locais onde também tenho acesso de gravação, mas quando o destino está dentro do meu diretório inicial, ele falha. Eu me pergunto se selinuxestá causando isso.

Eu configurei unattended-upgradesem servidores rodando Raspbian ( Raspbian GNU/Linux 9.4 (stretch)). Versão das atualizações autônomas:0.93.1+nmu1

As atualizações funcionam, mas estou tendo problemas com os relatórios por e-mail. Eu quero usar mailxpara enviar relatórios. Se eu executar a atualização com o comando unattended-upgrade -v -d, o relatório será enviado e usará a configuração de e-mail que tenho em /root/.mailrc.

Quando unattended upgradessão executados pelo timer Systemd ( apt-daily-upgrade.timer), no entanto, ele não usará mailx.

Se sendmailestiver presente, é usado para enviar o e-mail. Nesse caso, o e-mail é enviado, mas o remetente é root@hostnamee as mensagens são sinalizadas como spam.

Se não houver sendmail, vejo este erro no diário de apt-daily-upgrade:

Cannot start "/usr/sbin/sendmail": executable not found (adjust *sendmail* variable)

Não consigo entender por que diferentes programas de email são usados ​​dependendo de como a tarefa foi iniciada.

Eu tentei editar o unattended-upgradesprograma Python para forçá-lo a usar mailx:

if os.path.exists(SENDMAIL_BINARY):
        ret = _send_mail_using_sendmail(from_email, to_email, subject, body)
    elif os.path.exists(MAIL_BINARY):
        ret = _send_mail_using_mailx(from_email, to_email, subject, body

Eu mudei a variável SENDMAIL_BINARYpara apontar para um caminho inexistente para que fosse forçado a usar mailx. Isso também funcionou quando invocado unattended-upgradesmanualmente, mas falhou quando foi executado pelo Systemd. (E o erro acima sobre tentar usar sendmailainda é registrado.)

Como posso forçar unattended upgradeso uso mailxmesmo quando é executado automaticamente pelo systemd e o que está causando a diferença no programa Mail que é usado?

EDITAR:

Arquivo de unidade do sistema que executa atualizações autônomas:

[Unit]
Description=Daily apt upgrade and clean activities
Documentation=man:apt(8)
ConditionACPower=true
After=apt-daily.service

[Service]
Type=oneshot
ExecStart=/usr/lib/apt/apt.systemd.daily install
KillMode=process
TimeoutStopSec=900

Estou usando Ubuntu 16.04e habilitei atualizações e reinicializações automáticas. Versão de unattended-upgradesé 0.90ubuntu0.9.

Quando há uma reinicialização pendente e estou logado no servidor, continuo recebendo estas notificações na minha sessão:

Broadcast message from root@server (Fri 2018-04-06 10:30:00 EEST):
The system is going down for reboot at Sat 2018-04-07 03:30:00 EEST!

Broadcast message from root@server (Fri 2018-04-06 11:30:00 EEST):
The system is going down for reboot at Sat 2018-04-07 03:30:00 EEST!

Broadcast message from root@server (Fri 2018-04-06 12:30:00 EEST):
The system is going down for reboot at Sat 2018-04-07 03:30:00 EEST!

Broadcast message from root@server (Fri 2018-04-06 13:30:00 EEST):
The system is going down for reboot at Sat 2018-04-07 03:30:00 EEST!

Broadcast message from root@server (Fri 2018-04-06 14:30:00 EEST):
The system is going down for reboot at Sat 2018-04-07 03:30:00 EEST!

Posso evitar que essas mensagens sejam enviadas para o shell, pois é irritante recebê-las e os usuários sabem que o servidor pode reiniciar durante a janela de manutenção? Eu verifiquei, /etc/apt/apt.conf.d/50unattended-upgradesmas encontrei apenas configurações de notificação por e-mail lá.

Eu tenho um servidor Raspberry Pi com Raspbian OS:

Kernel: Linux 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
Description:    Raspbian GNU/Linux 8.0 (jessie)
Release:        8.0
Codename:       jessie

Hoje notei que as tentativas de uso mysqlterminam em falha de segmentação.

user@host~ $ mysql -u root -p
Enter password:
Segmentation fault

Isso acontece tanto para a senha errada quanto para a correta. Ou mesmo se eu inventasse um nome de usuário. Na verdade, verifica-se que mesmo executar o mysqlcomando sem nenhum argumento tem o mesmo efeito.

O servidor Mysql ainda pode ser acessado via Python ( pymysql) e Perl. Eu tenho scripts que escrevem e leem vários bancos de dados, todos funcionam sem problemas.

Shell scripts que usam o mysqlcomando, todos eles falham. Por exemplo:

/home/user/example.sh: line 2: 27974 Segmentation fault      /usr/bin/mysql -u dbuser -p$dbpass dbname --execute="select * from example;"

As falhas de segmentação começaram a aparecer hoje e não consigo descobrir o que as está causando agora. O servidor não foi inicializado em algumas semanas. Já se passou mais de uma semana desde a última atualização.

Não consigo encontrar nenhum erro que possa parecer relevante para esta situação nos logs ou syslog do Mysql.

Eu tentei:

• Reiniciando o Mysql
• Atualização do sistema e reinicialização
• Verificando o disco na reinicialização, nenhum erro encontrado

Como esses procedimentos não ajudaram, tentei usar gdbconforme sugerido aqui:

O aplicativo em execução termina com "Falha de segmentação"

Isso é o que recebo ao depurar o comando mysqlsem nenhum parâmetro:

gdb mysql run run Iniciando o programa: /usr/bin/mysql

gdb mysql
run
Starting program: /usr/bin/mysql
Program received signal SIGSEGV, Segmentation fault.
elf_dynamic_do_Rel (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>,
    reladdr=<optimized out>, map=0xb6fff968) at do-rel.h:112
112     do-rel.h: No such file or directory.

Eu me pergunto o que eu poderia fazer para corrigir esse problema? (Além de fazer um relatório de bug sobre isso.)