Ubuntu 18.04 LTS
Im Januar 2019 habe ich mich zu einem Upgrade von Ubuntu 16.04 LTS auf diese Version entschlossen.
Upgrade
Zunächst habe ich mein Virtualbox mal auf den neuesten Stand gebracht (5.2.22) Virtualbox Guest Extensions wieder installiert. Danach erfolgte der Ubuntu Upgrade (mit apt statt mit apt-get):
sudo bash
apt update && apt dist-upgrade && apt autoremoveDas hat hat ganz gut funktioniert. Abgesehen von
lokalen Änderungen in
/etc/resolvconf/resolv.conf.d/head- habe ich verworfeneinige Third Party Sourcen wurden disabled
meine MySQL Workbench war anschließend weg und ich mußte sie neu installieren
beim Start meines Virtual Box Images erhalte ich die Warnung
failed to connect to lvmetad- ein Problem, das scheinbar viele mit dem 18.04 haben
Danach habe ich die Virtualbox Guest Extensions nochmal installiert, weil ich einen neuen Kernel bei dem Upgrade bekommen habe.
Langsame IO Performance - I/O Scheduler
"Next is the IO scheduler which determines how your operating system is going to talk to the disk. There are different types of IO scheduler with each having various tunables to optimize the IO performance based on your requirement." (golinuxcloud)
Ich konnte bisher immer einen 10 MB großen Dump in meinen MySQL-Docker Container schnell einspielen (15 Sekunden) - z. B. beim Hochfahren der MySQL Instanz. Nach dem Upgrade dauerte es ewig (60 Sekunden) - ähnlich wie dieser Benutzer ... der I/O Scheduler (/sys/block/sda/queue/scheduler - wird pro Device konfiguriert ... hier sda) scheint große Unterschiede zu machen:
cfq: 60 Sekundencfg = completely fair queuing
"CFQ and deadline, are impossible to suggest specific use cases for. The reason for this is that the exact behaviour depends on both the Linux kernel you’re using and the associated workload. There are kernel versions where CFQ has terrible performance, and deadline is clearly better because of bugs in the CFQ implementation in that version. In other situations, deadline will add latency exactly the opposite of what people expect when the system has a high level of concurrency. And you’re not going to be able to usefully compare them with any simple benchmark. The main differences between CFQ and deadline only show up when there are many concurrent read and write requests fighting for disk time. Which is optimal is completely dependent on that mix." (golinuxcloud)
deadline: ???noop: 15-20 Sekunden"The noop scheduler, which just pushes data quickly toward the hardware, can improve performance if your hardware has its own large cache to worry about." (golinuxcloud)
"Avoid using the none/noop I/O schedulers for a HDD as sorting requests on block addresses reduce the seek time latencies and neither of these I/O schedulers support this feature." ((Linux I/O schedulers)[https://wiki.ubuntu.com/Kernel/Reference/IOSchedulers])
es gibt prinzipiell noch weitere, aber nicht in meiner Ubuntu Distribution
Interessanterweise hatte die Einstellung auf meine Maven-Builds keinen Einfluss (bei einem 8 Minuten Build ohne Tests) - vermutlich, weil dies vergleichsweise (im Vergleich zum Dump-Restore) wenig I/O.
Temporär kann man die Einstellung als root per echo noop > /sys/block/sda/queue/scheduler verändern.
Eine permanente Änderung erfolgt in Grub als Kernel Parameter:
in
/etc/default/grubdieGRUB_CMDLINE_LINUX_DEFAULTanpassen: z. B.elevator:sda=noopsudo update-grub
Netzwerk-Konfiguration
Ubuntu verwendet per Default in einem Ubuntu-Server systemd-networkd als Netzwerkmanager - die dazu passende CLI ist networkctl. In einem Ubuntu-Desktop-System ist es hingegen der network-manager. Daneben kann man sich aber auch für andere DNS-Resolver bzw. -Server wie dnsmqsq oder bind entscheiden.
systemd-networkd und network-manager bilden das Backend für netplan ... in der Konfiguration (/etc/netplan/foo.yaml) wählt man renderer: NetworkManager oder renderer: networkd aus. Als Alternative zu netplan kann man /etc/network/interfaces verwenden ... hierzu muss man netplan deaktivieren.
Wegen der Seiteneffekte kann ist diese Konfiguration mit gewissen Hürden verbunden.
systemd-networkd
Neben systemd-networkd wird auch noch der systemd-resolved Dienst gestartet, der auf der IP-Adresse 127.0.0.53 und Port 53 lauscht. Er ist für die Namensauflösung zuständig.
systemd-networkd -Dummy-Interface einrichten
network-manager
Wechsel von networkd zu network-manager
disable und stop von
systemd-networkddurch
systemctl disable systemd-networkd.service
systemctl stop systemd-networkd.servicedisable und stop von
systemd-resolveddurch ... wenn dadurch der Port 53 nicht freigegeben wird hilf vielleicht dieser Link
systemctl disable systemd-resolved.service
systemctl stop systemd-resolved.serviceinstall
network-manager(apt install network-manager)configure
netplanto useNetworkManager
FAQ
Frage 1: Ich verwende NAT und im Homeoffice über VPN habe ich immer wieder Probleme Hostnamen aus dem Private Network aufzulösen. Nicht immer, aber irgendwann passiert es dann mal und dann muß ich die Netzwerkverbindung neu initialisieren (sudo systemctl stop systemd-resolved && sudo systemctl start systemd-resolved). Was ist das Problem?
Antwort 1: Der systemd-resolved ist ein DNS-Cache, den Ubuntu im Zusammenhang mit systemd-networkd verwendet. Deshalb ist der Prozess auch an den Port 53 (IANA-Port für DNS) auf Deinem System gebunden. Bei einem netstat -taupen | grep 53 bekomme ich folgende Ausgabe:
3:tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 102 410742 28695/systemd-resolDie Konfiguration ist unter /etc/systemd/resolved.conf zu finden ... wenn man daran etwas ändert muß man den Service per systemctl restart systemd-resolved neu starten. Hier findet man einen guten Artikel. Eine Anpassung von /etc/systemd/resolved.conf wie in den Antworten geschrieben hat noch nicht geholfen.. Schau mal in /var/log/syslog, ob da was zu finden ist.
Frage 2: Mein System scheint immer mal wieder einzufrieren ... es wird der Login-Screen gezeigt und nach erfolgreichem Login erhalte ich einen einfarbigen dunklen Bildschirm. Im /var/log/syslog sehe ich
Jan 14 08:37:06 workbench kernel: [ 3540.582228] INFO: rcu_sched detected stalls on CPUs/tasks:
Jan 14 08:37:06 workbench kernel: [ 3540.582237] 0-...!: (1 GPs behind) idle=e8c/0/0 softirq=16644/16644 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582240] 1-...!: (4 GPs behind) idle=82c/0/0 softirq=17176/17176 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582242] 2-...!: (8 GPs behind) idle=ca0/0/0 softirq=20991/20992 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582244] 3-...!: (1 GPs behind) idle=1a0/0/0 softirq=22994/22994 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582247] 4-...!: (12 GPs behind) idle=9f4/0/0 softirq=21277/21277 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582249] 5-...!: (12 GPs behind) idle=74c/0/0 softirq=18478/18478 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582251] 7-...!: (1 GPs behind) idle=1c8/0/0 softirq=32111/32112 fqs=0
Jan 14 08:37:06 workbench kernel: [ 3540.582252] (detected by 6, t=53708 jiffies, g=20124, c=20123, q=6)
Jan 14 08:37:06 workbench kernel: [ 3540.582256] Sending NMI from CPU 6 to CPUs 0:
Jan 14 08:37:06 workbench kernel: [ 3540.582315] NMI backtrace for cpu 0 skipped: idling at native_safe_halt+0x12/0x20
Jan 14 08:37:06 workbench kernel: [ 3540.583261] Sending NMI from CPU 6 to CPUs 1:
Jan 14 08:37:06 workbench kernel: [ 3540.583311] NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0x12/0x20
Jan 14 08:37:06 workbench kernel: [ 3540.584349] Sending NMI from CPU 6 to CPUs 2:
Jan 14 08:37:06 workbench kernel: [ 3540.585016] systemd[1]: systemd-logind.service: Watchdog timeout (limit 3min)!
Jan 14 08:37:06 workbench kernel: [ 3540.585030] systemd[1]: systemd-logind.service: Killing process 1155 (systemd-logind) with signal SIGABRT.
Jan 14 08:37:06 workbench kernel: [ 3540.588064] NMI backtrace for cpu 2
Jan 14 08:37:06 workbench kernel: [ 3540.588065] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G C E 4.15.0-62-generic #69-Ubuntu
Jan 14 08:37:06 workbench kernel: [ 3540.588066] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jan 14 08:37:06 workbench kernel: [ 3540.588066] RIP: 0010:reschedule_interrupt+0x0/0xa0
Jan 14 08:37:06 workbench kernel: [ 3540.588067] RSP: 0018:ffff9e18c318be58 EFLAGS: 00000046
Jan 14 08:37:06 workbench kernel: [ 3540.588068] RAX: ffffffff853bb0f0 RBX: 0000000000000002 RCX: 0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588068] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588069] RBP: ffff9e18c318be80 R08: ffffffffffffffff R09: 0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588069] R10: 0000000000000000 R11: 00000000000007c0 R12: 0000000000000002
Jan 14 08:37:06 workbench kernel: [ 3540.588070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588071] FS: 0000000000000000(0000) GS:ffff8bbcbfe80000(0000) knlGS:0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588071] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 14 08:37:06 workbench kernel: [ 3540.588072] CR2: 00007fc43b9be4f0 CR3: 0000000067e0a005 CR4: 00000000000606e0
Jan 14 08:37:06 workbench kernel: [ 3540.588072] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 14 08:37:06 workbench kernel: [ 3540.588073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 14 08:37:06 workbench kernel: [ 3540.588073] Call Trace:
Jan 14 08:37:06 workbench kernel: [ 3540.588073] ? native_safe_halt+0x12/0x20
Jan 14 08:37:06 workbench kernel: [ 3540.588074] default_idle+0x20/0x100
Jan 14 08:37:06 workbench kernel: [ 3540.588074] arch_cpu_idle+0x15/0x20
Jan 14 08:37:06 workbench kernel: [ 3540.588075] default_idle_call+0x23/0x30
Jan 14 08:37:06 workbench kernel: [ 3540.588075] do_idle+0x172/0x1f0
Jan 14 08:37:06 workbench kernel: [ 3540.588075] cpu_startup_entry+0x73/0x80
Jan 14 08:37:06 workbench kernel: [ 3540.588076] start_secondary+0x1ab/0x200
Jan 14 08:37:06 workbench kernel: [ 3540.588076] secondary_startup_64+0xa5/0xb0
Jan 14 08:37:06 workbench kernel: [ 3540.588076] Code: 48 89 3c 25 f8 3f 00 00 65 48 8b 24 25 98 5b 01 00 57 e8 c4 08 00 00 e9 eb e4 ff ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 <0f> 1f 00 68 02 ff ff ff fc f6 44 24 10 03 74 10 0f 01 f8 0f 1fDann hilft nur ein Reboot ...
Beobachtungen:
passiert nur, wenn das Host-System (meiner VirtualBox) gesperrt ist (Win-L)
manchmal verliere ich kurzzeitig die WLAN-Verbindung
Ich habe auch schon sowas gesehen:
Jan 14 11:50:08 workbench kernel: [10946.514078] clocksource: timekeeping watchdog on CPU6: Marking clocksource 'tsc' as unstable because the skew is too large:
Jan 14 11:50:08 workbench kernel: [10946.514079] clocksource: 'kvm-clock' wd_now: 9f7fd12d7b9 wd_last: 25fd713400f mask: ffffffffffffffff
Jan 14 11:50:08 workbench kernel: [10946.514080] clocksource: 'tsc' cs_now: 17ecc61b7c15 cs_last: 5b2d10ee003 mask: ffffffffffffffff
Jan 14 11:50:08 workbench kernel: [10946.514081] tsc: Marking TSC unstable due to clocksource watchdog
Jan 14 11:50:08 workbench kernel: [10946.514510] 03:01:35.931255 timesync vgsvcTimeSyncWorker: Radical host time change: 8 398 702 000 000ns (HostNow=1 578 999 013 139 000 000 ns HostLast=1 578 990 614 437 000 000 ns)
Jan 14 11:50:08 workbench kernel: [10946.514551] 03:01:35.931323 timesync vgsvcTimeSyncWorker: Radical guest time change: 8 353 359 671 000ns (GuestNow=1 578 999 008 454 132 000 ns GuestLast=1 578 990 655 094 461 000 ns fSetTimeLastLoop=false)
Jan 14 11:50:08 workbench systemd-resolved[7909]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 10.....
Jan 14 11:50:08 workbench systemd[1]: Starting Daily apt download activities...Frage 2: Nach der Deinstallation von Python (der Default war noch Python 2 und ich wollte nur noch Python 3 haben) stellte mein "Gnome Terminal" nicht mehr die Optionen "Split Horizontally" und "Split Vertically" zur Verfügung. Natürlich konnte ich das nicht direkt auf die Deinstallation (apt-get remove python) zurückführen, sondern zweifelte an meinem Verstand. Jedenfalls war das meine gewohnte Terminalwelt und plötzlich funktionierte es nicht mehr. Letztlich griff ich auf ein Backup meiner VirtualBox zurück (glücklicherweise nur eine Woche alt), um die Funktion zumindest mal wieder zu sehen. Scheinbar war ich doch nicht verrückt geworden. Was war passiert?
Antwort 2: So genau hatte ich mich bisher nicht damit auseinandergesetzt wie mein Terminal funktionierte. Ich kann mich auch nicht erinnern, daß ich das mal so konfiguriert hatte. Vielleicht war das eine Default-Konfiguration, die der Windowmanager awesome mitbrachte. Jedenfalls fand ich raus, daß auf meinem System der Prozess /usr/bin/python /usr/bin/x-terminal-emulator lief. Scheinbar ist der x-terminal-emulator (ein paar weitere Informationen) für diese beiden Features zuständig. Da ich aber leider python deinstalliert hatte, konnte das wohl nicht mehr funktionieren. Leider bekam ich beim Start meines Terminal mit "CMD-RETURN" keine Fehlermeldung, sondern einfach ein anderes Terminal, das diese Features nicht hatte :-(
Auf meinem Ubuntu 20.04 LTS (das ich vor Wochen schon mal installiert hatte - ohne es wirklich zu benutzen) war auch schon awesome installiert, aber der x-terminal-emulator ... dementsprechend fehlten dort auch die Features :-(
Last updated
Was this helpful?