Re: Pues sí, systemd se queda
2014-11-20 15:38 GMT+00:00 Luis Felipe Tabera Alonso <taberalf@unican.es>:
> On Thursday 20 November 2014 14:33:06 C. L. Martinez wrote:
>> 2014-11-20 14:07 GMT+00:00 Santiago Vila <sanvila@unex.es>:
>> > On Thu, Nov 20, 2014 at 10:20:24AM -0300, Ricardo Delgado wrote:
>> >> desde el simple hecho de tirar un "dmesg"
>> >
>> > ¿Qué le pasa a dmesg?
>> >
>> >> o tratar de ver los logs.
>> >
>> > ¿Qué le pasa a /var/log/syslog? Si no te gusta journalctl todavía
>> > puedes usar los logs de siempre. ¿Qué problema tienes?
>>
>> Ricardo tiene razón ... Es un auténtico despropósito todo el systemd
>> en sí. ¿Tu has comparado las salidas de "dmesg", "syslog" y
>> journalctl? Porque una cagada más a añadir a las tantas de systemd, es
>> que encima te mete los logs en binario que no vas a ver con el comando
>> "dmesg" y dentro del archivo syslog ...
>
> root@mychabol:/home/luisfe# journalctl -k -o short-monotonic| tail -5
> [ 703.807585] mychabol kernel: usb 2-1.2: new high-speed USB device number 9
> using ehci-pci
> [ 714.223097] mychabol kernel: usb 2-1.2: device not accepting address 9,
> error -110
> [ 714.295340] mychabol kernel: usb 2-1.2: new high-speed USB device number 10
> using ehci-pci
> [ 724.711056] mychabol kernel: usb 2-1.2: device not accepting address 10,
> error -110
> [ 724.711201] mychabol kernel: usb 2-1-port2: unable to enumerate USB device
>
> root@mychabol:/home/luisfe# dmesg | tail -5
> [ 703.807585] usb 2-1.2: new high-speed USB device number 9 using ehci-pci
> [ 714.223097] usb 2-1.2: device not accepting address 9, error -110
> [ 714.295340] usb 2-1.2: new high-speed USB device number 10 using ehci-pci
> [ 724.711056] usb 2-1.2: device not accepting address 10, error -110
> [ 724.711201] usb 2-1-port2: unable to enumerate USB device
>
>
Vale, vamos a jugar a ver quien la tiene mejor puesta :)) (es un broma
o sea que no nos cabreemos):
[root@ol7test01 ~]# journalctl -k -o short-monotonic| tail -10
[ 2569.625996] ol7test01.my.domain kernel: net vethGI7O4O:
'vethGI7O4O' renaming to 'eth0'
[ 2569.633998] ol7test01.my.domain kernel: IPv6:
ADDRCONF(NETDEV_CHANGE): vprodif0: link becomes ready
[ 2569.634025] ol7test01.my.domain kernel: prodif: port 4(vprodif0)
entered forwarding state
[ 2569.634033] ol7test01.my.domain kernel: prodif: port 4(vprodif0)
entered forwarding state
[ 2569.634260] ol7test01.my.domain kernel: net vethNLBR02:
'vethNLBR02' renaming to 'eth1'
[ 2569.638889] ol7test01.my.domain kernel: IPv6:
ADDRCONF(NETDEV_CHANGE): vsiemif0: link becomes ready
[ 2569.638916] ol7test01.my.domain kernel: siemif: port 3(vsiemif0)
entered forwarding state
[ 2569.638922] ol7test01.my.domain kernel: siemif: port 3(vsiemif0)
entered forwarding state
[root@ol7test01 ~]# dmesg | tail -10
[ 2569.613771] net vethGI7O4O: 'vethGI7O4O' renaming to 'vethGI7O4O'
[ 2569.621746] net vethNLBR02: 'vethNLBR02' renaming to 'vethNLBR02'
[ 2569.625996] net vethGI7O4O: 'vethGI7O4O' renaming to 'eth0'
[ 2569.633998] IPv6: ADDRCONF(NETDEV_CHANGE): vprodif0: link becomes ready
[ 2569.634025] prodif: port 4(vprodif0) entered forwarding state
[ 2569.634033] prodif: port 4(vprodif0) entered forwarding state
[ 2569.634260] net vethNLBR02: 'vethNLBR02' renaming to 'eth1'
[ 2569.638889] IPv6: ADDRCONF(NETDEV_CHANGE): vsiemif0: link becomes ready
[ 2569.638916] siemif: port 3(vsiemif0) entered forwarding state
[ 2569.638922] siemif: port 3(vsiemif0) entered forwarding state
Esto es una Oracle Linux Enterprise 7 corriendo 25 instancias LXC
(varias CentOS y otras OL6/7), donde se supone que la morralla del
systemd es lo más cercano a estable y menos agresivo que ninguna otra
linux y que ya lleva 5 o más actualizaciones del paquete systemd (y
esta no es una beta, es GA). Vale, pues ya me faltan dos lineas de
log:
[ 2569.613771] net vethGI7O4O: 'vethGI7O4O' renaming to 'vethGI7O4O'
[ 2569.621746] net vethNLBR02: 'vethNLBR02' renaming to 'vethNLBR02'
Anda la ostia!!! ... ¿Y eso porqué? Vamos a verlo:
a/ Primero un dmesg normal:
[root@ol7test01 ~]# dmesg | more
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.8.13-44.1.4.el7uek.x86_64
(mockbuild@ca-build56.us.oracle.com) (gcc version 4.8.2 20140120 (Red
Hat 4.8.2-16) (GCC) ) #2 SMP Wed Oct 2
9 16:58:08 PDT 2014
[ 0.000000] Command line:
BOOT_IMAGE=/vmlinuz-3.8.13-44.1.4.el7uek.x86_64
root=UUID=909470e7-0a76-4716-899f-f1eec3c7c61e ro net.ifnames=0
biosdevname=0 ipv6_disab
le=1 vconsole.keymap=es crashkernel=auto
vconsole.font=latarcyrheb-sun16 quiet LANG=en_US.UTF-8
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000f362efff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000f362f000-0x00000000f363bfff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000f363c000-0x00000000f363cfff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000f363d000-0x00000000f7ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fee0ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000040bffefff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.7 present.
[ 0.000000] DMI: HP ProLiant BL460c G7, BIOS I27 01/29/2011
[ 0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] No AGP bridge found
[ 0.000000] e820: last_pfn = 0x40bfff max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 00F4000000 mask FFFC000000 uncachable
[ 0.000000] 1 base 00F8000000 mask FFF8000000 uncachable
....
b/ Ahora a ver que me dice la morralla de systemd:
Nov 06 09:41:17 ol7test01.my.domain systemd-journal[143]: Runtime
journal is using 8.0M (max 788.8M, leaving 1.1G of free 7.6G, current
limit 788.8M).
Nov 06 09:41:17 ol7test01.my.domain systemd-journal[143]: Runtime
journal is using 8.0M (max 788.8M, leaving 1.1G of free 7.6G, current
limit 788.8M).
Nov 06 09:41:17 ol7test01.my.domain kernel: Initializing cgroup subsys cpuset
Nov 06 09:41:17 ol7test01.my.domain kernel: Initializing cgroup subsys cpu
Nov 06 09:41:17 ol7test01.my.domain kernel: Linux version
3.8.13-44.1.4.el7uek.x86_64 (mockbuild@ca-build56.us.oracle.com) (gcc
version 4.8.2 20140120 (Red
Nov 06 09:41:17 ol7test01.my.domain kernel: Command line:
BOOT_IMAGE=/vmlinuz-3.8.13-44.1.4.el7uek.x86_64
root=UUID=909470e7-0a76-4716-899f-f1eec3c7c61e ro
Nov 06 09:41:17 ol7test01.my.domain kernel: e820: BIOS-provided
physical RAM map:
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x0000000000000000-0x000000000009ebff] usable
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x000000000009ec00-0x000000000009ffff] reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000000f0000-0x00000000000fffff] reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x0000000000100000-0x00000000f362efff] usable
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000f362f000-0x00000000f363bfff] ACPI data
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000f363c000-0x00000000f363cfff] usable
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000f363d000-0x00000000f7ffffff] reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000fec00000-0x00000000fee0ffff] reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x00000000ff800000-0x00000000ffffffff] reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: BIOS-e820: [mem
0x0000000100000000-0x000000040bffefff] usable
Nov 06 09:41:17 ol7test01.my.domain kernel: NX (Execute Disable)
protection: active
Nov 06 09:41:17 ol7test01.my.domain kernel: SMBIOS 2.7 present.
Nov 06 09:41:17 ol7test01.my.domain kernel: DMI: HP ProLiant BL460c
G7, BIOS I27 01/29/2011
Nov 06 09:41:17 ol7test01.my.domain kernel: e820: update [mem
0x00000000-0x0000ffff] usable ==> reserved
Nov 06 09:41:17 ol7test01.my.domain kernel: e820: remove [mem
0x000a0000-0x000fffff] usable
Nov 06 09:41:17 ol7test01.my.domain kernel: No AGP bridge found
Nov 06 09:41:17 ol7test01.my.domain kernel: e820: last_pfn = 0x40bfff
max_arch_pfn = 0x400000000
Nov 06 09:41:17 ol7test01.my.domain kernel: MTRR default type: write-back
Nov 06 09:41:17 ol7test01.my.domain kernel: MTRR fixed ranges enabled:
Nov 06 09:41:17 ol7test01.my.domain kernel: 00000-9FFFF write-back
Nov 06 09:41:17 ol7test01.my.domain kernel: A0000-BFFFF uncachable
Nov 06 09:41:17 ol7test01.my.domain kernel: C0000-FFFFF write-protect
Nov 06 09:41:17 ol7test01.my.domain kernel: MTRR variable ranges enabled:
Nov 06 09:41:17 ol7test01.my.domain kernel: 0 base 00F4000000 mask
FFFC000000 uncachable
Nov 06 09:41:17 ol7test01.my.domain kernel: 1 base 00F8000000 mask
FFF8000000 uncachable
Nov 06 09:41:17 ol7test01.my.domain kernel: 2 disabled
Nov 06 09:41:17 ol7test01.my.domain kernel: 3 disabled
Nov 06 09:41:17 ol7test01.my.domain kernel: 4 disabled
Nov 06 09:41:17 ol7test01.my.domain kernel: 5 disabled
Nov 06 09:41:17 ol7test01.my.domain kernel: 6 disabled
Nov 06 09:41:17 ol7test01.my.domain kernel: 7 disabled
....
Yep, alto. Que la morralla esta juega con buffers y espacios en disco:
Nov 06 09:41:17 ol7test01.my.domain systemd-journal[143]: Runtime
journal is using 8.0M (max 788.8M, leaving 1.1G of free 7.6G, current
limit 788.8M).
Nov 06 09:41:17 ol7test01.my.domain systemd-journal[143]: Runtime
journal is using 8.0M (max 788.8M, leaving 1.1G of free 7.6G, current
limit 788.8M)
Vaya tela. O sea que hemos pasado de archivos de log puro en texto a
formato binario, con el consiguente problema de corrupción de datos y
pérdida de info. Pues si, hemos mejorado estupendamente. Mira por
dónde que en algún momento este server ha llenado esos 788.8M y claro,
como es tan listo, hemos empezado a borrar ... Anda la leche. Si, una
ventaja del copón ...
Cosas como esta son las que os esperan con systemd. Y esto solo son
los logs, algo de máxima criticidad en un server. Claro, que luego
viene el problema numero 2. ¿Y si tengo que redirigir a un colector de
logs y pierdo log porque porque se llena el journal? ¿Que hago, voy y
la casco? Porque otra de las fantásticas ideas que se implantarán con
systemd, es que los logs puros a texto te los vas a tener que currar
tú, porque por defecto el señorito sytemd los va a meter en binario.
¿Empezamos a ver porqué Linux (porque esto ya implica a más del 85% de
las distros) va a sufrir un retroceso brutal en todos los terrenos
profesionales?
Porque como esta hay más ...
Reply to: