Re: [systemd-devel] networkd losing dhcp lease with dracut / nfs root
Hi Rich, Your analysis is correct. networkd is not updating the lft. We should change two things: dracut (or whatever is being used on your machine) should set an infinite lifetime when using NFS root (IMHO), and networkd should update the lft (and in particular force-set it to infinite if CriticalConnection is being used). The latter is on my TODO. Cheers, Tom On Sat, Jun 28, 2014 at 5:19 AM, Rich Freeman r-syst...@thefreemanclan.net wrote: I'm running systemd-212 and dracut-037, on a diskless box with an nfs root and pxe boot. After a number of updates I noticed that the box would freeze up after 24h uptime - almost exactly. This behavior is the same whether I have systemd-networkd running or not (it is configured to set up any interface matching e* with dhcp). I traced this to the dhcp lease time - if I set the lease to 10min the box freezes in 10min, with errors spewing to the network console shortly after about not being able to reach the nfs server. After some research, I suspect it is the result of: https://bugzilla.redhat.com/show_bug.cgi?id=1097523 I monitored the box more closely and discovered that with a 10 minute lease the box is renewing the lease after 5 minutes. However, if I run watch ip addr the box counts down the valid_lft from 600 seconds down to 1 second with no change after 5 minutes. If I disable systemd-networkd then the box doesn't renew the lease at all, and valid_lft counts down just the same. I suspect that systemd-networkd is renewing the lease but not updating the valid_lft on the interface, and thus after the original lease expires the kernel brings it down. The only other thing that is odd is that my interface has two IPs assigned, and I have no idea where one is coming from: 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:01:2e:31:04:dc brd ff:ff:ff:ff:ff:ff inet 200.0.0.0/24 brd 200.0.0.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.0.10/24 brd 192.168.0.255 scope global dynamic eth0 valid_lft 220sec preferred_lft 220sec inet6 fe80::201:2eff:fe31:4dc/64 scope link valid_lft forever preferred_lft forever Clearly systemd-networkd is managing 192.168.0.10: Jun 27 23:12:43 mythliv2 systemd-networkd[442]: eth0: link is up Jun 27 23:12:43 mythliv2 systemd-networkd[442]: eth0: carrier on Jun 27 23:12:43 mythliv2 systemd[1]: Started Network Service. Jun 27 23:12:43 mythliv2 systemd-networkd[442]: eth0: DHCPv4 address 192.168.0.10/24 via 192.168.0.101 Jun 27 23:12:43 mythliv2 systemd-networkd[442]: eth0: link configured I'm not sure where the other IP is coming from - it shows up even if I don't enable systemd-networkd, so perhaps dracut is setting it up. I'm not sure if its valid_lft of forever is causing any confusion though. My network config: [Match] Name=e* [Network] DHCP=yes [DHCPv4] CriticalConnection=yes (I get the same behavior if I drop the CriticalConnection=yes) Any thoughts as to what is going wrong here? I'm happy to test patches/etc. Rich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: When exiting with an error, make the error code meaningful.
This is accomplished by having the return value of wait_for_container be
interpreted as a negative version of the exit status code.
---
src/nspawn/nspawn.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0a8dc0c..0c89c40 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2662,7 +2662,7 @@ static int wait_for_container(pid_t pid, ContainerStatus
*container) {
switch (status.si_code) {
case CLD_EXITED:
-r = status.si_status;
+r = -status.si_status;
if (r == 0) {
if (!arg_quiet)
log_debug(Container %s exited successfully.,
@@ -2672,7 +2672,6 @@ static int wait_for_container(pid_t pid, ContainerStatus
*container) {
} else {
log_error(Container %s failed with error code %i.,
arg_machine, status.si_status);
-r = -1;
}
break;
@@ -2699,13 +2698,13 @@ static int wait_for_container(pid_t pid,
ContainerStatus *container) {
case CLD_DUMPED:
log_error(Container %s terminated by signal %s.,
arg_machine, signal_to_string(status.si_status));
-r = -1;
+r = -EXIT_FAILURE;
break;
default:
log_error(Container %s failed due to unknown reason.,
arg_machine);
-r = -1;
+r = -EXIT_FAILURE;
break;
}
@@ -3296,11 +3295,10 @@ check_container_status:
/* Redundant, but better safe than sorry */
kill(pid, SIGKILL);
-r = wait_for_container(pid, container_status);
+r = -wait_for_container(pid, container_status);
pid = 0;
-if (r 0) {
-r = EXIT_FAILURE;
+if (r 0) {
break;
} else if (container_status == CONTAINER_TERMINATED)
break;
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] nspawn: When exiting with an error, make the exit code meaningful.
These two patches both do the same thing, in slightly different ways. They fix a regression intruduced in commit 113cea8 (present in v213 and 214) where the exit status of nspawn does not reflect the exit status of the containered process. Happy hacking, ~ Luke Shumaker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: When exiting with an error, make the error code meaningful.
This is accomplished by having wait_for_container() return a positive error
code when we would like that error code to make its way to the user. This
is at odds with the CODING_STYLE rule that error codes should be returned
as negative values.
---
src/nspawn/nspawn.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 0a8dc0c..42f939b 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2645,12 +2645,17 @@ static int change_uid_gid(char **_home) {
}
/*
- * Return 0 in case the container is being rebooted, has been shut
- * down or exited successfully. On failures a negative value is
- * returned.
+ * Return values:
+ * 0 : The container was terminated by a signal, or failed for an
+ * unknown reason. No change is made to the container argument.
+ * 0 : The container terminated with an error code, which is the
+ * return value. No change is made to the container argument.
+ * 0 : The container is being rebooted, has been shut down or exited
+ * successfully. The container argument has been set to either
+ * CONTAINER_TERMINATED or CONTAINER_REBOOTED.
*
- * The status of the container CONTAINER_TERMINATED or
- * CONTAINER_REBOOTED will be saved in the container argument
+ * That is, success is indicated by a return value of zero, and an
+ * error is indicated by a non-zero value.
*/
static int wait_for_container(pid_t pid, ContainerStatus *container) {
int r;
@@ -2672,7 +2677,6 @@ static int wait_for_container(pid_t pid, ContainerStatus
*container) {
} else {
log_error(Container %s failed with error code %i.,
arg_machine, status.si_status);
-r = -1;
}
break;
@@ -3299,8 +3303,9 @@ check_container_status:
r = wait_for_container(pid, container_status);
pid = 0;
-if (r 0) {
-r = EXIT_FAILURE;
+if (r != 0) {
+if (r 0)
+r = EXIT_FAILURE;
break;
} else if (container_status == CONTAINER_TERMINATED)
break;
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Multiple template parameters for one service
Hi all, I am at the moment trying to clean up my units to write some simple ones that I just have to link without hardcoding anything in them but am stuck at this issue: what to do if my unit requires multiple parameters? E.g. Using unison to sync files, the different variables I have to use are: local user and profile file (an optional variable would be the server). It is at the moment not possible to write a unit file that would understand so many things with just a simple '@'. I could use an extra configuration file in /etc/systemd/system every time I want to use unison, but it's not really nice and clean (one file per unison profile...). Some people would object that I can have a bash script do the job of translating what is behind the '@' into my many arguments: not really nice either. An idea would be to use units with many '@' or have systemd interpret the string between '@' and '.service' as '@'-separated values (e.g. unison@local_user@profile.service). The feature could also help by including some optional arguments (e.g. the server information in unison is not necessary for it to work but could help if I use a service to check if the server is online beforehand: unison@local_user@profile@server.service). Cheers, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple template parameters for one service
You could just use /etc/systemd/system/unison@instance.service.d/ directory to provide service environment variables, this seems to be much more convenient way to configure service. Best regards, Alexander 2014-06-29 0:15 GMT+08:00 Moviuro movi...@gmail.com: Hi all, I am at the moment trying to clean up my units to write some simple ones that I just have to link without hardcoding anything in them but am stuck at this issue: what to do if my unit requires multiple parameters? E.g. Using unison to sync files, the different variables I have to use are: local user and profile file (an optional variable would be the server). It is at the moment not possible to write a unit file that would understand so many things with just a simple '@'. I could use an extra configuration file in /etc/systemd/system every time I want to use unison, but it's not really nice and clean (one file per unison profile...). Some people would object that I can have a bash script do the job of translating what is behind the '@' into my many arguments: not really nice either. An idea would be to use units with many '@' or have systemd interpret the string between '@' and '.service' as '@'-separated values (e.g. unison@local_user@profile.service). The feature could also help by including some optional arguments (e.g. the server information in unison is not necessary for it to work but could help if I use a service to check if the server is online beforehand: unison@local_user@profile@server.service). Cheers, -- Moviuro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple template parameters for one service
On Sunday 29 June 2014 00:21:33 you wrote: You could just use /etc/systemd/system/unison@instance.service.d/ directory to provide service environment variables, this seems to be much more convenient way to configure service. I can't do that because different users may have the same profile name (and thus the same configuration folder). (I wanted to avoid it but, here is the unit) [Unit] Description=Unison sync for profile PROFILE Requires=reachable-retry@SERVER.service After=reachable-retry@SERVER.service [Service] User=LOCAL_USER ExecStart=/usr/bin/unison -auto -silent PROFILE I can't put the full path to the PROFILE as unison@/path/to/profile.service because I can't put '/' in a file name. Cheers, -- Moviuro signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple template parameters for one service
On Sat, Jun 28, 2014 at 06:15:58PM +0200, Moviuro wrote: Hi all, I am at the moment trying to clean up my units to write some simple ones that I just have to link without hardcoding anything in them but am stuck at this issue: what to do if my unit requires multiple parameters? Hi, systemd is kind of built around the idea of a single instance parameter... Allowing multiple would be convenient, but would require much more complexity, and a rewriting of a lot of internals. I don't think this is going to happen. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Multiple template parameters for one service
%I specifier unescapes instance name, so unison@path-to-profile.service instance becomes path/to/profile Best regards, Alexander 2014-06-29 0:31 GMT+08:00 Moviuro movi...@gmail.com: On Sunday 29 June 2014 00:21:33 you wrote: You could just use /etc/systemd/system/unison@instance.service.d/ directory to provide service environment variables, this seems to be much more convenient way to configure service. I can't do that because different users may have the same profile name (and thus the same configuration folder). (I wanted to avoid it but, here is the unit) [Unit] Description=Unison sync for profile PROFILE Requires=reachable-retry@SERVER.service After=reachable-retry@SERVER.service [Service] User=LOCAL_USER ExecStart=/usr/bin/unison -auto -silent PROFILE I can't put the full path to the PROFILE as unison@/path/to/profile.service because I can't put '/' in a file name. Cheers, -- Moviuro ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: do not check btrfs and xfs
fsck.btrfs and fsck.xfs are documented to return immediately, so there is
little sense in running them. Avoids some user confusion and a few lines
in the logs.
https://bugzilla.redhat.com/show_bug.cgi?id=1098799
---
man/systemd-f...@.service.xml | 15 ---
src/fstab-generator/fstab-generator.c | 23 ++-
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml
index ee66f3712d..1e9975f426 100644
--- a/man/systemd-f...@.service.xml
+++ b/man/systemd-f...@.service.xml
@@ -69,14 +69,15 @@
all other file systems and for the root file system in
the initramfs./para
-paraThose services are started at boot if
-optionpassno/option in
+paraThose services are started at boot for the root
+file system or when optionpassno/option in
filename/etc/fstab/filename for the file system is
-set to a value greater than zero. The file system
-check for root is performed before the other file
-systems. Other file systems may be checked in
-parallel, except when they are one the same rotating
-disk./para
+set to a value greater than zero, except for file
+system types like btrfs and xfs which are checked by
+the kernel. The check for root is performed before the
+other file systems. Other file systems may be checked
+in parallel, except when they are one the same
+rotating disk./para
parafilenamesystemd-fsck/filename does not know
any details about specific filesystems, and simply
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 1256a1ce53..4dad82d425 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -165,6 +165,14 @@ static bool mount_in_initrd(struct mntent *me) {
streq(me-mnt_dir, /usr);
}
+static bool mount_skip_fsck(const char *fstype) {
+static const char table[] =
+btrfs\0
+xfs\0;
+
+return fstype nulstr_contains(table, fstype);
+}
+
static int add_mount(
const char *what,
const char *where,
@@ -377,6 +385,7 @@ static int parse_fstab(bool initrd) {
else {
bool noauto, nofail, automount;
const char *post;
+int check;
noauto = !!hasmntopt(me, noauto);
nofail = !!hasmntopt(me, nofail);
@@ -393,6 +402,13 @@ static int parse_fstab(bool initrd) {
else
post = SPECIAL_LOCAL_FS_TARGET;
+check = me-mnt_passno;
+if (check mount_skip_fsck(me-mnt_type)) {
+log_warning(No need to check %s, type %s.
Ignoring fstab passno.,
+what, me-mnt_type);
+check = 0;
+}
+
k = add_mount(what,
where,
me-mnt_type,
@@ -415,6 +431,7 @@ static int parse_fstab(bool initrd) {
static int add_root_mount(void) {
_cleanup_free_ char *what = NULL;
const char *opts;
+int check;
if (isempty(arg_root_what)) {
log_debug(Could not find a root= entry on the kernel
commandline.);
@@ -436,12 +453,16 @@ static int add_root_mount(void) {
else
opts = arg_root_options;
+check = mount_skip_fsck(arg_root_fstype);
+if (!check)
+log_debug(Skipping fsck for root.);
+
log_debug(Found entry what=%s where=/sysroot type=%s, what,
strna(arg_root_fstype));
return add_mount(what,
/sysroot,
arg_root_fstype,
opts,
- 1,
+ check,
false,
false,
false,
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Locking current session programmatically
27 июня 2014 г., в 21:54, Lennart Poettering lenn...@poettering.net написал(а): On Fri, 27.06.14 17:45, Ivan Shapovalov (intelfx...@gmail.com) wrote: I want to lock my current session using a command-line tool (or a D-Bus call). The only apparent way to do this is `loginctl lock-session $XDG_SESSION_ID`. However, this results in an Access denied reply, which is somewhat strange (I expect to be able to lock my own session). Is this by design or a bug? Neither. Just missing functionality. I added this to the TODO list now. In either case, is it possible to lock the current session? Well, not with logind, no. But you should be able to do it with GNOME's APIs. Lennart -- Lennart Poettering, Red Hat I've got a DE-less setup (a freestanding window manager). Should I just invoke whatever tool I use for screenlocking (i3lock in my case)? -- Ivan Shapovalov / intelfx / (Sent from a phone. Havoc may be wreaked on the formatting.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
