Re: [systemd-devel] systemd and hostnamed (and nss-myhostname) - an alternative path
On Fri, 29.07.11 06:50, JB (jer...@silentdome.com) wrote: I'm a happy Arch Linux user of systemd. I want to share a few of my thoughts about systemd's interaction with the system hostname. Here's my understanding of how systemd currently sets the hostname * hostnamed is included in the systemd package * During early boot systemd makes a call to hostnamed and the hostname is set to the value in /etc/hostname No. systemd does that on its own. systemd-hostnamed is an optional component which adds a mechanism for UIs (such as GNOME 3.2) to change the hostname, but is otherwise unnecessary to merely initialize it at boot. My proposal for systemd's interaction with the hostname * hostnamed nss-myhostname are packaged together in a 'hostnamed' package Well, one of the reasons why hsotnamed is really small is that it can reuse a lot fo the code we already have in systemd, which makes this easy. There's little point in splitting this off. Packagers can split this off if they wish after compilation, but it doesn't really make a lot of sense to us to split the sources up. * (Wishlist/Off topic) Has any thought been given to having the various ttys and syslogs listen via dbus for a hostname changed signal so they can immediately change the hostname displayed and their log messages. Are there any other apps/daemons that could benefit from doing this? GNOME 3.2 can watch for this, and I have plans teaching Avahi the same. If you want other apps to listen for host name changes, too, then file a bug regarding the respective packages. My reasoning * I have a use case where I need to change the hostname on each boot at boot time. I'm able to do this with a custom 'Set Hostname' unit but my logs always show the hostname from the previous boot because systemd sets it to the value in /etc/hostname before I can change it. I also loose time at boot because hostname is being set twice. If I could just set an ExecStartPre on a systemd provided 'Set Hostname' unit my isues would be solved. systemd initializes the hostname only at boot, so that at all times there is a hostname configured. If you want to change it later you may do so, for example by issuing a bus request to trigger this. hostnamed distuingishes between a static and a transient hostname to make this nice. http://www.freedesktop.org/wiki/Software/systemd/hostnamed Invoke SetHostname() from that interface and the right thing will happen. (You can easily do this via dbus-send) * There is absolutely nothing systemd specific about hostnamed (Correct me if I'm mistaken). Non-systemd distros/users can benefit from hostnamed without hassle if it's maintained outside of the systemd tree Well, we standardize /etc/hostname with this service, which is a configuration file otherwise not known outside Debian. And the key point here is that much of the code hsotnamed internally uses is shared with the rest of systemd. Hence having this in systemd itself is quite easy and can be done with minimal code. If we'd split this off we'd have to duplicate a lot of code and the code of hostnamed would become vastly more complex. Downside to my method * Hostname is set a few milliseconds later in the boot process The point of what we do hostname-setup.c is actually that we initialize it so early that for the entire userspace the hostname is properly initialized (though not necessarily with the 'final' hostname), and we can rely that gethostname() called from userspace always returns a somewhat useful value. Note again that systemd does not monopolize the hostname. It just does an initialization of it, but if it is changed later on this is completely fine. Upsides * Flexibility to support my and yet to be forseen use cases for a dynamic hostname change at boot without effectively setting the hostname twice and having an incorrect hostname in syslog messages Well, if you set the hostname only after setting up the network, then you cannot log any network configuration issues to syslog, can you? Hence: we need a sane hostname configured right from the beginning, which is why systemd does that. You are welcome to later on change it and we make that easy, and send out change notifications. Note again, that in systemd this is designed to initialize the hostname early, and you are welcome to change it, which is why we distuingish the transient and the static hostname. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and hostnamed (and nss-myhostname) - an alternative path
On Fri, 29.07.11 14:20, JB (jer...@silentdome.com) wrote: After browsing through git I think I may have a viable solution to the main issue of not being able to change that hostname before it is set at boot time. Move the logic from hostname-setup.c into hostnamed a hostnamed Sorry, I am not interested in this. We want the hostname initialized to some value very early at boot, so that userspace can rely that the hostname is set at all times, even if that is not the final host name. In most cases it will be the final name, but if in many cases (like the hostname from DHCP usecase) it isn't then this is fine. In your case I'd just recommend removing any configuration of the static hostname entirely. (i.e. remove /etc/hostname and friends). systemd will then just initialize the hostname to localhost. Then, when you know your final hostname, just set it with dbus-send for example. Make a hostnamed --setfromfile option and use in in a set-hostname.service file. But why? That would allow a user (me) to use ExecStartPre or to create another unit and set a Before=set-hostname.service. In this unit I can change the /etc/hostname file before the hostname is set. This is all designed so that writes to /etc are never necessary, (i.e. that dir can be mounted read-only). So, when you figure out your network-based hostname, then set the transient hostname to it, not the static one. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] common RPM spec file?
On Thu, 28.07.11 09:49, Andreas Jaeger (a...@suse.com) wrote: How are other distros packaging systemd? The systemd 31 release now adds devel files, so I consider creating a systemd-devel package. Can we all agree - at least the RPM world - to use the same basic split of systemd in subpackages? In that case we could keep a version in git and use as reference. We have a slightly different split on Fedora, but we'd acttually like to clean this up and merge two of those packages again. Right now on openSUSE we have: * systemd * systemd-gtk * systemd-sysvinit What is this one for? (We used to have one like this, but we dropped that when systemd become the only supported init system in Fedora) * systemd-plymouth Note that we will soon move the Plymouth unit files into Plymouth proper and they will then be removed from systemd. On Fedora we have two further packages: systemd-units: exists mostly for legacy reasons and we hope to fold this back into systemd soon, if we manage to get the upgrade path right. systemd-sysv: contains some compat code which i'd like to get rid of in F17 or so. putting this together we have: systemd systemd-units (will go away) systemd-sysv (will go away) systemd-gtk systemd-devel And I would now introduce * systemd-devel for include files, pkg files and .so link This common usage would make life easier for people developing packages for several distributions that require systemd at build time, So I am wondering about systemd-sysvinit. Otherwise it looks like we'll eventually have the same packaging on Suse and Fedora. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EnvironmentFile being ignored.
On Fri, 29.07.11 20:10, Harald Hoyer (harald.ho...@gmail.com) wrote: On 29.07.2011 17:23, Steve Dickson wrote: On 07/29/2011 11:17 AM, Kay Sievers wrote: On Fri, Jul 29, 2011 at 17:00, Steve Dickson ste...@redhat.com wrote: Doing a 'systemctl show' it appears my EnvironmentFile is being ignored EnvironmentFile=/etc/sysconfig/nfs (ignore=yes) Why is this happening? In the service file is a '-' in front, right? Then the errors are ignored not the file. should maybe display EnvironmentFile=/etc/sysconfig/nfs (ignore_error=yes) Done. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] initctl: support 'telinit u/q'
We send SIGTERM (resp., SIGHUP) when we receive request for changing to
runlevel 'u' (resp., 'q').
As initctl is already async, we just send the signals rather than first
attempting to connect to sytemd over dbus and then falling back to kill.
---
src/initctl.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/src/initctl.c b/src/initctl.c
index dd74314..ea1acd1 100644
--- a/src/initctl.c
+++ b/src/initctl.c
@@ -165,7 +165,24 @@ static void request_process(Server *s, const struct
init_request *req) {
if (!isprint(req-runlevel))
log_error(Got invalid runlevel. Ignoring.);
else
-change_runlevel(s, req-runlevel);
+switch (req-runlevel) {
+
+/* we are async anyway, so just use kill for
reexec/reload */
+case 'u':
+case 'U':
+if (kill(1, SIGTERM) 0)
+log_error(kill() failed: %m);
+break;
+
+case 'q':
+case 'Q':
+if (kill(1, SIGHUP) 0)
+log_error(kill() failed: %m);
+break;
+
+default:
+change_runlevel(s, req-runlevel);
+}
return;
case INIT_CMD_POWERFAIL:
--
1.7.6
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
