Ubuntu Core 18: Error message after disabling ssh

device
1

Hey there!

Before deploying an Ubuntu Core 18 device, I sometimes disable ssh.
https://docs.ubuntu.com/core/en/reference/core-configuration
snap set core service.ssh.disable=true

However, now I noticed that after disabling ssh, an error is printed continuously on my serial console:

Traceback (most recent call last):
File “/usr/share/subiquity/console-conf-write-login-details”, line 25, in
sys.exit(write_login_details_standalone())
File “/usr/share/subiquity/console_conf/controllers/identity.py”, line 184, in write_login_details_standalone
write_login_details(sys.stdout, owner[‘username’], ips)
File “/usr/share/subiquity/console_conf/controllers/identity.py”, line 153, in write_login_details
sshcommands=sshcommands, host_key_info=host_key_info(), tty_name=tty_name, first_ip=first_ip, version=version))
File “/usr/share/subiquity/console_conf/controllers/identity.py”, line 119, in host_key_info
longest_type = max([len(keytype) for keytype, _ in fingerprints])
ValueError: max() arg is an empty sequence

The error in itself does not seem to create any problems, but I’m worrying that this could perhaps fill the disk space (log files) on my devices, which are already deployed in the field.

Can the error message be ignored, or is it a problem that can cause my memory cards to become full?

2

unless you enabled persistent logging it will not do any harm … note that core18 comes with rsyslog removed and only uses journald which by default logs to a ringbuffer in ram.

(nontheless you should probably file a bug against subiquity via https://bugs.launchpad.net/ubuntu/+source/subiquity/+filebug )

1 Like
3

Thank you for your quick reply, Oliver.
I did not manually enable any logging feature, so this will hopefully be no problem.

I will get right to it and create a bug report for subiquity. Thank you for linking the Launchpad page.

So if I get this correctly, logging (syslog etc) is disabled by default in core18? Is this documented somewhere?

EDIT:

4

no, logging still happens … in Ubuntu Core 16 rsyslog and journald were installed in parallel by default but since this means duplication rsyslog was removed from the image for Ubuntu Core 18.

journald is still there but logs to a ringbuffer in ram by default unless you explicitly create the /var/log/journal directory, then it will start logging inside this dir.

if you want to collect logs over the net on a central logging server you can also follow:

5

Ahh, ok, thank you for your clarification.
I’ve got another question: how much memory does journald use at most?

https://www.freedesktop.org/software/systemd/man/journald.conf.html states:

SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.

The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G.

My ‘manpage reading skills’ are not that good, so does journald not use more than 10% RAM in core18? As far as I can see, core18 uses default values. There are no overwrites in /etc/systemd/journald.conf

6

the non-persistent logs live by default in /run/log/journal/.

/run uses a max of 10% of your ram by default, so the log ringbuffer size being 10% of the underlying filesystem is set to a maximum of 1% of your ram…

7

Thanks for the explanation :slight_smile: