Bug 83930 - hostnamed should emit PropertyChanged for Hostname property
Summary: hostnamed should emit PropertyChanged for Hostname property
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-16 13:39 UTC by Marius Vollmer
Modified: 2014-10-21 19:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Marius Vollmer 2014-09-16 13:39:29 UTC
systemd 215-14.fc21

It's a bit disappointing that there are no notifications about Hostname changing, not even when it is changed via hostnamed itself.

Maybe hostnamed can use systemtap to get change notifications from the kernel.
Comment 1 David Herrmann 2014-09-16 15:37:41 UTC
hostnamed sets the kernel hostname itself, so there is little reason in tracking it. We don't support other processes setting the kernel hostname directly (and there is little reason for it), but only via hostnamed APIs.

Currently, hostnamed sends dbus notifications for *any* hostname change. That is, if you're interested in a specific hostname, watch those notifications and then either parse them are read the hostname via the gethostname(2) syscall.

Btw., I just noticed that we have the code to send notifications for "Hostname" changes, but we lacked a vtable annotation. I fixed this [1], so you should now get notifications for "Hostname" changes, too.


[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=caffbef636ec48958dcb22e4b4140a9889a6a769
Comment 2 Marius Vollmer 2014-09-17 07:20:32 UTC
(In reply to comment #1)
> Currently, hostnamed sends dbus notifications for *any* hostname change.
> That is, if you're interested in a specific hostname, watch those
> notifications and then either parse them are read the hostname via the
> gethostname(2) syscall.

I only now noticed that gethostname will not always correspond to the Hostname property, at least since c779a442 (released with v213)... Should hostnamed maybe have one more property EffectiveHostname that is guaranteed to have the same value as gethostname?

How can things like the hostname be so complicated? :-)

> Btw., I just noticed that we have the code to send notifications for
> "Hostname" changes, but we lacked a vtable annotation. I fixed this [1], so
> you should now get notifications for "Hostname" changes, too.

Great, I am happy to hear that this was just a bug, and not some fundamental limitation, as I had feared.  Thanks!
Comment 3 David Herrmann 2014-09-17 09:08:16 UTC
(In reply to comment #2)
> I only now noticed that gethostname will not always correspond to the
> Hostname property, at least since c779a442 (released with v213)... Should
> hostnamed maybe have one more property EffectiveHostname that is guaranteed
> to have the same value as gethostname?

We never expose systemd/bus APIs if there is already an API to retrieve the given value. That is, our recommendation is to *always* use gethostname() if you require the effective hostname of your system.

We enforce this policy in quite a lot places, and so far there hasn't been any reason to change this.

> How can things like the hostname be so complicated? :-)

Yeah.. auto-configuration via DHCP makes stuff awfully complicated. What can we do..
Comment 4 Marius Vollmer 2014-09-17 09:58:37 UTC
(In reply to comment #3) 
> Yeah.. auto-configuration via DHCP makes stuff awfully complicated. What can
> we do..


Also, NetworkManager seems to have its own ideas and calls sethostname itself.
Comment 5 Lennart Poettering 2014-10-21 19:23:39 UTC
To watch the system hostname please use poll() on /proc/sys/kernel/hostname. You'll get a wakeup each time the hostname changes and you can reread the new hostname.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.