Change the mp3 bitrate for ripping in K3b

I’ve been using K3b successfully (it’s currently at version 2.0.3-r1 in Gentoo Linux) to rip Audio CDs to mp3 files, but despite changing the bitrate to 192 kbps in the ‘K3b Lame Mp3 Encoder’ plugin settings, K3b was still ripping mp3 files at 128 kbps. I found out that I needed to make another change too.

The default bitrate for ripped mp3 tracks is 128 kbps in K3b. To use a different bitrate, I needed to do the following:

1. ‘Settings’ > ‘Configure K3b…’

2. Click on ‘Plugins’

3. Click on the spanner next to ‘K3b Lame Mp3 Encoder’, and change the bitrate on the Settings tab to 192 (or whatever you want). However, this alone does not have any effect, so also click on the spanner next to ‘K3b External Audio Encoder’, click on ‘Mp3 (Lame)’ in the list of ‘Configured Encoders’, click on ‘Edit’ and insert ‘-b 192‘ (or whatever bitrate you want) in the list of lame options, like so:

lame -r --bitwidth 16 --little-endian -b 192 -s 44.1 -h --tt %t --ta %a --tl %m --ty %y --tc %c --tn %n - %f

Here’s what happens before I added the ‘-b 192‘ to the settings for ‘Mp3 (Lame)’ in ‘K3b External Audio Encoder':

$ file 01\ -\ Meu\ Bem\ Querer.mp3
01 - Meu Bem Querer.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

And after adding the ‘-b 192‘ to the settings for ‘Mp3 (Lame)’ in ‘K3b External Audio Encoder':

$ file 01\ -\ Meu\ Bem\ Querer.mp3
01 - Meu Bem Querer.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, JntStereo

Notice the bit rate of the file has changed.

NetworkManager creating a new connection ‘eth0′ that does not work, Part 4

Further to my previous post, this is to report the result of another experiment. By doing all the following I can stop NetworkManager creating an invalid second eth0 connection:

  • Enable IPv6 system-wide in /etc/modprobe.d/aliases.conf by commenting-out ‘alias net-pf-10 off‘.
  • Disable use of IPv6 by the Avahi daemon in /etc/avahi/avahi-daemon.conf (see the four additional lines given in my previous post).
  • Use plasma-nm to edit the connection profile for ‘eth0′ that I had already created. Click on the IPv6 tab and ensure ‘Method: Ignored‘ is selected. Click on the IPv4 tab and ensure ‘Method: Automatic‘ is selected and ‘IPv4 is required for this connection‘ is ticked. Ticking ‘IPv4 is required for this connection‘ adds the line ‘may-fail=false‘ in the [ipv4] section in the file /etc/NetworkManager/system-connections/eth0 (the default value for may-fail is ‘true‘ if the box has not been ticked and may-fail has not been assigned in the file).

The various experiments I have conducted are summarised in the following table:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true true false false false
Invalid second eth0 created usually no usually no yes yes

As disabling IPv6 system-wide makes it impossible for NetworkManager to use IPv6, the above table can actually be written as follows:

Laptop WiFi switch off off off off off on
IPv6 enabled in aliases.conf yes no yes yes yes yes
IPv6 enabled in avahi-daemon.conf yes yes||no no no yes yes
[ipv6] method= ignore ignore ignore ignore ignore ignore
[ipv4] method= auto auto auto auto auto auto
[ipv4] may-fail= true true||false true false false false
Invalid second eth0 created usually no usually no yes yes

I still think there is a bug in NetworkManager. I would not have expected NetworkManager to create a second eth0 connection and make it an IPv6 Link-Local connection when all the following are true:

  • /etc/NetworkManager.conf has ‘no-auto-default=eth0‘ in the [main] section.
  • IPv4 is required for this connection‘ is not ticked in plasma-nm (i.e. the [ipv4] section in /etc/NetworkManager/system-connections/eth0 contains either the line ‘may-fail=true‘ or the line ‘may-fail=‘).
  • Method: Automatic‘ is selected for IPv4 (‘method=auto‘ under [ipv4] in /etc/NetworkManager/system-connections/eth0).
  • Method: Ignored‘ is selected for IPv6 (‘method=ignore‘ under [ipv6] in /etc/NetworkManager/system-connections/eth0) and the other fields on the IPv6 tab have been rendered unselectable as a result.

Anyway, I will keep IPv6 disabled in /etc/avahi/avahi-daemon.conf and IPv6 enabled system-wide. This seems to be the first thing to try if you’re experiencing the creation of an invalid additional eth0 connection with an IPv6 Link-Local address and you’re sure that none of the net.* services are running.

NetworkManager creating a new connection ‘eth0′ that does not work, Part 3

I’m even more convinced the problem discussed in my previous post is due to a bug in NetworkManager. I believe the issue with the Avahi daemon generating an IPv6 Link-Local address is a consequence of NetworkManager not always activating an interface and therefore not obtaining an IPv4 address, i.e. the IPv6 Link-Local address produced by the Avahi daemon is a side effect, not the root cause.

After my previous post I discovered that adding ‘use-ipv6=no‘ in /etc/avahi/avahi-daemon.conf (my Experiment 2) had not prevented avahi-daemon using IPv6. However, adding the following lines in /etc/avahi/avahi-daemon.conf defintely does prevent avahi-daemon from using IPv6 in my installation:

use-ipv4=yes
use-ipv6=no
publish-a-on-ipv6=no
publish-aaaa-on-ipv4=no

You can see in the message log below that the Avahi daemon is no longer generating an IPv6 Link-Local address. However, even with IPv6 disabled in avahi-daemon, an invalid second eth0 connection with an IPv6 Link-Local address still occurs in my installation. This indicates the problem is not caused by the Avahi daemon.

Mar 18 22:17:31 localhost syslog-ng[8316]: syslog-ng starting up; version='3.6.2'
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  NetworkManager (version 1.0.0) is starting...
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  Read config: /etc/NetworkManager/NetworkManager.conf
Mar 18 22:17:32 localhost NetworkManager[8346]: <info>  WEXT support is enabled
Mar 18 22:17:34 localhost kernel: fglrx_pci 0000:01:00.0: irq 34 for MSI/MSI-X
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8351
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8352
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Firegl kernel thread PID: 8353
Mar 18 22:17:34 localhost kernel: <6>[fglrx] IRQ 34 Enabled
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e2000, size:4000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:f7e6000, size:51a000 
Mar 18 22:17:34 localhost kernel: <6>[fglrx] Reserved FB block: Unshared offset:3fff3000, size:d000 
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/Cisco00497
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/eth0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  new connection /etc/NetworkManager/system-connections/DIRECT-HeC460 Series
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  monitoring kernel firmware directory '/lib/firmware'.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  rfkill0: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill0) (driver iwlwifi)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi hardware radio set enabled
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN hardware radio set enabled
Mar 18 22:17:33 localhost /etc/init.d/NetworkManager[8326]: WARNING: NetworkManager has started, but is inactive
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wwan.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Loaded device plugin: /usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiFi disabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WWAN enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  WiMAX enabled by radio killswitch; enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  Networking is enabled by state file
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): new Generic device (driver: 'unknown' ifindex: 1)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (lo): exported as /org/freedesktop/NetworkManager/Devices/0
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): link connected
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): carrier is ON
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): new Ethernet device (driver: 'atl1c' ifindex: 2)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  startup complete
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: starting connection 'eth0'
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): using nl80211 for WiFi device control
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): new 802.11 WiFi device (driver: 'iwlwifi' ifindex: 3)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): exported as /org/freedesktop/NetworkManager/Devices/2
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (wlan0): preparing device
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 1 of 5 (Device Prepare) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) starting...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) successful.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) scheduled.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 2 of 5 (Device Configure) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
Mar 18 22:17:33 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ModemManager1' (using servicehelper)
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) scheduled...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 3 of 5 (IP Configure Start) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) started...
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): Activation: Stage 5 of 5 (IPv6 Commit) complete.
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 18 22:17:33 localhost NetworkManager[8346]: <info>  NetworkManager state is now CONNECTED_LOCAL
Mar 18 22:17:33 localhost acpid[8386]: starting up with netlink and the input layer
Mar 18 22:17:33 localhost acpid[8386]: 6 rules loaded
Mar 18 22:17:33 localhost acpid[8386]: waiting for events: event logging is off
Mar 18 22:17:34 localhost ModemManager[8385]: <info>  ModemManager (version 1.4.2) starting in system bus...
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  (eth0): Activation: successful, device activated.
Mar 18 22:17:34 localhost dbus[7763]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 18 22:17:34 localhost nm-dispatcher[8435]: Dispatching action 'up' for eth0
Mar 18 22:17:34 localhost rpc.statd[8451]: Version 1.3.2 starting
Mar 18 22:17:34 localhost rpc.statd[8451]: Flags: TI-RPC 
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8457]: status: inactive
Mar 18 22:17:34 localhost rpc.statd[8451]: Running as root.  chown /var/lib/nfs to choose different user
Mar 18 22:17:34 localhost /etc/init.d/NetworkManager[8469]: status: inactive
Mar 18 22:17:34 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ModemManager1'
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager disappeared from bus
Mar 18 22:17:34 localhost NetworkManager[8346]: <info>  ModemManager available in the bus
Mar 18 22:17:35 localhost sm-notify[8556]: Version 1.3.2 starting
Mar 18 22:17:35 localhost avahi-daemon[8585]: Found user 'avahi' (UID 108) and group 'avahi' (GID 444).
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped root privileges.
Mar 18 22:17:35 localhost avahi-daemon[8585]: avahi-daemon 0.6.31 starting up.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully called chroot().
Mar 18 22:17:35 localhost avahi-daemon[8585]: Successfully dropped remaining capabilities.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/sftp-ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Loading service file /services/ssh.service.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Network interface enumeration completed.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Registering HINFO record with values 'X86_64'/'LINUX'.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Server startup complete. Host name is meshedgedx.local. Local service cookie is 3778762828.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/ssh.service) successfully established.
Mar 18 22:17:35 localhost avahi-daemon[8585]: Service "meshedgedx" (/services/sftp-ssh.service) successfully established.
Mar 18 22:17:35 localhost ntpd[8645]: ntpd 4.2.8@1.3265-o Wed  4 Mar 02:23:30 UTC 2015 (1): Starting
Mar 18 22:17:35 localhost ntpd[8645]: Command line: ntpd -g -q
Mar 18 22:17:35 localhost ntpd[8645]: proto: precision = 0.061 usec (-24)
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 0 v6wildcard [::]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 2 lo 127.0.0.1:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 3 lo [::1]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listen normally on 4 eth0 [fe80::725a:b6ff:fe3e:c18a%2]:123
Mar 18 22:17:35 localhost ntpd[8645]: Listening on routing socket on fd #21 for interface updates
Mar 18 22:17:36 localhost kernel: fbcondecor: console 1 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 1
Mar 18 22:17:37 localhost kernel: fbcondecor: console 2 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 2
Mar 18 22:17:37 localhost kernel: fbcondecor: console 3 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 3
Mar 18 22:17:37 localhost kernel: fbcondecor: console 4 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 4
Mar 18 22:17:37 localhost kernel: fbcondecor: console 5 using theme 'Emergance'
Mar 18 22:17:37 localhost kernel: fbcondecor: switched decor state to 'on' on console 5
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth daemon 5.28
Mar 18 22:17:36 localhost bluetoothd[8787]: Starting SDP server
Mar 18 22:17:37 localhost kernel: Bluetooth: Core ver 2.19
Mar 18 22:17:37 localhost kernel: NET: Registered protocol family 31
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI device and connection manager initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: HCI socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: L2CAP socket layer initialized
Mar 18 22:17:37 localhost kernel: Bluetooth: SCO socket layer initialized
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP filters: protocol multicast
Mar 18 22:17:38 localhost kernel: Bluetooth: BNEP socket layer initialized
Mar 18 22:17:36 localhost bluetoothd[8787]: Bluetooth management interface 1.7 initialized
Mar 18 22:17:36 localhost NetworkManager[8346]: <info>  use BlueZ version 5
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by any plugin
Mar 18 22:17:37 localhost ModemManager[8385]: <warn>  Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0': not supported by any plugin
Mar 18 22:17:39 localhost dbus[7763]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper)
Mar 18 22:17:39 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.ColorManager'
Mar 18 22:17:41 localhost kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC= SRC=fe80:0000:0000:0000:725a:b6ff:fe3e:c18a DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=64 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=UDP SPT=8612 DPT=8612 LEN=24 
Mar 18 22:17:43 localhost laptop-mode[8947]: Laptop mode 
Mar 18 22:17:43 localhost laptop-mode[8948]: enabled, not active
Mar 18 22:17:58 localhost kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Mar 18 22:17:58 localhost rpc.mountd[9741]: Version 1.3.2 starting
Mar 18 22:17:59 localhost kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Mar 18 22:17:59 localhost kernel: NFSD: starting 90-second grace period (net ffffffff81c3d580)
Mar 18 22:17:58 localhost sm-notify[9760]: Version 1.3.2 starting
Mar 18 22:17:58 localhost sm-notify[9760]: Already notifying clients; Exiting!
Mar 18 22:18:00 localhost sshd[9816]: Server listening on 0.0.0.0 port 22.
Mar 18 22:18:00 localhost sshd[9816]: Server listening on :: port 22.
Mar 18 22:18:00 localhost cron[9870]: (CRON) STARTUP (V5.0)
Mar 18 22:18:00 localhost su[9899]: Successful su for fitzcarraldo by root
Mar 18 22:18:00 localhost su[9899]: + /dev/console root:fitzcarraldo
Mar 18 22:18:00 localhost su[9899]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost dbus[7763]: [system] Activating service name='org.freedesktop.RealtimeKit1' (using servicehelper)
Mar 18 22:18:01 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully called chroot.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully dropped privileges.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Successfully limited resources.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Watchdog thread running.
Mar 18 22:18:01 localhost rtkit-daemon[9906]: Canary thread running.
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_unix(kde:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:01 localhost kdm[8833]: :0[8833]: pam_ck_connector(kde:session): nox11 mode, ignoring PAM_TTY :0
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] sink.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] source.c: Default and alternate sample rates are the same.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost rtkit-daemon[9906]: Supervising 0 threads of 0 processes of 1 users.
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module-jackdbus-detect.c: Unable to contact D-Bus session bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:03 localhost pulseaudio[9904]: [pulseaudio] module.c: Failed to load module "module-jackdbus-detect" (argument: "channels=2"): initialization failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Module load failed.
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost pulseaudio[9904]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Mar 18 22:18:04 localhost su[9899]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9964]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9964]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9966]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9966]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: Successful su for fitzcarraldo by root
Mar 18 22:18:04 localhost su[9968]: + /dev/console root:fitzcarraldo
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session opened for user fitzcarraldo by (uid=0)
Mar 18 22:18:04 localhost su[9968]: pam_unix(su:session): session closed for user fitzcarraldo
Mar 18 22:18:15 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
Mar 18 22:18:15 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UPower'
Mar 18 22:18:17 localhost dbus[7763]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper)
Mar 18 22:18:17 localhost udisksd[10120]: udisks daemon version 2.1.4 starting
Mar 18 22:18:17 localhost dbus[7763]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Mar 18 22:18:17 localhost udisksd[10120]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Mar 18 22:18:19 localhost kernel: [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:16:fa:25:28:01:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=0 PROTO=2 
Mar 18 22:18:54 localhost hp-systray[10453]: hp-systray[10453]: error: option -s not recognized
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Successfully made thread 10469 of process 10469 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:55 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:55 localhost pulseaudio[10469]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Successfully made thread 10485 of process 10485 (/usr/bin/pulseaudio) owned by '1000' high priority at nice level -11.
Mar 18 22:18:56 localhost rtkit-daemon[9906]: Supervising 1 threads of 1 processes of 1 users.
Mar 18 22:18:56 localhost pulseaudio[10485]: [pulseaudio] pid.c: Daemon already running.
Mar 18 22:19:04 localhost polkitd[7911]: Registered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.52 [/usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Mar 18 22:19:10 localhost su[10569]: Successful su for root by fitzcarraldo
Mar 18 22:19:10 localhost su[10569]: + /dev/pts/0 fitzcarraldo:root
Mar 18 22:19:10 localhost su[10569]: pam_unix(su:session): session opened for user root by fitzcarraldo(uid=1000)
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Mar 18 22:19:26 localhost pulseaudio[9904]: [alsa-sink-ALC272 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Mar 18 22:20:01 localhost cron[10670]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

In the cases when NetworkManager activates a connection correctly and there is no invalid second eth0 connection, the log contains a message like the following:

Mar 16 22:23:47 localhost NetworkManager[6688]: <info>  Auto-activating connection 'eth0'.

Notice there is no such message in the message log above.

The only way I can be sure of preventing NetworkManager creating an invalid second eth0 connection is to disable IPv6 system-wide by uncommenting the line ‘alias net-pf-10 off‘ in the file /etc/modprobe.d/aliases.conf.

So, to me, this looks like a bug in NetworkManager 1.0.0 (I have been experiencing it since Version 0.9.10.0).

NetworkManager creates a new connection ‘eth0′ that does not work

Several months ago a new entry ‘eth0′ began appearing under ‘Available connections‘ in the KDE plasma-nm widget (the KDE GUI front-end to NetworkManager) in my Gentoo Linux installation. However, there was already an automatically-created entry ‘Wired connection 1′ for the wired interface. In the plasma-nm GUI I could see that both entries were for the same interface (eth0) and MAC address. My laptop could access the Internet via the connection ‘Wired connection 1′ as usual, but not via the new connection ‘eth0′. And if I deleted ‘eth0′ in the plasma-nm GUI, ‘Wired connection 1′ could not access the Internet until I recreated ‘eth0′ manually.

Apart from the fact that two entries for the same interface is unnecessary, it was annoying because sometimes ‘eth0′ automatically became the active connection instead of ‘Wired connection 1′, despite the fact that only ‘Wired connection 1′ had ‘Automatically connect to this network when it is available’ ticked in the plasma-nm GUI. When this happened, the network icon on the Panel showed an active connection but in fact the laptop could not connect to the Internet. However, the connection did work as expected on the occasions when ‘Wired connection 1′ automatically became the active connection or if I switched manually to ‘Wired connection 1′ via the plasma-nm GUI.

Even more strangely, if I happened to be using WiFi when no Ethernet cable was connected, very occasionally the network icon on the Panel would change from a wireless icon to a wired icon and connection to the Internet would be lost. I would then have to re-select the wireless network in order to reconnect to the Internet.

As my laptop has only one Ethernet port, and as there was previously no ‘eth0′ entry under ‘Available connections‘, initially I thought that the new entry occurred because I had recently installed a new version of udev. I have the parameter net.ifnames=0 in the kernel boot line to stop udev/eudev using the so-called Predictable Network Interface Names, and I have the following udev/eudev rules files relating to networking:

# ls -la /etc/udev/rules.d/*net*
lrwxrwxrwx 1 root root    9 Nov 30 15:25 80-net-setup-link.rules -> /dev/null
# ls -la /lib64/udev/rules.d/*net*
-rw-r--r-- 1 root root  452 Nov  7 09:57 /lib64/udev/rules.d/75-net-description.rules
-rw-r--r-- 1 root root 1734 Jan 28 18:29 /lib64/udev/rules.d/77-mm-huawei-net-port-types.rules
-rw-r--r-- 1 root root  491 Nov  7 09:57 /lib64/udev/rules.d/80-net-name-slot.rules
-rw-r--r-- 1 root root  280 Jan 24 00:41 /lib64/udev/rules.d/90-network.rules

Perhaps udev (well, eudev, as I switched to using eudev after the problem started) did have something to do with the new entry, but I began to suspect that NetworkManager was the culprit. I think the problem first occurred after installing NetworkManager 0.9.10.0 last October, but it remained after I installed NetworkManager 1.0.0, until today when I made the various changes described further on.

I had merged NetworkManager 1.0.0 and preceding versions since 0.9.8.8 with USE flags -dhclient and dhcpcd, i.e. NetworkManager in my installation uses the DHCP client dhcpcd instead of dhclient. (I used to merge NetworkManager to use dhclient but found it did not work with 0.9.8.8 and later versions of NetworkManager.)

The relevant network services running in my installation are as follows, and nothing looks incorrect to me:

# rc-update show | grep -i net
       NetworkManager |      default
                local |      default nonetwork
               net.lo | boot
             netmount |      default
# rc-status | grep -i net
NetworkManager                                                    [ started ]
netmount                                                          [ started ]
# rc-update show | grep dh
# rc-status | grep dh
# rc-update -v show | grep supplicant
wpa_supplicant |
# rc-status | grep supplicant
#

NetworkManager itself launches the DHCP client, so the installation should not be configured to launch a DHCP client. Indeed the output above shows that no DHCP client service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of a DHCP client are not running (they’re not):

# ps -C NetworkManager
  PID TTY          TIME CMD
 6481 ?        00:00:22 NetworkManager
# ps -C dhcpcd
  PID TTY          TIME CMD
10378 ?        00:00:00 dhcpcd
# ps -C dhclient
  PID TTY          TIME CMD
#

As far as WiFi is concerned, NetworkManager itself launches wpa_supplicant, so the installation should not be configured to launch wpa_supplicant. Indeed the output from rc-update and rc-status above shows that no wpa_supplicant service is configured to run independently of NetworkManager, and I also double-checked that multiple instances of wpa_supplicant are not running (they’re not):

# ps -C wpa_supplicant
  PID TTY          TIME CMD
 6491 ?        00:00:00 wpa_supplicant
#

So, as far as I could tell, there was nothing wrong with the non-NetworkManager side of my installation.

I thought the problem might be due to the settings in the file /etc/NetworkManager/NetworkManager.conf, which contained the following:

[main]
plugins=keyfile
dhcp=dhcpcd

[ifnet]
managed=true
auto_refresh=false

[keyfile]
hostname=meshedgedx

I studied the manual pages for NetworkManager.conf:

# man NetworkManager.conf

If I understand correctly, the ifnet plug-in is Gentoo-specific (see References 3, 4 and 5 further on). The entries under [ifnet] in my NetworkManager.conf file were redundant in any case because the ifnet plug-in was not included in the plugins list under [main], so I deleted the entire [ifnet] section. There is no mention of the ifnet plug-in on the NetworkManager.conf manual page or in the Gentoo Linux Wiki article on NetworkManager, and a cursory look in the Gentoo ebuild for NetworkManager 1.0.0 clearly indicates the ifnet plug-in is broken. See, for example, the following comment in the ebuild:

# ifnet plugin always disabled until someone volunteers to actively
# maintain and fix it

and the following warning messages in the ebuild if the user has included ifnet in plugin=<plugin list> in NetworkManager.conf:

ewarn "Ifnet plugin is now disabled because of it being unattended"
ewarn "and unmaintained for a long time, leading to some unfixed bugs"
ewarn "and new problems appearing. We will now use upstream 'keyfile'"
ewarn "plugin."
ewarn "Because of this, you will likely need to reconfigure some of"
ewarn "your networks. To do this you can rely on Gnome control center,"
ewarn "nm-connection-editor or nmtui tools for example once updated"
ewarn "NetworkManager version is installed."
ewarn "You seem to use 'ifnet' plugin in ${EROOT}etc/NetworkManager/NetworkManager.conf"
ewarn "Since it won't be used, you will need to stop setting ifnet plugin there."

I modified NetworkManager.conf to contain the following:

[main]
plugins=keyfile
dhcp=dhcpcd
no-auto-default=eth0

[keyfile]
hostname=meshedgedx

Note that the ifnet plug-in was not specified in the plugins list in the [main] section of my previous NetworkManager.conf so it was not the cause of my problem, but I hoped that adding no-auto-default=eth0 to NetworkManager.conf would solve the problem. I deleted the ‘Wired connection 1′ entry from the plasma-nm GUI, ticked ‘Automatically connect to this network when it is available’ for the ‘eth0′ entry and made sure that option was not ticked for any of the other entries under ‘Available connections‘, then rebooted. There was no longer an entry ‘Wired connection 1′ in the plasma-nm widget GUI, just an entry for ‘eth0′, and the installation connected automatically to the wired network and I could access the Internet, but did not reconnect to the wired network if I removed and reinserted the Ethernet cable when also connected to a wireless network. So I was not home and dry yet.

I have read on various Web sites that NetworkManager prefers wired connections over wireless connections. I assume this is because NetworkManager sets a higher metric for the wired connection.

I am on a work trip at the moment and cannot use a dynamic wired connection, only a static wired connection, but I can see that NetworkManager 1.0.0 does set a higher-priority metric for wired connections:

# # Now with both dynamic wireless and static wired:
# ip route show
default via 10.90.21.1 dev eth0  proto static  metric 100
default via 10.96.0.1 dev wlan0  proto static  metric 600
10.90.21.0/24 dev eth0  proto kernel  scope link  src 10.90.21.112  metric 100
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86
10.96.0.0/16 dev wlan0  proto kernel  scope link  src 10.96.87.86  metric 303
127.0.0.0/8 dev lo  scope host
127.0.0.0/8 via 127.0.0.1 dev lo
192.0.2.1 via 10.96.0.1 dev wlan0  proto dhcp  metric 600
#

10.90.21.1 is the IP address of the gateway for the wired connection, and 10.90.21.112 is the IP address of my laptop’s wired interface. The smaller the metric value, the higher the routing priority. Notice that the metric for the eth0 interface is 100 whereas the metric for the wlan0 interface is 600, so it does appear that NetworkManager favours a wired connection over a wireless connection when both are active.

After doing all the above, I came across Debian bug report no. 755202: network-manager: keeps creating and using new connection “eth0″ that does not work which appears to be exactly what I was experiencing. Various people posted solutions that worked in their particular circumstances, so I am none the wiser. Gentoo user Keivan Moradi posted message no. 79 on that bug report, about a warning message he found in the NetworkManager log file regarding a file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0, and he then deleted the latter file. I found the same message in /var/log/messages:

# grep networkmanager /var/log/messages
Feb  9 04:10:05 localhost NetworkManager[10355]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing
Feb 11 15:53:05 localhost NetworkManager[13143]: <warn>      error in connection /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0: invalid connection: connection.type: property is missing

The file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 also existed in my installation, so I also deleted it. It was a zero-length file and I do not know if it had anything to do with my problem:

# ls -la /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
-rw------- 1 root root 0 Jan 20 00:09 /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
# rm /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0
#

Anyway, the file /etc/NetworkManager/system-connections/.keep_net-misc_networkmanager-0 has not reappeared since I deleted it.

Keivan Moradi had ‘id=Wired‘ under [connection] in the file /etc/NetworkManager/system-connections/eth0, and he decided to change the name of the file from ‘eth0‘ to ‘Wired‘. However, in my case the file name and the id in the file /etc/NetworkManager/system-connections/eth0 are both ‘eth0‘:

# cat /etc/NetworkManager/system-connections/eth0
[ethernet]
mac-address=70:5A:B6:3E:C1:8A
mac-address-blacklist=

[connection]
id=eth0
uuid=cb3d5786-f947-44b8-92f7-8471fc94c568
type=ethernet
permissions=
secondaries=

[ipv6]
method=ignore
dns-search=

[ipv4]
method=auto
dns-search=

I had already deleted and recreated the connection ‘eth0′ in the plasma-nm GUI by the time I checked the contents of the directory /etc/NetworkManager/system-connections/ so I do not know if the original file name and id were the same. I had also already deleted the connection ‘Wired connection 1′ in the plasma-nm GUI by the time I checked the contents of the directory; presumably files for connections ‘Wired connection 1′ and ‘eth0′ both existed in /etc/NetworkManager/system-connections/ before then. I do not know why the zero-length file .keep_net-misc_networkmanager-0 was created, but no further files have appeared in the directory since I deleted the connection ‘Wired connection 1′ and the file .keep_net-misc_networkmanager-0.

Keivan Moradi was also previously using a buggy r8169 kernel module (Realtek Ethernet hardware) and switched to using the r8168 module, but I am using a Qualcomm Atheros AR8131 Gigabit Ethernet card and an Intel Corporation Ultimate N WiFi Link 5300 card, so that part of his problem cannot be a factor in my case.

Anyway, as I wrote earlier, I no longer have two connection entries for the wired interface, and NetworkManager no longer creates automatically a second connection entry for the wired interface. And now if I am already connected to a wireless network, NetworkManager connects/reconnects automatically to a wired network with the ‘Automatically connect’ option ticked. So it looks like my problem is completely solved, although I reserve judgement until I have been able to use the laptop in my home network (which has the same router for both wired and wireless connections, whereas the wired network and wireless network are separate networks in the office in which I am now working).

Conclusion

If you had the patience to read all the above, I am impressed! If you also understood it, I am doubly impressed!

To cut a long story short, if you are experiencing a similar problem to mine, I recommend you do the following:

  1. Check that your network driver is reliable. You can search the Web to see if other users have experienced problems with the same driver you are using.

  2. Make sure the contents of NetworkManager.conf are correct. Read the NetworkManager.conf man page and the GNOME Wiki page on NetworkManager settings to find out what options are available.

  3. Delete all the files (i.e. including hidden files) in the directory /etc/NetworkManager/system-connections/ and recreate your connections via either the NetworkManager GUI (e.g. plasma-nm in KDE or nm-applet in GNOME) or NetworkManager TUI (nmtui).

References

  1. man NetworkManager.conf
  2. Gentoo Linux Wiki – NetworkManager
  3. GNOME Wiki – NetworkManager SystemSettings – Configuration Plugins
  4. Gentoo NetworkManager Plugin
  5. Another Gentoo Dev – Ifnet updates for NetworkManager 0.9

UPDATE (March 10, 2015): Well, I was right to reserve judgement until I was able to use my laptop with my home network. I am now back at home and an Ethernet cable is plugged into my laptop’s RJ45 socket. Even with the changes I made, when I boot the laptop NetworkManager sometimes (but not always) has two connections named ‘eth0′, one of them the ‘Active connection’ (but not able to connect to the Internet) and the other an ‘Available connection’. In this situation the wired network icon on the Panel has a yellow question mark superimposed. If I delete the ‘eth0′ active connection and use the other ‘eth0′, the latter works as expected and I have no trouble connecting to the Internet. In Debian bug report no. 755202 (see the link further up) user Frederik Himpe added a comment on March 4, 2015 that he is also still experiencing this problem and “It looks like there is a race somewhere, causing the network interface to be brought up before Network Manager is started, and this prevents correct configuration by NM”. So the problem is still unresolved. Hmm … I wonder if udev does have something to do with it after all.

UPDATE (March 12, 2015): The problem persists. I disabled use of IPv6 in /etc/avahi/avahi-daemon.conf to see if the Avahi daemon has something to do with the problem, but that made no difference. Later I also disabled use of IPv4 in /etc/avahi/avahi-daemon.conf, but that made no difference either. So it looks like the Avahi daemon is not the culprit. Checking via the plasma-nm GUI I notice that the ‘rogue’ eth0 Active connection has IPv4 disabled and IPv6 Link-Local enabled. So why is NetworkManager creating a second eth0 connection just for IPv6 Link-Local? And why on Earth is NetworkManager creating any additional connection at all when NetworkManager.conf contains no-auto-default=eth0? Surely this must be a bug in NetworkManager 1.0.0?

UPDATE (March 17, 2015): I have been investigating the problem further: see my latest blog post for details.

Fix for ALSA Speaker volume level resetting to zero at boot

Up until 2011 the problem of the volume level in ALSA resetting to zero at boot was a common occurrence in my Linux installations. Actually it was a common occurrence in Linux, full stop; search the Web using keywords such as “alsa reset volume” and you’ll find umpteen links. In 2012 the situation improved and I thought the problem had become a thing of the past, but it resurfaced in 2013 on my main laptop and has plagued me through every update since (well, apart from in one release of KDE). Every time I reboot, the ALSA Speaker channel’s volume is zero when I log-in to KDE. And, as KMix is a PulseAudio mixer by default these days, I have to launch ALSAMixer and raise the volume of the Speaker channel manually.

I don’t know if the source of the problem lies in KDE, PulseAudio or ALSA itself. It did disappear after one upgrade to KDE earlier this year (I don’t recall which release of KDE) but returned in the next KDE upgrade, so I suspect it is a KDE issue. In earlier days I could resolve the problem using the commands alsactrl store and alsactl restore and similar approaches. However, this time none of those fixes work for me. The problem never bothered me much, as I always connect external speakers to my laptop’s headphone socket when I’m at home, and I don’t want my laptop emitting sounds at the office. Nevertheless, the fact the problem exists niggled me, so I decided to try and fix it. Rather than expending any more effort trying to get the usual approaches to work (the Web is littered with suggested fixes over the years), I decided to reset the Speaker volume to the same level at each boot by using an automatically-launched shell script. The method I use is given below, and should work with either OpenRC or systemd in Gentoo Linux.

1. Create the file /etc/local.d/20set_alsa_volume.start containing the following:

#!/bin/bash
# Reset ALSA Speaker channel on the first sound card to 90% after booting.
su -c "amixer -c 0 -- sset Speaker playback 90%" -s /bin/sh fitzcarraldo

(Replace “fitzcarraldo” with your own user name, of course.)

2. Make the script executable:

# chmod +x 20set_alsa_volume.start

That’s all there is to it. The volume of the ALSA Speaker channel is always set to 90% after I reboot and login to the desktop environment. KMix remembers the PulseAudio volume setting from the previous session, so I can still avoid blasting the laptop’s speakers.

By the way, the manual pages for the amixer and alsamixer commands make useful reading:

$ man amixer
$ man alsamixer

For example, the first audio card (Card 0) in my main laptop has the following controls:

$ amixer -c 0 scontrols
Simple mixer control ‘Master’,0
Simple mixer control ‘Headphone’,0
Simple mixer control ‘Speaker’,0
Simple mixer control ‘PCM’,0
Simple mixer control ‘Mic’,0
Simple mixer control ‘Mic Boost’,0
Simple mixer control ‘Beep’,0
Simple mixer control ‘Capture’,0
Simple mixer control ‘Auto-Mute Mode’,0
Simple mixer control ‘Digital’,0
Simple mixer control ‘Internal Mic’,0
Simple mixer control ‘Internal Mic Boost’,0

Update (January 29, 2015): I found the cause of the problem: PulseAudio. I edited the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf as per user agmg‘s January 2013 post Re: [SOLVED] Problems with PulseAudio 3.0 in the PCLinuxOS Forums:

Again, I had to edit the file: /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf

and change this:

[Element Speaker]
switch = mute
volume = off

to this:

[Element Speaker]
switch = mute
volume = merge

I realized that editing the [Element Desktop Speaker] section of the above file, has no effect on the issue. Only the edit to [Element Speaker] is needed in my case.

In my case this change forces the ALSA Speaker channel volume to 100% after rebooting (irrespective of the volume levels I set via ALSAMixer and KMix before shutdown).

The contents of the file /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf also include the following comment:

; See analog-output.conf.common for an explanation on the directives

The contents of the file analog-output.conf.common include the following comment:

; volume = ignore | merge | off | zero | <volume step> # What to do with this volume: ignore it, merge it into the device
;                                                      # volume slider, always set it to the lowest value possible, or always
;                                                      # set it to 0 dB (for whatever that means), or always set it to
;                                                      # <volume step> (this only makes sense in path configurations where
;                                                      # the exact hardware and driver are known beforehand).

So I could have tried volume = <volume step> instead of volume = merge, although I have no idea what value <volume step> would need to be. Anyway, the Bash script /etc/local.d/20set_alsa_volume.start that I created does the job in a different way without me having to tinker with the troublesome PulseAudio, so I reverted to volume = off in the file analog-output.conf and reverted to using /etc/local.d/20set_alsa_volume.start as explained earlier.

Laptop Mode Tools revisited due to a change in its functionality

The site statistics for this blog can be quite revealing. For example, over the last two or three months I noticed that my post How to prevent a USB mouse auto-suspending in Linux when a laptop’s power supply is disconnected has consistently been one of the most viewed. Given the problems I experienced with Laptop Mode Tools 1.65 (see my Gentoo Linux Forums post Bug in laptop-mode-tools-1.65? and Gentoo Linux Bugzilla Bug Report No. 520124), I was not entirely surprised. Thanks to fellow Gentoo Linux and Laptop Mode Tools user Ted Tanberry I learned that Version 1.65 had stopped using Laptop Mode Tools module usb-autosuspend, and started using Laptop Mode Tools module runtime-pm instead. At least that was the developer’s intention, but he had not implemented it correctly. The aforementioned Gentoo Linux bug report explains in detail the problem with Version 1.65.

The situation in my Gentoo Linux installation with laptop-mode-tools-1.64 installed, providing the functionality I desired, was as follows:

a. The precise package installed:

# eix -I laptop-mode-tools
[U] app-laptop/laptop-mode-tools
Available versions: 1.64 (~)1.65 (~)1.65-r1 (~)1.66 {+acpi apm bluetooth scsi}
Installed versions: 1.64(10:04:43 21/10/14)(acpi bluetooth -apm -scsi)
Homepage: http://www.samwel.tk/laptop_mode/
Description: Linux kernel laptop_mode user-space utilities

b. The auto-suspend state when the laptop PSU was connected:

# for d in /sys/bus/usb/devices/[0-9]* ; do if [[ -e $d/product ]] ; then echo -e "`basename $d`\t`cat $d/power/control`\t`cat $d/speed`\t`cat $d/product`" ; fi ; done
1-1.2 on 1.5 USB Laser Mouse
2-1.2 on 12 Fingerprint Sensor
2-1.3 on 480 USB 2.0 Camera

c. The contents of the file /lib64/udev/rules.d/99-laptop-mode.rules:

ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=usb-autosuspend devices=%k"

d. The contents of file /etc/laptop-mode/conf.d/usb-autosuspend.conf:

#
# Configuration file for Laptop Mode Tools module usb-autosuspend.
#
# For more information, consult the laptop-mode.conf(8) manual page.
#
 
 
###############################################################################
# USB autosuspend settings
# ------------------------
#
# If you enable this setting, laptop mode tools will automatically enable the
# USB autosuspend feature for all devices.
#
# NOTE: Some USB devices claim they support autosuspend, but implement it in a
# broken way. This can mean keyboards losing keypresses, or optical mice turning
# their LED completely off. If you have a device that misbehaves, add its USB ID
# to the blacklist below and complain to your hardware vendor.
################################################################################
 
# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0
 
# Enable USB autosuspend feature?
# Set to 0 to disable
CONTROL_USB_AUTOSUSPEND="auto"
 
# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which USB devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0
 
# The list of USB IDs that should not use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_BLACKLIST="046d:c052"
 
# The list of USB driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_BLACKLIST=""
 
# The list of USB IDs that should use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_WHITELIST=""
 
# The list of USB driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_WHITELIST=""
 
# Trigger auto-suspension of the USB deivce under conditional circumstances
BATT_SUSPEND_USB=1
LM_AC_SUSPEND_USB=0
NOLM_AC_SUSPEND_USB=0
 
# USB Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

Having experienced the problems with the buggy Laptop Mode Tools 1.65, I re-installed 1.64 and had been using that successfully until a week ago. Then I noticed that 1.66 had been released, so I installed it:

# emerge laptop-mode-tools
.
.
.
>>> Installing (1 of 1) app-laptop/laptop-mode-tools-1.66::gentoo
* To enable automatic power state event handling,
* e.g. enabling laptop_mode after unplugging the battery,
* both laptop_mode and the acpid daemon must be
* added to default runlevel:
* # rc-update add laptop_mode default
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

I would not have expected that ewarn message about adding laptop_mode to the default runlevel, as the ebuild is only supposed to display the warning if laptop_mode is not assigned to the default runlevel. But, sure enough, something had removed it:

# rc-update show -v | grep laptop
laptop_mode |
# rc-update show -v | grep acpi
acpid |      default

I don’t know what removed laptop_mode from the default runlevel. It was certainly assigned previously, as proved by Laptop Mode Tools 1.64 working as expected when I connected and disconnected the laptop’s PSU from the mains (see my earlier post). Anyway, I re-added it:

# rc-update add laptop_mode default
* service laptop_mode added to runlevel default

If you use systemd instead of OpenRC, instead of adding laptop_mode to the default runlevel you would need to use the following command:

# systemctl enable laptop_mode.service

Notice that the incorrect contents of 99-laptop-mode.rules and /etc/laptop-mode/laptop-mode.conf that were present in Laptop Mode Tools 1.65 have been fixed in 1.66:

# cat /lib64/udev/rules.d/99-laptop-mode.rules
ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto force"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=runtime-pm devices=%k"

# cat /etc/laptop-mode/laptop-mode.conf | grep usb-autosuspend
#

The ebuild for Laptop Mode Tools 1.66 did not delete the now-redundant file /etc/laptop-mode/conf.d/usb-autosuspend.conf but it is presumably ignored by 1.66 anyway.

From now on I must configure the contents of /etc/laptop-mode/conf.d/runtime-pm.conf instead. After installing Laptop Mode Tools 1.66 it contained the following:

#
# Configuration file for Laptop Mode Tools module runtime-pm
#
# For more information, consult the laptop-mode.conf(8) manual page.
#


###############################################################################
# Runtime Power Management Settings
# ---------------------------------
#
#__COMMENT If you enable this setting, laptop mode tools will automatically enable
#__COMMENT the Runtime Power Management feature for all devices.
#__COMMENT
#__COMMENT NOTE: Some devices claim they support autosuspend, but implement it in a
#__COMMENT broken way. This can mean keyboards losing keypresses, or optical mice
#__COMMENT turning their LED completely off. If you have a device that misbehaves,
#__COMMENT add its DEVICE ID to the blacklist section below and complain to your
#__COMMENT hardware / device driver contact
#
################################################################################

# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0

# Enable Runtime autosuspend feature?
# Set to 0 to disable
CONTROL_RUNTIME_AUTOSUSPEND=1

# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0

# The list of Device IDs that should not use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST=""

# The list of device driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST=""

# The list of Device IDs that should use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_WHITELIST=""

# The list of device driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_WHITELIST=""

# Trigger auto-suspension of the deivce under conditional circumstances
# Warning: DO NOT CHANGE THESE DEFAUTLS UNLESS YOU KNOW
BATT_SUSPEND_RUNTIME=1
LM_AC_SUSPEND_RUNTIME=1
NOLM_AC_SUSPEND_RUNTIME=1

# Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

So, in order to stop my laptop’s USB mouse, USB external keyboard and some internal USB devices from going to sleep when my laptop is only on battery power, I made the following change to a line in /etc/laptop-mode/conf.d/runtime-pm.conf:

# External keyboard at one office, internal Webcam, internal fingerprint sensor, Logitek NX50 notebook mouse
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="03f0:0024 064e:a115 147e:1001 046d:c052"

My earlier post about Laptop Mode Tools explained one method for finding the device ID for each USB device, but the lsusb command can also be used:

# lsusb
Bus 002 Device 005: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard <---- External keyboard at one office
Bus 002 Device 004: ID 064e:a115 Suyin Corp. <---- Built-in Webcam
Bus 002 Device 003: ID 147e:1001 Upek TCS5B Fingerprint sensor <---- Built-in fingerprint sensor
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 046d:c052 Logitech, Inc. <----Logitech NX50 notebook mouse
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Although the Laptop Mode Tools usb-autosuspend module is supposed to be unused in 1.66, I edited /etc/laptop-mode/conf.d/usb-autosuspend.conf (which was not deleted by the 1.66 ebuild) and changed CONTROL_USB_AUTOSUSPEND="auto" to CONTROL_USB_AUTOSUSPEND="0" just to be on the safe side.

My thoughts on systemd

When I first read about systemd a few years ago, the main ‘marketing point’ seemed to be that Linux boots faster using it rather than SysVinit — see, for example, On to better booting. When I read that article back in September 2012, a paragraph caught my eye:

It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Gentoo, Frugalware — Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Ubuntu seems to be sticking with Upstart.

As a Gentoo user I was surprised to read that the distribution was ‘lining up behind systemd’ — systemd was not even mentioned in the Gentoo Handbook — so I started a thread in the Gentoo Forums enquiring whether there were plans to change the default init system from OpenRC to systemd: Gentoo ‘lining up behind systemd’?.

Revisiting that ITWorld article two years later, I notice the paragraph was subsequently changed, as it now reads:

It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Frugalware — Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Gentoo has its own next generation rc system called OpenRC, which competes with both systemd and upstart, but provides its users with the option of installing systemd. Ubuntu seems to be sticking with Upstart.

OpenRC works fine for me; I know how to use it and I do not particularly want to have to learn how to use another system when what I use now works perfectly well for my purposes. By no means do I begrudge others the use of systemd, as long as my freedom of choice is not curtailed. Each to his own, as the saying goes. But events over the past couple of years have left me wondering about my freedom to choose in the future, and indeed about the future form of the operating system itself.

Faster startup?

As I mentioned above, the main marketing point when I first read about systemd was its boot time. When I tried systemd in May 2013 on a 2009 Acer Aspire 5536-643G25Mn laptop (dual-core CPU; 3 GB RAM) — no match for today’s state-of-the-art hardware — the times to boot from the GRUB 2 menu to the DM login screen for a fully-updated 64-bit Sabayon Linux Xfce installation were as follows:

OpenRC with rc_parallel=”NO” 33 seconds
OpenRC with rc_parallel=”YES” 31 seconds
systemd 29 seconds

I posted the above timings in the Sabayon Linux Forums and the developer of the distribution responded:

speed improvements heavily depend on the CPU and I/O subsystem. In particular, systemd is able to leverage multi-core CPUs much better (because it spawns services in parallel). Spawning services in parallel also puts more pressure on the I/O subsystem, which means that if you have faster I/O (like with SSDs), the speed boost compared to OpenRC becomes quite relevant.

Indeed a few users of newer machines with 8 GB or more RAM and/or SSD drives wrote in the Sabayon Linux Forums that their boot times had almost been halved (e.g. from circa 40 seconds to circa 21 seconds). However, I expect the boot times for OpenRC and systemd would not be dramatically different from each other on any of my existing machines and, in any case, I’m not bothered about saving a few seconds in boot time on my machines (and I don’t reboot often either).

Nowadays one hears less mention of faster boot times from systemd proponents. For example, the author of the December 2011 article Here We Go Again, Another Linux Init: Intro to systemd mentioned ‘Faster Startups’ early on, whereas in a September 2014 article Understanding and Using Systemd, the same author states:

For whatever reason, it seems that the proponents of SysVInit replacements are obsessed with boot times. My systemd systems, like CentOS 7, don’t boot up all that much faster than the others. It’s not something I particularly care about in any case, since most boot speed measurements only measure reaching the login prompt, and not how long it takes for the system to completely start and be usable.

Erosion of choice?

A couple of Gentoo developers commented in the above-mentioned 2012 Gentoo Forums thread that adoption of systemd as the default init system in Gentoo would be extremely unlikely. Several posters pointed out that alternative init systems exist and Gentoo users could simply install an alternative if desired. However, I started to wonder about the long-term availability of choice when I began to see blog posts such as Red Hat Flag and, indeed, when I myself was affected by systemd’s subsumption of udev (see e.g. udev is doomed) earlier this year and, more recently, when a Gentoo developer had to create the package upower-pm-utils because systemd subsumed hibernate & suspend support from upower (UPower 0.99.0 was released to ~arch as of 2014-06-01).

Whatever one’s views on systemd, the impact on non-systemd users when systemd developers change something that previously worked fine is frustrating. Gentoo developers have been doing a good job working around such nugatory subsumptions, but it’s extra work for them and extra effort for the Gentoo user who doesn’t use systemd. I began to wonder how long this state of affairs could continue.

Another layer of abstraction?

Although my main laptop has Gentoo installed with OpenRC, on a couple of other machines I tinker with Sabayon Linux, which uses systemd. Sabayon Linux is pre-compiled Gentoo with an overlay and its own binary package manager, so there is some synergy in using the two distributions. Also, it is clear from several threads requesting help in the Gentoo Forums that a number of Gentoo users are migrating to systemd. In answering or just reading forum posts involving systemd, and in writing blog posts of my own explaining how to use systemd for certain tasks, in some cases it feels to me as if systemd sometimes adds a layer of abstraction that is not necessarily helpful. Two examples that spring to mind are given below.

  1. The Gentoo Forums thread [SOLVED]I don’t understand transient hostnames in which a Gentoo user using systemd was trying to stop the hostname being changed when he connected to some networks:

    I’m running a systemd based system for the first time and I’m having an issue with my hostname. Basically, when I connect to (some) networks the network assigns me a transient hostname. This transient hostname seems to completely break everything with my desktop manager (KDM). I have to log out, and then log in with the new transient hostname (which is presumably assigned shortly after I log in and network manager connects to the network). Is this expected? I have set my hostname as described in the handbook and the systemd wiki page. How do I make my hostname *never* change based on dhcp crap?

    After I pointed out that it is possible to force a persistent hostname by specifying the hostname in NetworkManager.conf if NetworkManager is being used with either systemd or OpenRC, he wrote:

    My hostname is now written in 3 places (/etc/hosts, /etc/hostname, and /etc/NetworkManager/NetworkManager.conf). Oh, and I have some random executable (hostnamectl) sitting on my system doing a seemingly poor job of ‘controlling’ my hostname.

    Out of curiosity I then experimented with hostnamectl and compared the outcome with the outcome of setting the hostname in an installation that does not use systemd, and the results differed, so I’m not sure of the scope of hostnamectl.

  2. Time (Arch Wiki)

    The hardware clock can be queried and set with the timedatectl command. To change the hardware clock time standard to localtime, use:

    # timedatectl set-local-rtc 1

    If you want to revert to the hardware clock being in UTC, do:

    # timedatectl set-local-rtc 0

    These will generate /etc/adjtime automatically and update the RTC accordingly; no further configuration is required.

    During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of /sys/class/rtc/rtcN/hctosys (N=0,1,2,..) will be set to 1.

    Later, the system clock is set again from the hardware clock by systemd, dependent on values in /etc/adjtime. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea (there is a lot more to it). To avoid it systemd (>215) will only synchronize back, if the hardware clock is set to UTC and keep the kernel uninformed about the local timezone. As a consequence timestamps on a FAT filesystem touched by the Linux system will be in UTC.

    Note: The use of timedatectl requires an active dbus. Therefore, it may not be possible to use this command under a chroot (such as during installation). In these cases, you can revert back to the hwclock command.

Swimming against the tide?

There have been a number of dissenting voices on the Internet. Some argue against systemd on technical grounds, others on philosophical grounds. Here are are few examples:

One of the few distributions bucking the trend is Void Linux, which has replaced systemd with runit as the default init system, with systemd becoming an option.

Slackware and Gentoo are two distributions that do not use systemd by default, although it is actually reasonably straightforward to switch to systemd in Gentoo. It seems one or two people are moving to Gentoo, or contemplating it, because systemd isn’t the default in Gentoo (see, for examples, Re: OT: Open letter to the Linux World and IgnorantGuru’s Hiatus).

Several threads in the Gentoo Forums contain prolonged discussions on systemd, and it is clear that some Gentoo users have strong reservations about systemd. As I write this, a poll in the Gentoo Forums shows only 13 per cent of respondents support the idea of Gentoo adopting systemd as the default init system. I suspect that users of binary-based distributions find this lack of enthusiasm odd, but I believe it is because Gentoo is a source-based distribution and its users are usually more familiar with Linux internals and more comfortable, more adept and more interested in getting ‘under the hood’ than are users of binary-based distributions. Gentoo is not quite Linux From Scratch, but Gentoo users build their installations almost from the ground up (Gentoo does not even have an installer application, for example). I believe that anything interfering with the current way of doing things, or adding a level of abstraction, is not of interest to many Gentoo users. On the other hand, I think users of binary-based distributions who just want to get something done in the quickest way possible are less likely to object.

The beginnings of a new OS?

systemd is not just an init system, it has grown into much more than that and continues to add functionality (referred to by some as ‘feature creep’). Below is the current list of functionality provided in systemd, and the list is growing.

init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, read-ahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, console management, network management, time synchronisation

I think more of the seasoned GNU/Linux users are waking up to the impact of what Lennart Poettering (the chief architect of systemd) and his fellow systemd ‘cabal’ (his word) members are doing. They are re-designing GNU/Linux from the ground up, and I don’t think it would be an exaggeration to call the end result ‘systemd/Linux’, a de facto new OS. Personally I’m not interested in using that, but I think the vast majority of existing users or newcomers to ‘Linux’ — to use the popular term for the OS — simply don’t care. As long as it works out-of-the-box, that’s all that matters to most people.

And as far as distribution developers are concerned, the status quo says it all: most have already switched their distributions to systemd or have committed to doing so in the future. I suspect it is because they see systemd as being easier to maintain, thus making their lives easier, and they also see systemd as being easier for their desktop users (and with a boot time closer to Windows 8/8.1 Fast Startup). Ultimately the systemd ‘cabal’ will effectively make the different package managers obsolete too, as the latest plan Revisiting How We Put Together Linux Systems shows.

In my opinion, the end result of the radical systemd redesign of the OS could be greater take-up of the OS on the desktop, but the distinction between distributions will lessen and many will cease to exist, as there will be little point choosing one over another. The greater commonality and the larger user base of systemd/Linux will attract more crackers than at present. In some respects the de facto new OS will be much more like Windows or Mac OS than the current GNU/Linux.

Widening the net?

In a Chromium OS discussion group thread earlier this year — The future of initsystem in Chromium OS — a systemd proponent (a Fedora developer?) offered to help the Chrome OS developers switch from Upstart to systemd, but the Chrome OS developers saw no reason to do so without proof of tangible benefits. I believe there is too much revenue at stake to risk switching an important component of the OS of a commercial product (Chromebooks) on a whim. With Chromebooks looking increasingly like the main threat to Microsoft’s hegemony on the desktop, I’m sure Google has no interest in jeopardising that without a very good reason.

The future?

The future seemed clear to me once Mark Shuttleworth announced Ubuntu would drop Upstart and adopt systemd (he made the announcement after Debian developers decided to adopt systemd). Given the number of Ubuntu users (I’ve seen figures in the tens of millions bandied about), I believe Ubuntu will be the making or breaking of systemd. In my opinion, as was the case with PulseAudio (another Lennart Poettering project) there will be a couple of choppy years with plenty of posts in the Ubuntu Forums seeking help, more bugs will be shaken out, and I believe the vast majority of Linux users will end up as accepting users of systemd. In some cases systemd does make configuration a little easier for a newcomer (see, for example, my post Configuring the Linux clock). Personally I find systemd no easier to use than what I use now; in some cases I find systemd more complicated than what I use now (e.g. OpenRC’s local.d). My concerns regarding abstraction, subsumption, loss of choice and the morphing of the OS into something closer to the Windows approach remain, although I can see that many people, including newcomers to Linux, would actually welcome those things. Ironically, although I used to get frustrated with the large number of Linux distributions and their differences, the implications of greater commonality now worry me from a security (predominantly cybercrime) point of view. I am satisfied and comfortable with the existing GNU/Linux tools, configuration files, modus operandi and OpenRC (which works with no problems whatsoever in my case), so I have no desire to migrate to systemd on my main machine running Gentoo Linux. I will also continue to tinker with Sabayon Linux, and thus with systemd, but it will be several years hence before this jury returns a verdict on systemd.

Configuring the Linux clock

A problem often reported by users in Linux forums is that the time displayed by the system clock is incorrect. Typically the problem is that it displays UTC instead of local time. The most common cause is incorrect configuration, although dual booting with Windows will also change the Linux system clock’s time unless either a) Linux is configured to use local time for the hardware clock, or b) Windows is configured to use UTC* and Windows’ time synchronisation with an Internet time server is disabled.

* A change to the Windows Registry is required in order to enable Windows to use UTC for hardware clock time, but even then you may still face problems (see e.g. Force Windows 8 to use UTC when dealing with BIOS clock).

Some terms you need to know: ‘hardware clock’, ‘RTC’ (real-time clock), ‘CMOS clock’ and ‘BIOS clock’ are terms commonly used for the same thing. The hardware clock is non-volatile. ‘system clock’ is the software clock the operating system uses. It is volatile (it is in the kernel). The system clock is normally set from the hardware clock when the operating system boots, taking into account various configuration options. I recommend that you read the manual for the hwclock command, as it explains in detail about clocks in Linux:

# man hwclock

To configure your time zone and clocks correctly, follow the steps below.

If your installation uses the OpenRC init system

  1. Set the time zone:

    1. Specify your time zone in the file /etc/timezone. If you are in Spain, for example, the contents of that file should be ‘Europe/Madrid‘ (without the quotes).

      # nano /etc/timezone

      You can find out which time zones are available by looking in the directory /usr/share/zoneinfo/ and its sub-directories.

    2. Provide the information for your time zone. If you are in Spain, for example, you would enter the following command:

      # cp /usr/share/zoneinfo/Europe/Madrid /etc/localtime

      Note: Some people recommend making /etc/localtime a symlink rather than creating it by copying a file from /usr/share/zoneinfo/, however I recommend copying. You should definitely not use a symlink if /usr is on a different partition (see Ref. 1).

  2. Set the system clock’s time to your local time now (I’ll assume it is 23:54:30 on 21 September 2014 when you press Enter):

    # date 092123542014.30

  3. Specify whether the hardware clock time is UTC:

    # hwclock --utc

    or local time:

    # hwclock --localtime

    It is preferable for the hardware clock time to be in UTC. However, if you dual boot with Windows it is recommended for the hardware clock time to be in local time rather than UTC unless both the following are true: a) the Windows Registry has been configured for hardware clock time in UTC; b) Windows’ time synchronisation with an Internet time server is disabled.

  4. Set the hardware clock’s time by specifying your local time (I’ll assume it is 23:54:50 on 21 September 2014 when you press Enter):

    # rm /etc/adjtime
    # hwclock --set --date="2014-09-21 23:54:50"

    Note: You must specify local time in the above command, even if you intend the hardware clock time to be UTC.

    Note that the third line in /etc/adjtime should be ‘UTC’ if the hardware clock time is in UTC, or ‘LOCAL’ if the hardware clock time is in local time. For example:

    # cat /etc/adjtime
    0.000000 1412038530 0.000000
    1412038530
    UTC

  5. Tell OpenRC whether the hardware clock uses UTC or local time, and to update the hardware clock time from the system clock time at every shutdown (taking into account any time zone difference between the two clocks):

    # nano /etc/conf.d/hwclock

    1. Make clock="UTC" (or clock="local" if you dual boot with Windows and the Windows Registry is not configured to use UTC for hardware clock time).

    2. Make clock_systohc="YES" to adjust the hardware clock time at shutdown based on the software clock time (taking time zone into account). However, you don’t need to bother doing this if your kernel configuration has CONFIG_RTC_SYSTOHC=y and your installation is configured to synchronise the system clock with a NTP time server (see my post Synchronise your Gentoo Linux clock with an Internet time server). You can check if the hardware clock time is being updated from the software clock time (taking time zone into account) by looking at the kernel messages displayed when in verbose mode during shutdown to see if the following message is displayed:

      Setting hardware clock using the system clock [UTC] ...

    3. Make clock_hctosys="YES" to adjust the system clock time at start up based on the hardware clock time (taking time zone into account). However, you don’t need to bother doing this if your kernel configuration has CONFIG_RTC_HCTOSYS=y. You can check by looking at the kernel messages displayed when in verbose mode during boot to see if the following message is displayed:

      Setting system clock using the hardware clock [UTC] ...

  6. Reboot and check everything is working as expected:

    # date
    Tue 30 Sep 01:55:55 BST 2014
    # hwclock
    Tue 30 Sep 2014 01:55:59 BST -0.031877 seconds

    The hwclock command always shows local time, even if you keep your hardware clock in UTC.

  7. Optionally (but I recommend it), configure your installation to synchronise the system clock with an Internet NTP server (see my post Synchronise your Gentoo Linux clock with an Internet time server).

If your installation uses systemd

  1. Set the time zone:

    1. Find out the available time zones:

      # timedatectl list-timezones

    2. Specify your time zone (I’ll assume you are in Spain in this example):

      # timedatectl set-timezone Europe/Madrid

  2. Set the system clock time to your local time (I’ll assume it is 23:54:30 on 21 September 2014 when you press Enter):

    # timedatectl set-time "2014-09-21 23:54:30"

  3. Inform systemd that the hardware clock uses UTC, and set the current UTC in the hardware clock now:

    # timedatectl set-local-rtc 0

    Note that, by default, systemd assumes the hardware clock uses UTC. Although systemd can be configured to assume the hardware clock uses local time, for technical reasons it is not recommended (see man timedatectl and Arch Wiki article Time for an explanation of why this is not advisable).

    Note that the third line in /etc/adjtime should be ‘UTC’ if the hardware clock time is in UTC, or ‘LOCAL’ if the hardware clock time is in local time. For example:

    # cat /etc/adjtime
    0.000000 1412038530 0.000000
    1412038530
    UTC

  4. Reboot and check everything is working as expected:

    $ timedatectl

  5. Optionally (but I recommend it), configure your installation to synchronise the system clock with an Internet NTP server (see my post Synchronising the clock using NTP in Sabayon Linux).

References

[1] Gentoo Forums – how exactly to set timezone in /etc/localtime ?[solved]

Synchronising the clock using NTP in Sabayon Linux

In my previous post I explained how to install Sabayon Linux via the command line from the Sabayon Linux ‘SpinBase’ ISO.

If the system clock in your current installation is not being synchronised with an external time server over the Internet, the simplest way to achieve this is to install the net-misc/ntp package and configure systemd as shown below.

Note that I use net-misc/ntp rather than net-misc/chrony because the latter does not work in my Sabayon Linux installation; after I have configured the Chrony daemon, the command ‘systemctl status chronyd‘ returns the error message ‘Can’t initialise from real time clock, driver not loaded’. Of course, if Chrony happens to be installed and is working fine, you don’t need to do anything at all. But if Chrony is not working correctly and you want to try the ntp daemon instead, before performing the steps below you’ll first need to disable Chrony as explained under ‘Caveat’ at the end of this post.

  1. Install the ntp package:

    # equo install ntp

  2. Enable the ntp daemon so that it starts at boot:

    # systemctl enable ntpd
    # timedatectl set-ntp true

  3. Start the ntp daemon running now:

    # systemctl start ntpd

  4. Check whether the daemon is running:

    # systemctl status ntpd

Below I show the console output for the complete sequence from Step 2 to Step 4 with the command ‘timedatectl status‘ between each step so that you can see the effect. Note that I had previously set the hardware clock time (which, by default, systemd assumes to be UTC) to be the same time as local time. Since BST and UTC do not coincide, clearly both clocks should not both contain 10:06, so watch what happens below once the NTP daemon is launched.

sabayon fitzcarraldo # timedatectl status
      Local time: Mon 2014-09-22 10:06:06 BST
  Universal time: Mon 2014-09-22 09:06:06 UTC
        RTC time: Mon 2014-09-22 10:06:07
        Timezone: Europe/London (BST, +0100)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2014-03-30 00:59:59 GMT
                  Sun 2014-03-30 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2014-10-26 01:59:59 BST
                  Sun 2014-10-26 01:00:00 GMT
sabayon fitzcarraldo # systemctl enable ntpd
ln -s '/usr/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'
sabayon fitzcarraldo # timedatectl status
      Local time: Mon 2014-09-22 10:06:39 BST
  Universal time: Mon 2014-09-22 09:06:39 UTC
        RTC time: Mon 2014-09-22 10:06:39
        Timezone: Europe/London (BST, +0100)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2014-03-30 00:59:59 GMT
                  Sun 2014-03-30 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2014-10-26 01:59:59 BST
                  Sun 2014-10-26 01:00:00 GMT
sabayon fitzcarraldo # timedatectl set-ntp true
sabayon fitzcarraldo # timedatectl status
      Local time: Mon 2014-09-22 10:06:57 BST
  Universal time: Mon 2014-09-22 09:06:57 UTC
        RTC time: Mon 2014-09-22 10:06:58
        Timezone: Europe/London (BST, +0100)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2014-03-30 00:59:59 GMT
                  Sun 2014-03-30 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2014-10-26 01:59:59 BST
                  Sun 2014-10-26 01:00:00 GMT
sabayon fitzcarraldo # systemctl start ntpd
sabayon fitzcarraldo # timedatectl status
      Local time: Mon 2014-09-22 10:07:13 BST
  Universal time: Mon 2014-09-22 09:07:13 UTC
        RTC time: Mon 2014-09-22 09:07:13
        Timezone: Europe/London (BST, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2014-03-30 00:59:59 GMT
                  Sun 2014-03-30 02:00:00 BST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2014-10-26 01:59:59 BST
                  Sun 2014-10-26 01:00:00 GMT
sabayon fitzcarraldo # systemctl status ntpd
ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
   Active: active (running) since Mon 2014-09-22 10:07:11 BST; 23s ago
 Main PID: 2420 (ntpd)
   CGroup: /system.slice/ntpd.service
           └─2420 /usr/sbin/ntpd -g -n

Sep 22 10:07:11 sabayon ntpd[2420]: Listen normally on 5 eth0 fe80::a00:27ff:fe86:21f3 UDP 123
Sep 22 10:07:11 sabayon ntpd[2420]: peers refreshed
Sep 22 10:07:11 sabayon ntpd[2420]: Listening on routing socket on fd #22 for interface updates
Sep 22 10:07:13 sabayon ntpd[2420]: Deferring DNS for 0.gentoo.pool.ntp.org 1
Sep 22 10:07:14 sabayon ntpd[2420]: Deferring DNS for 1.gentoo.pool.ntp.org 1
Sep 22 10:07:15 sabayon ntpd[2420]: Deferring DNS for 2.gentoo.pool.ntp.org 1
Sep 22 10:07:16 sabayon ntpd[2420]: Deferring DNS for 3.gentoo.pool.ntp.org 1
Sep 22 10:07:18 sabayon ntpd_intres[2422]: DNS 0.gentoo.pool.ntp.org -> 85.236.36.4
Sep 22 10:07:18 sabayon ntpd_intres[2422]: DNS 1.gentoo.pool.ntp.org -> 78.46.197.35
Sep 22 10:07:18 sabayon ntpd_intres[2422]: DNS 2.gentoo.pool.ntp.org -> 91.234.160.19
sabayon fitzcarraldo #

Notice that the NTP daemon synchronised the RTC (hardware clock) time to UTC (I had previously set the hardware clock time to be the same as local time to show what would happen when the NTP deamon was launched). That is correct: notice ‘RTC in local TZ: no‘ in the output above, meaning that systemd by default assumes the time in the RTC is UTC.

By the way, in case you’re wondering, the NTP daemon of course synchronises the time in the system clock too. You do not need to worry: the system clock uses the local time of the time zone you previously configured (see my previous post), so the Linux date command and the clock of the Desktop Environment will show you local time by default.

Caveat
Note that I am using the ntp daemon instead of the Chrony daemon or the OpenNTPD daemon. If Chrony happens to be installed and active in your Sabayon Linux installation, before performing any of the above steps you’ll first need to do the following:

  1. Uninstall the Chrony package:

    # equo remove chrony

  2. Disable the Chrony daemon so that it does not start at boot:

    # systemctl disable chronyd
    # timedatectl set-ntp false

  3. Stop the Chrony daemon running now:

    # systemctl stop chronyd

  4. Check whether the daemon is still running:

    # systemctl status chronyd

Change systemd’s binary logging to text logging in Sabayon Linux

systemd logs system messages in a binary file which the developers call a ‘journal’. However, if you would prefer system messages to be logged in a text file, here is how to do it for Sabayon Linux. The steps will probably be similar in other distributions.

1. See what log files currently exist in your installation:

# ls /var/log
anaconda btmp cups faillog kdm.log mysql portage sandbox tallylog Xorg.0.log
boot.log chrony entropy journal lastlog news samba spice-vdagentd wtmp Xorg.0.log.old

Notice that the traditional text log file /var/log/messages is not present. The systemd binary log files are in a sub-directory of /var/log/journal/:

# ls /var/log/journal
5d387e19d28644c5b24f06f8bc6e9b9c
# ls /var/log/journal/5d387e19d28644c5b24f06f8bc6e9b9c
system.journal user-1000.journal

2. Edit the file /etc/systemd/journald.conf and change #Storage=auto to Storage=none

# nano /etc/systemd/journald.conf

3. Install the system logger syslog-ng:

# equo install syslog-ng

If it’s not already installed, install the logrotate package:

# equo install logrotate

4. Enable the service so that it starts the next time you boot:

# systemctl enable syslog-ng.service
ln -s '/usr/lib/systemd/system/syslog-ng.service' '/etc/systemd/system/syslog.service'
ln -s '/usr/lib/systemd/system/syslog-ng.service' '/etc/systemd/system/multi-user.target.wants/syslog-ng.service'

5. Start the service now:

# systemctl start syslog-ng.service

6. Check if the text log file /var/log/messages has been created:

# ls /var/log
anaconda btmp cups faillog kdm.log messages news samba spice-vdagentd wtmp Xorg.0.log.old
boot.log chrony entropy journal lastlog mysql portage sandbox tallylog Xorg.0.log

If you now reboot you’ll see that the text file /var/log/messages is being used to log system messages, and you can view it easily using commands such as cat, more, less, nano or whatever, and search through it using grep etc. Note that the systemd journal service is still running; it is just not logging to a binary file any more and is forwarding system messages to syslog-ng.

Follow

Get every new post delivered to your Inbox.

Join 58 other followers