Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 died (code=killed, status=15/TERM) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 belongs to systemd-exit.service Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service: main process exited, code=killed, status=15/TERM Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed start - dead Jan 26 11:53:59 linux-1a7f systemd[1942]: Job systemd-exit.service/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Started Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: Closed jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: exit.target changed dead - active Jan 26 11:53:59 linux-1a7f systemd[1942]: Job exit.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Exit the Session. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cannot see the whole picture
In some of my earlier mails I have said that I try to port a modular live slackware based distro (Porteus) to systemd as a personal project. I think I can do a lot of the booting with a initrd.img containing the core and the kernel parts. But then a difficult part comes. I have to make a service file which copies the unpacked modules to a loop-device in memory. Does anyone has a example of such file. Second part I m struggeling with is how I can take care that this is one of the first part of the booting. And this part must be alone and cannot be in parralel with other parts because they all depend on this step. Can someone help me to see the whole picture ? Roelof ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot see the whole picture
On 01/26/2014 09:16 AM, Roelof Wobben wrote: In some of my earlier mails I have said that I try to port a modular live slackware based distro (Porteus) to systemd as a personal project. Dropline an Gnome based slackware distribution [1] keeps a page [2] with what's needed for systemd integration on top of the traditional Slackware system which you should be able to go through to achieve just that. You can just contact them if that page is not enough since they have most likely solved all your problems already. JBG 1..http://www.droplinegnome.org/ 2. http://sourceforge.net/apps/trac/dropline-gnome/wiki/DroplineGnome3_10_Systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot see the whole picture
Date: Sun, 26 Jan 2014 09:50:16 + From: johan...@gmail.com To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Cannot see the whole picture On 01/26/2014 09:16 AM, Roelof Wobben wrote: In some of my earlier mails I have said that I try to port a modular live slackware based distro (Porteus) to systemd as a personal project. Dropline an Gnome based slackware distribution [1] keeps a page [2] with what's needed for systemd integration on top of the traditional Slackware system which you should be able to go through to achieve just that. You can just contact them if that page is not enough since they have most likely solved all your problems already. JBG 1..http://www.droplinegnome.org/ 2. http://sourceforge.net/apps/trac/dropline-gnome/wiki/DroplineGnome3_10_Systemd I know that project and Dropline is not a distribution but Gnome for Slackware. They used a hybrid system where I want a full systemd system.I use the Arch Linux build script for this. Second They do not use the modular system that Porteus uses. Roelof ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup: Support key-slot option
Debian recently introduced the option key-slot to /etc/crypttab to
specify the LUKS key slot to be used for decrypting the device. On
systems where a keyfile is used and the key is not in the first slot,
this can speed up the boot process quite a bit, since cryptsetup does
not need to try all of the slots sequentially. (Unsuccessfully testing
a key slot typically takes up to about 1 second.)
This patch makes systemd aware of this option.
Debian bug that introduced the feature:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704470
---
man/crypttab.xml| 14 ++
src/cryptsetup/cryptsetup.c | 13 +++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/man/crypttab.xml b/man/crypttab.xml
index 90d8ce9..5f386e5 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -164,6 +164,20 @@
/varlistentry
varlistentry
+termvarnamekey-slot=/varname/term
+
+listitemparaSpecifies the key slot to
+compare the passphrase or key against.
+If the key slot does not match the given
+passphrase or key, but another would, the
+setup of the device will fail regardless.
+This implies varnameluks/varname. See
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values. The default is to try
+all key slots in sequential
order./para/listitem
+/varlistentry
+
+varlistentry
termvarnameluks/varname/term
listitemparaForce LUKS mode. When this mode
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 0a15b50..033c0cd 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -39,6 +39,7 @@
static const char *opt_type = NULL; /* CRYPT_LUKS1, CRYPT_TCRYPT or
CRYPT_PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static int opt_key_slot = CRYPT_ANY_SLOT;
static unsigned opt_keyfile_size = 0;
static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
@@ -87,6 +88,14 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, key-slot=)) {
+
+opt_type = CRYPT_LUKS1;
+if (safe_atoi(option+9, opt_key_slot) 0) {
+log_error(key-slot= parse failure, ignoring.);
+return 0;
+}
+
} else if (startswith(option, tcrypt-keyfile=)) {
opt_type = CRYPT_TCRYPT;
@@ -425,7 +434,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
crypt_get_device_name(cd));
if (key_file) {
-r = crypt_activate_by_keyfile_offset(cd, name, CRYPT_ANY_SLOT,
+r = crypt_activate_by_keyfile_offset(cd, name, opt_key_slot,
key_file,
opt_keyfile_size,
opt_keyfile_offset,
flags);
if (r 0) {
@@ -439,7 +448,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
if (pass_volume_key)
r = crypt_activate_by_volume_key(cd, name, *p,
opt_key_size, flags);
else
-r = crypt_activate_by_passphrase(cd, name,
CRYPT_ANY_SLOT, *p, strlen(*p), flags);
+r = crypt_activate_by_passphrase(cd, name,
opt_key_slot, *p, strlen(*p), flags);
if (r = 0)
break;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot see the whole picture
On Sun, Jan 26, 2014 at 10:16 AM, Roelof Wobben rwob...@hotmail.com wrote: In some of my earlier mails I have said that I try to port a modular live slackware based distro (Porteus) to systemd as a personal project. I think I can do a lot of the booting with a initrd.img containing the core and the kernel parts. But then a difficult part comes. I have to make a service file which copies the unpacked modules to a loop-device in memory. I don't know precisely what your modules contain or what they are used for, but it may be simplest to just do the unpacking from the initrd (after the real root has been mounted, but before we switch). Assuming you use systemd in your initrd, the relevant targets to order your service before/after can be found in man 7 bootup. HTH, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Support key-slot option
On Sun, Jan 26, 2014 at 12:02 PM, Christian Seiler christ...@iwakd.de wrote:
Debian recently introduced the option key-slot to /etc/crypttab to
specify the LUKS key slot to be used for decrypting the device. On
systems where a keyfile is used and the key is not in the first slot,
this can speed up the boot process quite a bit, since cryptsetup does
not need to try all of the slots sequentially. (Unsuccessfully testing
a key slot typically takes up to about 1 second.)
This patch makes systemd aware of this option.
Debian bug that introduced the feature:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704470
---
man/crypttab.xml| 14 ++
src/cryptsetup/cryptsetup.c | 13 +++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/man/crypttab.xml b/man/crypttab.xml
index 90d8ce9..5f386e5 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -164,6 +164,20 @@
/varlistentry
varlistentry
+termvarnamekey-slot=/varname/term
+
+listitemparaSpecifies the key slot to
+compare the passphrase or key against.
+If the key slot does not match the given
+passphrase or key, but another would, the
+setup of the device will fail regardless.
+This implies varnameluks/varname. See
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values. The default is to try
+all key slots in sequential
order./para/listitem
+/varlistentry
+
+varlistentry
termvarnameluks/varname/term
listitemparaForce LUKS mode. When this
mode
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 0a15b50..033c0cd 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -39,6 +39,7 @@
static const char *opt_type = NULL; /* CRYPT_LUKS1, CRYPT_TCRYPT or
CRYPT_PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static int opt_key_slot = CRYPT_ANY_SLOT;
static unsigned opt_keyfile_size = 0;
static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
@@ -87,6 +88,14 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, key-slot=)) {
+
+opt_type = CRYPT_LUKS1;
+if (safe_atoi(option+9, opt_key_slot) 0) {
+log_error(key-slot= parse failure, ignoring.);
+return 0;
+}
+
} else if (startswith(option, tcrypt-keyfile=)) {
opt_type = CRYPT_TCRYPT;
@@ -425,7 +434,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
crypt_get_device_name(cd));
if (key_file) {
-r = crypt_activate_by_keyfile_offset(cd, name,
CRYPT_ANY_SLOT,
+r = crypt_activate_by_keyfile_offset(cd, name, opt_key_slot,
key_file,
opt_keyfile_size,
opt_keyfile_offset,
flags);
if (r 0) {
@@ -439,7 +448,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
if (pass_volume_key)
r = crypt_activate_by_volume_key(cd, name,
*p, opt_key_size, flags);
else
-r = crypt_activate_by_passphrase(cd, name,
CRYPT_ANY_SLOT, *p, strlen(*p), flags);
+r = crypt_activate_by_passphrase(cd, name,
opt_key_slot, *p, strlen(*p), flags);
if (r = 0)
break;
--
1.8.3.1
Thanks! Applied.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 12:09:23 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can easily hit new process that was spawned since service stop had been initiated. Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 died (code=killed, status=15/TERM) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 belongs to systemd-exit.service Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service: main process exited, code=killed, status=15/TERM Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed start - dead Jan 26 11:53:59 linux-1a7f systemd[1942]: Job systemd-exit.service/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Started Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: Closed jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: exit.target changed dead - active Jan 26 11:53:59 linux-1a7f systemd[1942]: Job exit.target/start finished, result=done Jan 26 11:53:59 linux-1a7f
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 17:18:28 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Sun, 26 Jan 2014 12:09:23 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can easily hit new process that was spawned since service stop had been initiated. Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. 2. user@.service has single timeout, but it manages unknown in advance number of services each needing unknown timeout. While having some capping to total timeout looks sensible, only user itself may estimate the value. But service user@.system is system-level service which use cannot configure ... Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
Hi Andrey, On Sun, Jan 26, 2014 at 4:21 PM, Andrey Borzenkov arvidj...@gmail.com wrote: I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can easily hit new process that was spawned since service stop had been initiated. Thanks for debugging this! Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I don't think we want any processes to survive the exit of user@.service, so KillMode=process feels wrong. However, isn't the problem that we are going into the kill control-group mode too soon, before user@.serivce has had a chance of cleaning itself up gracefully? I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. I guess what we want is to first send SIGTERM only to the systemd --user process, and only after a timeout start sending SIGTERM to all the processes in the control group? I.e., wouldn't a ExecStop entry in user@.service give us the required timeout? 2. user@.service has single timeout, but it manages unknown in advance number of services each needing unknown timeout. While having some capping to total timeout looks sensible, only user itself may estimate the value. But service user@.system is system-level service which use cannot configure ... I think it really makes sense to have a system-wide timeout on these things (possibly a high one), we don't want the user to delay things without limit. The user already has the possibility of putting their own limits if they want to (but they must of course be shorter than the system-wide one). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Makefile.am: add a phony target for cppcheck
On Wed, Jan 22, 2014 at 03:28:43AM -0800, gitter.spi...@gmail.com wrote: From: Elia Pinto devzero2...@rpm5.org The cppcheck target was introduced by commit 16f4efb4150c65e3c61adaa8ea512489de49f532 build-sys: add cppcheck target. But it is preferable to use a make phony target for it, as this patch does. There are two general reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance. In this case the first reason is obvious, and the second is that make skips the implicit rule search for phony targets, since it knows that phony targets do not name actual files that could be remade from other files (as described in the Gnu Make Manual). Applied. Signed-off-by: Elia Pinto devzero2...@rpm5.org Not necessary. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 17:23:54 +0100 Tom Gundersen t...@jklm.no пишет: Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I don't think we want any processes to survive the exit of user@.service, so KillMode=process feels wrong. However, isn't the problem that we are going into the kill control-group mode too soon, before user@.serivce has had a chance of cleaning itself up gracefully? Yes. I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. I guess what we want is to first send SIGTERM only to the systemd --user process, and only after a timeout start sending SIGTERM to all the processes in the control group? I.e., wouldn't a ExecStop entry in user@.service give us the required timeout? Does not work. systemd sends SIGTERM as soon as ExecStop finished. Jan 26 21:00:14 linux-1a7f systemd[1]: Stopping User Manager for 0... Jan 26 21:00:14 linux-1a7f systemd[1]: About to execute: /usr/bin/kill -15 $MAINPID Jan 26 21:00:14 linux-1a7f systemd[1]: Forked /usr/bin/kill as 1978 Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service changed running - stop Jan 26 21:00:14 linux-1a7f systemd[1978]: Executing: /usr/bin/kill -15 1886 Jan 26 21:00:14 linux-1a7f systemd[1886]: Received SIGTERM from PID 1978 (kill). Jan 26 21:00:14 linux-1a7f systemd[1886]: Activating special unit exit.target Jan 26 21:00:14 linux-1a7f systemd[1886]: Trying to enqueue job exit.target/start/replace Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job exit.target/start as 9 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job systemd-exit.service/start as 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job shutdown.target/start as 11 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job -.slice/stop as 12 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job default.target/stop as 13 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job test.service/stop as 14 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job paths.target/stop as 15 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job timers.target/stop as 16 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job sockets.target/stop as 17 Jan 26 21:00:14 linux-1a7f systemd[1886]: Enqueued job exit.target/start as 9 Jan 26 21:00:14 linux-1a7f systemd[1886]: Stopping Test service with stop delay... Jan 26 21:00:14 linux-1a7f systemd[1886]: About to execute: /bin/sleep 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Forked /bin/sleep as 2001 Jan 26 21:00:14 linux-1a7f systemd[1886]: test.service changed exited - stop Jan 26 21:00:14 linux-1a7f systemd[2001]: Executing: /bin/sleep 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Stopping Default. ... Jan 26 21:00:14 linux-1a7f systemd[1]: Child 1978 died (code=exited, status=0/SUCCESS) Jan 26 21:00:14 linux-1a7f systemd[1]: Child 1978 belongs to user@0.service Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service: control process exited, code=exited status=0 Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service got final SIGCHLD for state stop Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service changed stop - stop-sigterm I believe someone already mentioned this problem. In general, we cannot assume that ExecStop is synchronous. It may just signal main process to exit. systemd should wait until $MAINPID exits (or timeout) before continuing further processing. 2. user@.service has single timeout, but it manages unknown in advance number of services each needing unknown timeout. While having some capping to total timeout looks sensible, only user itself may estimate the value. But service user@.system is system-level service which use cannot configure ... I think it really makes sense to have a system-wide timeout on these things (possibly a high one), we don't want the user to delay things without limit. The user already has the possibility of putting their own limits if they want to (but they must of course be shorter than the system-wide one). I mostly agree, except current 90 seconds look too small and this definitely requires better communication to user (like auto exit from quiet mode) so system does not appear to be hung. There is also practical issue - we have two levels - PID 1 instance and user instance (multiple users actually). Does it make sense to display each individual user
Re: [systemd-devel] [PATCH] pam_systemd: Ignore vtnr when seat != seat0
On Fri, Jan 24, 2014 at 11:23:01AM -0700, Matthew Monaco wrote: From: Matthew Monaco matthew.mon...@0x01b.net logind considers it an error for a seat other than seat0 to have a non-zero vtnr for CreateSession --- This is what I've been using for the past 3 weeks. Looks ok. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Malicious tests?
Does systemd have any tests for malicious behavior? People sending bazillions of dbus requests? People sending random nonsense dbus requests? I'm just asking because you gotta know someone is gonna do it if you don't do it first :-). I also find that merely sending two systemctl disable commands in quick succession totally borks my fedora 20 system, so there's your first malicious test that doesn't even need a new program or script written... See: https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c45 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Malicious tests?
В Sun, 26 Jan 2014 19:44:13 -0500 Tom Horsley horsley1...@gmail.com пишет: Does systemd have any tests for malicious behavior? People sending bazillions of dbus requests? People sending random nonsense dbus requests? I'm just asking because you gotta know someone is gonna do it if you don't do it first :-). I also find that merely sending two systemctl disable commands in quick succession totally borks my fedora 20 system, so there's your first malicious test that doesn't even need a new program or script written... See: https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c45 It is not disable itself but rather implicit deamon-reload it does. This was reported here just recently by Colin. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
This is a continuation of a discussion I had on #systemd. I have a server that has two onboard ethernet chipsets, and a fresh Arch linux install (systemd/udevd v208). On this system, consistent interface naming fails, and I end up with eno1 and eth1 after bootup. The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the apparently relevant part is: Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection ... *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists* Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection. *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1* From that, it appears that udevd is trying to rename both interfaces to eno1. As you can see from the boot log, the two chipsets are on separate PCI buses (bus 0, dev 0x19, and bus 2, dev 0). Looking in /sys , neither device has an acpi_index attribute, and both have an index attribute equal to 1. I'm by far not an expert on this data, but index=1 naively sounds right, since they're both the only ethernet device on their bus. According to The Source ( http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131), lack of acpi_index means that index is used instead, and we end up with two devices mapping to eno1. Further debugging information: full `dmidecode` output ( http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys ( http://pastebin.com/raw.php?i=TbSvDMSB ). At this point, I need more expert help. Is this a udev bug where it produces incorrect output in the presence of multiple PCI buses? Is it a firmware bug where my motherboard provides incorrect data to udev? Regardless, should udev be capable of handling this gracefully? Should I report a bug? Do you need more information from my system? Thoughts on temporary workarounds so that I can continue configuring my system with consistent interfaces also welcome, but my major concern is whether udev is doing the right thing, and how to make it do the right thing if not. Cheers, - Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
В Mon, 27 Jan 2014 04:18:20 + David Anderson d...@natulte.net пишет: This is a continuation of a discussion I had on #systemd. I have a server that has two onboard ethernet chipsets, and a fresh Arch linux install (systemd/udevd v208). On this system, consistent interface naming fails, and I end up with eno1 and eth1 after bootup. The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the apparently relevant part is: Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection ... *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists* Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection. *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1* From that, it appears that udevd is trying to rename both interfaces to eno1. As you can see from the boot log, the two chipsets are on separate PCI buses (bus 0, dev 0x19, and bus 2, dev 0). Looking in /sys , neither device has an acpi_index attribute, and both have an index attribute equal to 1. I'm by far not an expert on this data, but index=1 naively sounds right, since they're both the only ethernet device on their bus. According to The Source ( http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131), lack of acpi_index means that index is used instead, and we end up with two devices mapping to eno1. Further debugging information: full `dmidecode` output ( http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys ( http://pastebin.com/raw.php?i=TbSvDMSB ). At this point, I need more expert help. Is this a udev bug where it produces incorrect output in the presence of multiple PCI buses? Is it a firmware bug where my motherboard provides incorrect data to udev? Looks like it. According to specs Device Type Instance is a unique value (within a given onboard device type) You have two devices of type Ethernet with the same Instance values. Regardless, should udev be capable of handling this gracefully? You can always override udev names with your own. What do you suggest to do automatically? There is no way to find out which interface is really the first and which is the second. Should I report a bug? Do you need more information from my system? Thoughts on temporary workarounds so that I can continue configuring my system with consistent interfaces also welcome, but my major concern is whether udev is doing the right thing, and how to make it do the right thing if not. Cheers, - Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov arvidj...@gmail.comwrote: В Mon, 27 Jan 2014 04:18:20 + David Anderson d...@natulte.net пишет: This is a continuation of a discussion I had on #systemd. I have a server that has two onboard ethernet chipsets, and a fresh Arch linux install (systemd/udevd v208). On this system, consistent interface naming fails, and I end up with eno1 and eth1 after bootup. The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the apparently relevant part is: Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection ... *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists* Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection. *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1* From that, it appears that udevd is trying to rename both interfaces to eno1. As you can see from the boot log, the two chipsets are on separate PCI buses (bus 0, dev 0x19, and bus 2, dev 0). Looking in /sys , neither device has an acpi_index attribute, and both have an index attribute equal to 1. I'm by far not an expert on this data, but index=1 naively sounds right, since they're both the only ethernet device on their bus. According to The Source ( http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131 ), lack of acpi_index means that index is used instead, and we end up with two devices mapping to eno1. Further debugging information: full `dmidecode` output ( http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys ( http://pastebin.com/raw.php?i=TbSvDMSB ). At this point, I need more expert help. Is this a udev bug where it produces incorrect output in the presence of multiple PCI buses? Is it a firmware bug where my motherboard provides incorrect data to udev? Looks like it. According to specs Device Type Instance is a unique value (within a given onboard device type) Can you link me to the relevant spec? I suspect that Intel interpreted this as unique value within a bus instead of unique machine-wide, but I'm interested in the context surrounding that statement. You have two devices of type Ethernet with the same Instance values. Regardless, should udev be capable of handling this gracefully? You can always override udev names with your own. What do you suggest to do automatically? There is no way to find out which interface is really the first and which is the second. If it is indeed a firmware bug, there's nothing obvious for udev to do. A suggestion on IRC was to disambiguate by bus/device ID in such cases (lowest bus:device gets eno1, next gets eno2, etc.). I don't know if this is desirable, or even if udev can do this since it would require a second pass over the affected devices with a global view of all such devices. In any case, I ended up writing my own rules that correctly set up eno1/eno2 based on the port #s on the board. Slightly annoying, but short of bugging Intel for a firmware update, not much else to do. Thanks! - Dave Should I report a bug? Do you need more information from my system? Thoughts on temporary workarounds so that I can continue configuring my system with consistent interfaces also welcome, but my major concern is whether udev is doing the right thing, and how to make it do the right thing if not. Cheers, - Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] permission to post to this list
Email-id: basavaraj.rayappana...@in.bosch.commailto:basavaraj.rayappana...@in.bosch.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
On Sun, Jan 26, 2014 at 09:16:13PM +0400, Andrey Borzenkov wrote: В Sun, 26 Jan 2014 17:23:54 +0100 Tom Gundersen t...@jklm.no пишет: Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I don't think we want any processes to survive the exit of user@.service, so KillMode=process feels wrong. However, isn't the problem that we are going into the kill control-group mode too soon, before user@.serivce has had a chance of cleaning itself up gracefully? Yes. I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. I guess what we want is to first send SIGTERM only to the systemd --user process, and only after a timeout start sending SIGTERM to all the processes in the control group? I.e., wouldn't a ExecStop entry in user@.service give us the required timeout? Does not work. systemd sends SIGTERM as soon as ExecStop finished. Looks like we need a setting like SendKillSignalTo=main-pid|all|control-pid. Or something like that. Also the TimeoutStopSec on user@.service should be probably increased to 10 min or so. I believe someone already mentioned this problem. In general, we cannot assume that ExecStop is synchronous. It may just signal main process to exit. systemd should wait until $MAINPID exits (or timeout) before continuing further processing. ExecStop is required to be synchronous, i.e. the service should be stopped when it returns. /bin/kill is not going to work here. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
On Sat, Jan 25, 2014 at 06:16:38PM +0100, Reindl Harald wrote: Am 25.01.2014 18:09, schrieb Marcos Mello: Koen Kooi koen at dominion.thruhere.net writes: [snip] To make matters worse, the cylon eye isn't displayed when you boot with 'quiet' in your kernel command line. quiet systemd.show_status=1 shows the gracious Cylon eye so that should be default and extended by a visible counter manually to add boot-params are useless for the normal user the advaned one is not using quiet at all I now pushed a change to git to display time since a job was started and the job timeout in the ephemeral status. It turns out that in the recent rewrite, the timeout logic was borked, so the ephemeral status was not displayed properly. It should now be displayed more reliably. Still, nothing is displayed with 'quiet'. This is a separate change to make I guess. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
