setting the hostname is not persistent accross reboots

Bug #1418966 reported by Michael Vogt on 2015-02-06
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Snappy
Undecided
James Hunt

Bug Description

Setting the hostname works fine, /etc/hostanme is update but after a reboot "hostname" output the wrong value "localhost". /etc/hostname is still correct.

Might be that something (systemd?) read /etc/hostname too early, i.e. before the writable paths are merged.

Steps from Daniel Watkins to reproduce:
"""
$ kvm -m 512 -redir :8090::80 -redir :8022::22 <image> &

$ ssh-copy-id -p 8022 localhost ubuntu@localhost
...

$ ssh -p 8022 ubuntu@localhost hostname
localhost.localdomain

$ ssh -p 8022 ubuntu@localhost cat /etc/hostname
localhost.localdomain

$ echo test | ssh -p 8022 ubuntu@localhost sudo tee /etc/hostname
test

$ ssh -p 8022 ubuntu@localhost sudo hostname -F /etc/hostname

$ ssh -p 8022 ubuntu@localhost hostname
test

$ ssh -p 8022 ubuntu@localhost sudo reboot
sudo: unable to resolve host test

$ ssh -p 8022 ubuntu@localhost hostname
localhost.localdomain

$ ssh -p 8022 ubuntu@localhost cat /etc/hostname
test
"""

Related branches

Michael Vogt (mvo) wrote :

My theory for this is behavior is:
- /etc/hostname is a overlay in /writable/system-data/etc/writable/hostname
- on boot our initramfs hook prepares the /etc/fstab that contains the mount for /etc/hostname but does not mount it (this is for systemd) so /etc/hostname contains "localhost"
- when systemd runs it calls hostname_setup() in main.c:1563, the olverlay is not mounted yet so it uses the old "localhost"
- and then runs into its main loop where it executes the units to mount the overlay

James Hunt (jamesodhunt) wrote :

I think Michael is correct - since /etc/hostname is mounted from /etc/writable, if you do the following, you'll see the original version of the file:

$ cat /etc/hostname
foo
$ sudo umount /etc/writable
$ cat /etc/hostname
localhost.localdomain

One solution would be to have a systemd unit reset the hostname after processing the fstab entries (or delay hostnamed from starting until all the mounts have completed).

Steve Langasek (vorlon) wrote :

> One solution would be to have a systemd unit reset the hostname after
> processing the fstab entries (or delay hostnamed from starting until all
> the mounts have completed).

Yes, one or the other is definitely what should be done here.

James Hunt (jamesodhunt) on 2015-02-27
Changed in snappy-ubuntu:
assignee: nobody → James Hunt (jamesodhunt)
Martin Pitt (pitti) wrote :

For the record, I'd prefer mounting everything in /etc from the initramfs. That's its purpose after all -- prepare the root file system. Anything else is racy and involves doing more work during boot.

James Hunt (jamesodhunt) wrote :

Well, the initrd as a minimum needs to mount the rootfs r/o (which of course we are doing).

I understand the concern, but if we pile everthing into the initramfs, we increase the likelihood of a system failing to boot (either due to a buggy code path, or maybe something like an fsck failing [or even just taking a very long time to complete]). For IoT devices, that sort of failure scenario just isn't an option. We might be able to partially mitigate it through careful and thorough testing, but I think we'd end up having to implement things that userland already provides.

By keeping the initrd sleek and minimal, we get to leverage all the features in userspace that aren't available to the initrd.

I think this needs a lot of further discussion as there are good arguments on both sides. Maybe we're getting to the point where we need to consider: http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/...?

James Hunt (jamesodhunt) wrote :

The current plan is to create a system unit that contains essentially:

__________

[Unit]
Description=Set the hostname to the value stored on the writable partition
After=etc-writable.mount
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/bin/hostname -F /etc/hostname
__________

That will set the hostname (again) to the correct value by using the hostname file from the writable partition.

RISK: There is admittedly the possibility that if a service starts before all the mounts have been handled, that it will see the hostname as "localhost.localdomain".

James Hunt (jamesodhunt) on 2015-02-27
Changed in snappy-ubuntu:
status: New → In Progress

On Fri, Feb 27, 2015 at 03:47:31PM -0000, James Hunt wrote:
> The current plan is to create a system unit that contains essentially:

> [Unit]
> Description=Set the hostname to the value stored on the writable partition
> After=etc-writable.mount
> DefaultDependencies=no

<snip>

> That will set the hostname (again) to the correct value by using the
> hostname file from the writable partition.

> RISK: There is admittedly the possibility that if a service starts
> before all the mounts have been handled, that it will see the hostname
> as "localhost.localdomain".

Where does systemd currently do the setting of the hostname? I would have
expected this unit to include a 'Before=hostnamery' rule to enforce the
sequencing of etc-writable.mount and initial hostname setting, instead of
re-setting the hostname. But maybe the hostname is handled entirely
internally to systemd, and we have no way to insert a sequence point there?

Martin Pitt (pitti) wrote :

Steve Langasek [2015-02-27 19:52 -0000]:
> Where does systemd currently do the setting of the hostname?

It's not a unit, it's done right in the daemon before starting units.
It's more or less just sethostname(/etc/hostname).

> we have no way to insert a sequence point there?

James' unit is pretty much such a sequence point, i. e. the same way
we handle it in upstart (externally with an explicit job). So in
principle we get the same race condition as under upstart, but I
suppose it's not a practical problem if you do it early enough.

Bart van Kleef (bkleef) wrote :

Any idea when the merge will be accepted? Looks great to me!

Alexander Sack (asac) wrote :

james, let us know what is blocking; if not lets land it...

James Hunt (jamesodhunt) wrote :

I believe we're waiting for an ack on the current approach.

Martin Pitt (pitti) wrote :

I'm not sure if you are blocking on me (I wasn't aware of that), but I commented on the MP just in case.

Michael Vogt (mvo) on 2015-03-31
Changed in snappy-ubuntu:
status: In Progress → Fix Committed
Michael Vogt (mvo) on 2015-04-29
Changed in snappy-ubuntu:
status: Fix Committed → Fix Released
Michael Terry (mterry) on 2015-05-18
affects: snappy-ubuntu → snappy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers