Bug 645350

Summary:	sys-block/zram-init-3.8: /var/tmp mount service breaks systemd-hostnamed
Product:	Gentoo Linux	Reporter:	Pablo Cholaky <waltercool>
Component:	Current packages	Assignee:	Jason Zaman <perfinion>
Status:	RESOLVED OBSOLETE
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Pablo Cholaky 2018-01-22 11:42:40 UTC

Hi there

Currently using zram /var/tmp mountpoint is currently breaking systemd-hostnamed, making the service to fail exactly as you can check here: https://github.com/kubernetes/minikube/issues/727

It looks like systemd-hostnamed by default has a parameter on it service called PrivateTmp=yes, which writes at /var/tmp/systemd-private-UUID-blabla and zram may be mounted before NetworkManager, making this to take exactly 25s to start (and slowering down the whole init)

The current workaround as mentioned on minikube github, is changing the value of PrivateTmp=no, but it might work to modify /lib/systemd/system/zram_var_tmp.service to wait for network.target, unless you can point some better solution on that.

Thanks!

Summary:

- Get systemd + NetworkManager enabled + zram_var_tmp enabled
- Restart
- Get the annoying systemd-hostnamed error code=exited, status=226/NAMESPACE and 25s delay of the whole init by NetworkManager
- Modify PrivateTmp=yes to PrivateTmp=no at /lib/systemd/system/systemd-hostnamed.service
- Restart
- Init works fine

Comment 1 Pablo Cholaky 2018-01-22 11:54:14 UTC

Just as information, I sent a PR to them with my proposed solution if you want to keep in touch with this.

https://github.com/vaeth/zram-init/pull/11