[systemd-devel] PATCH: systemctl: null-initialize pointer with cleanup attribute
Patch attached. (git send-email currently brokken)
declarations with _cleanup_free_ attribute needs to be NULL initialized.
From e242049410bb8373f8724ac24328e0f024b9929b Mon Sep 17 00:00:00 2001
From: Daniel Buch boogiewasth...@gmail.com
Date: Wed, 6 May 2015 10:28:08 +0200
Subject: [PATCH] systemctl: null-initialize pointer with cleanup attribute
---
src/systemctl/systemctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 4f36ba8..4c45bfc 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -7289,7 +7289,7 @@ static int halt_main(sd_bus *bus) {
if (arg_when 0) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_bus_close_unref_ sd_bus *b = NULL;
-_cleanup_free_ char *m;
+_cleanup_free_ char *m = NULL;
if (avoid_bus()) {
log_error(Unable to perform operation without bus connection.);
--
2.4.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1430889996-24621-1-git-send-email-zbyszek%40in.waw.pl -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: fix coding style
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1430892913-32747-1-git-send-email-susant%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On Wed, May 6, 2015 at 5:52 AM, Ivan Shapovalov intelfx...@gmail.com wrote: On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote: On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: - do `systemd-run` twice and somehow set up the dependencies between two transient units I'd be happy to take a patch that allows configuring deps for transient units when constructing them. Hi Lennart, I've just done this (also added manager-side support for JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this turned out to be insufficient for my usecase. I have to start two transient services, say, A.service and B.service, and - B.service needs A.service (i. e. B.service Requires=A.service and After=A.service) - A.service must be stopped as soon as B.service exits (i. e. A.service BindsTo=B.service) And there is a contradiction: I can't make a dependency on an inexistent unit. If I create A.service before B.service, I can't set BindsTo=, and if I create B.service before A.service, I can't set Requires= and After=. Locally, I've solved this by allowing inverse dependencies to be set over the bus. That is, I make B.service BoundBy=A.service. Is this acceptable for upstream? What about adding option --define-only (I do not care about actual name) that adds unit definition but does not start unit? Then you can define any number of transient units and then systemctl start them later. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: fix coding style
---
src/udev/net/ethtool-util.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/udev/net/ethtool-util.c b/src/udev/net/ethtool-util.c
index ec67126..927b8ab 100644
--- a/src/udev/net/ethtool-util.c
+++ b/src/udev/net/ethtool-util.c
@@ -93,8 +93,7 @@ int ethtool_get_driver(int *fd, const char *ifname, char
**ret) {
return 0;
}
-int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed, Duplex
duplex)
-{
+int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed, Duplex
duplex) {
struct ethtool_cmd ecmd = {
.cmd = ETHTOOL_GSET
};
--
2.4.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: try to handle read-only file systems gracefully
On Wed, May 06, 2015 at 04:11:57AM +, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 30, 2015 at 08:50:38PM +0200, Michael Olbrich wrote:
On read-only filesystems trying to create the target will not fail with
EEXIST but with EROFS. Handle EROFS by checking if the target already
exists, and if empty when truncating.
This avoids reporting errors if tmpfiles doesn't actually needs to do
anything.
---
This is a rework of a patch I wrote some time ago[1]. This time reacting to
EROFS instead of preempting it.
Applied, with some small changes, see below.
Michael
[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022158.html
src/tmpfiles/tmpfiles.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 218d55051410..4473bf019911 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -983,9 +983,11 @@ static int write_one_file(Item *i, const char *path) {
log_debug_errno(errno, Not writing \%s\: %m,
path);
return 0;
}
-
-log_error_errno(errno, Failed to create file %s: %m,
path);
-return -errno;
+r = -errno;
+if (i-argument || r != -EROFS || stat(path, st) 0 ||
(i-type == TRUNCATE_FILE st.st_size 0)) {
+log_error_errno(r, Failed to create file %s: %m,
path);
+return r;
+}
I reverted the condition, because it seems safer to whitelist instead of
blacklisting. Also, if the condition didn't succeed, we'd do stat twice.
Please check that it still works as intended.
Looks good here.
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Restore udevadm settle timeout
Hi
On Wed, May 6, 2015 at 4:31 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Apr 20, 2015 at 10:33:48AM +0200, David Herrmann wrote:
Hi
On Sat, Apr 11, 2015 at 9:38 PM, Nir Soffer nir...@gmail.com wrote:
On Sat, Apr 11, 2015 at 1:36 PM, David Herrmann dh.herrm...@gmail.com
wrote:
@@ -139,6 +142,9 @@ static int adm_settle(struct udev *udev, int argc,
char *argv[]) {
break;
}
+if (now(CLOCK_MONOTONIC) = deadline)
+break;
+
Previous udevadm allowed timeout=0 to disable this. I added the condition.
Hi David,
I think the handling of timeout=0 is incorrect now. The manual says:
A value of 0 will check if the queue is empty and always return
immediately.
In udev-147 (used on rhel6), this was the behavior. If timeout was 0,
is_timeout was set and settle was returning with rc=1.
This behavior changed in:
http://git.kernel.org/cgit/linux/hotplug/udev.git/commit/?id=ead7c62ab7641e150c6d668f939c102a6771ce60
After this commit, zero timeout results in unlimited wait. Since this
patch did not
change the manual or the online help, and the commit message says:
udevadm: settle - kill alarm(), I guess this was unintended change.
I don't see the use case for disabling the timeout, so it seems that
we should fix
this, restoring the behavior before this commit.
What do you think?
Ok, this is on me, sorry for that. I tried to keep the behavior from
before the code-removal. I wasn't aware that this was not how it is
documented.
I'm actually not sure whether that was an intended change. It does not
look like it was, indeed. Maybe Kay or Tom know more.. I have no idea
whether timeout=0 is used in the wild.
I'll stall your further patches until we've decided on this.
What's the status here?
This is already fixed in -git. Original behavior is restored.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service
2015-05-06 1:49 GMT+02:00 Cameron Norman camerontnor...@gmail.com: +KillMode=process If I had to take a guess I would say that it was desired to let the shell do its own process management, but Lennart can only know. Maybe KillMode=mixed would be better? KillMode=mixed seems to work better, indeed, from a quick test and I don't see a downside using mixed. I have to add, that Debian's /sbin/sulogin implementation comes from sysvinit-utils, not util-linux. Maybe that makes a difference. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service
On Wed, May 06, 2015 at 12:39:50PM +0200, Michael Biebl wrote: 2015-05-06 1:49 GMT+02:00 Cameron Norman camerontnor...@gmail.com: +KillMode=process If I had to take a guess I would say that it was desired to let the shell do its own process management, but Lennart can only know. Maybe KillMode=mixed would be better? KillMode=mixed seems to work better, indeed, from a quick test and I don't see a downside using mixed. KillMode=mixed is newer. RefuseManual* is rather ugly, so this approach seems much nicer. Zbyszek I have to add, that Debian's /sbin/sulogin implementation comes from sysvinit-utils, not util-linux. Maybe that makes a difference. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-socket-util: Fix tests on machines without ipv6 support
On Thu, Apr 30, 2015 at 10:18:31AM +0200, Sjoerd Simons wrote:
The test for socket-util already has some code to only do certain tests
on machines with ipv6 support. However this was incomplete causing the
test to still fail on such machines, this patch adds the remaining cases
required to make it pass on machine without ipv6 support.
---
src/test/test-socket-util.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/test/test-socket-util.c b/src/test/test-socket-util.c
index f257af4..b58f5e3 100644
--- a/src/test/test-socket-util.c
+++ b/src/test/test-socket-util.c
@@ -111,9 +111,11 @@ static void test_socket_address_equal(void) {
assert_se(socket_address_parse(b, /foo/bar) = 0);
assert_se(socket_address_equal(a, b));
-assert_se(socket_address_parse(a, [::1]:) = 0);
-assert_se(socket_address_parse(b, [::1]:) = 0);
-assert_se(socket_address_equal(a, b));
+if (socket_ipv6_is_supported()) {
+assert_se(socket_address_parse(a, [::1]:) = 0);
+assert_se(socket_address_parse(b, [::1]:) = 0);
+assert_se(socket_address_equal(a, b));
+}
Instead of skipping the test, what about doing something like
int expect = socket_ipv6_is_supported() ? 0 : -EAFNOSUPPORT;
assert_se(socket_address_parse(...) == expect);
? We want to exercise as many paths through the code as possible.
Zbyszek
assert_se(socket_address_parse(a, @abstract) = 0);
assert_se(socket_address_parse(b, @abstract) = 0);
@@ -133,8 +135,10 @@ static void test_socket_address_get_path(void) {
assert_se(socket_address_parse(a, @abstract) = 0);
assert_se(!socket_address_get_path(a));
-assert_se(socket_address_parse(a, [::1]:) = 0);
-assert_se(!socket_address_get_path(a));
+if (socket_ipv6_is_supported()) {
+assert_se(socket_address_parse(a, [::1]:) = 0);
+assert_se(!socket_address_get_path(a));
+}
assert_se(socket_address_parse(a, /foo/bar) = 0);
assert_se(streq(socket_address_get_path(a), /foo/bar));
--
2.1.4
___
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] Don't allow to restart emergency.service/rescue.service
2015-05-06 13:40 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Wed, May 06, 2015 at 12:39:50PM +0200, Michael Biebl wrote: 2015-05-06 1:49 GMT+02:00 Cameron Norman camerontnor...@gmail.com: +KillMode=process If I had to take a guess I would say that it was desired to let the shell do its own process management, but Lennart can only know. Maybe KillMode=mixed would be better? KillMode=mixed seems to work better, indeed, from a quick test and I don't see a downside using mixed. KillMode=mixed is newer. RefuseManual* is rather ugly, so this approach seems much nicer. The following services in units/ use KillMode=process: console-getty.service.m4.in:KillMode=process container-ge...@.service.m4.in:KillMode=process debug-shell.service.in:KillMode=process getty@.service.m4:KillMode=process serial-getty@.service.m4:KillMode=process I wonder, if they should all be switched to use mixed. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Don't allow to restart emergency.service/rescue.service
On Wed, May 06, 2015 at 02:08:18PM +0200, Michael Biebl wrote: 2015-05-06 13:40 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Wed, May 06, 2015 at 12:39:50PM +0200, Michael Biebl wrote: 2015-05-06 1:49 GMT+02:00 Cameron Norman camerontnor...@gmail.com: +KillMode=process If I had to take a guess I would say that it was desired to let the shell do its own process management, but Lennart can only know. Maybe KillMode=mixed would be better? KillMode=mixed seems to work better, indeed, from a quick test and I don't see a downside using mixed. KillMode=mixed is newer. RefuseManual* is rather ugly, so this approach seems much nicer. The following services in units/ use KillMode=process: console-getty.service.m4.in:KillMode=process container-ge...@.service.m4.in:KillMode=process debug-shell.service.in:KillMode=process getty@.service.m4:KillMode=process serial-getty@.service.m4:KillMode=process I wonder, if they should all be switched to use mixed. Yes, maybe with the exception of debug-shell.service. Sometimes you might want to launch strace or something and have it survive exit from the debug shell. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On 06.05.2015 07:26, Zbigniew Jędrzejewski-Szmek wrote:
In the initramfs, we run systemd-fsck@sysroot-device.service.
In the real system we run systemd-fsck-root.service. Generate
a fake systemd-fsck-root.service if we are running a unit check
for the root file system. We don't really care if the real fsck unit
fails, because the failure will be handled in some other way.
This fake unit is created and pulled in only when we actually plan to
check the file system for /sysroot. This way we avoid having an
active/exited systemd-fsck-root.service in the main filesystem if
we didn't do anything.
https://bugzilla.redhat.com/show_bug.cgi?id=1201979
C.f. 956eaf2b8d6c024705ddadc7393bc707de02.
---
Something like this?
Yes ;) Let me test this.
TODO | 5 -
src/shared/generator.c | 30 ++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/TODO b/TODO
index 430a354e84..cc827701f0 100644
--- a/TODO
+++ b/TODO
@@ -113,9 +113,6 @@ Features:
* Maybe add support for the equivalent of ethtool advertise to .link files?
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
-* fstab-generator should generate systemd-fsck-root.service when
- running in the initrd, and operate on the right device.
-
* .timer units should optionally support CLOCK_BOOTTIME in addition to
CLOCK_MONOTONIC
* create a btrfs qgroup for /var/lib/machines, and add all container
@@ -153,8 +150,6 @@ Features:
* Introduce $LISTEN_NAMES to complement $LISTEN_FDS, containing a
colon separated list of identifiers for the fds passed.
-* when the fstab-generator runs in the initrd, it should create a /dev/null
mask for systemd-fsck-root.service, to avoid that the the root fs is fsck'ed
twice.
-
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 2dc34bf738..813ce1af9a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -28,8 +28,32 @@
#include generator.h
#include path-util.h
#include fstab-util.h
+#include fileio.h
#include dropin.h
+static int write_fsck_root_service(const char *dir) {
+const char *unit;
+int r;
+
+unit = strjoina(dir, /systemd-fsck-root.service);
+log_debug(Creating %s., unit);
+
+r = write_string_file_atomic(unit,
+# Automatically generated by a systemd-fstab-generator or
similar\n\n
+[Unit]\n
+Description=Root File System Check Placeholder\n
+DefaultDependencies=no\n
+Before=shutdown.target\n
+\n
+[Service]\n
+ExecStart=/bin/true\n
+Type=oneshot\n
+RemainAfterExit=yes\n);
+if (r 0)
+log_warning_errno(errno, Failed to write unit file %s: %m,
unit);
+return r;
+}
+
int generator_write_fsck_deps(
FILE *f,
const char *dir,
@@ -79,6 +103,12 @@ int generator_write_fsck_deps(
RequiresOverridable=%1$s\n
After=%1$s\n,
fsck);
+
+if (in_initrd() path_equal(where, /sysroot)) {
+(void) write_fsck_root_service(dir);
+fprintf(f,
+Wants=systemd-fsck-root.service\n);
+}
}
return 0;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
Works for me... booted with ro on the kernel cmdline:
$ systemctl status systemd-fsck-root.service
● systemd-fsck-root.service - File System Check on Root Device
Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static;
vendor preset: disabled)
Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago
Docs: man:systemd-fsck-root.service(8)
Main PID: 144 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-fsck-root.service
[1.440568] systemd[1]: Starting Root File System Check Placeholder...
[1.445484] systemd[1]: Started Root File System Check Placeholder.
[…]
[1.786864] systemd[1]: Starting File System Check on /dev/gpt-auto-root...
[1.804183] systemd[1]: Started File System Check on /dev/gpt-auto-root.
[2.015962] systemd[1]: Mounting /sysroot...
[…]
[2.294428] systemd[1]: Switching root.
[…]
[2.570286] systemd[1]: Stopped Switch Root.
[…]
[2.571714] systemd[1]: Stopped File System Check on Root Device.
[2.571859] systemd[1]: Stopping File System Check on Root Device...
[…]
[2.624669] systemd[1]: Started Remount Root and Kernel File Systems.
Although Stopping File System Check on Root Device is strange...
On 06.05.2015 07:26, Zbigniew Jędrzejewski-Szmek wrote:
In the initramfs, we run systemd-fsck@sysroot-device.service.
In the real system we run systemd-fsck-root.service. Generate
a fake systemd-fsck-root.service if we are running a unit check
for the root file system. We don't really care if the real fsck unit
fails, because the failure will be handled in some other way.
This fake unit is created and pulled in only when we actually plan to
check the file system for /sysroot. This way we avoid having an
active/exited systemd-fsck-root.service in the main filesystem if
we didn't do anything.
https://bugzilla.redhat.com/show_bug.cgi?id=1201979
C.f. 956eaf2b8d6c024705ddadc7393bc707de02.
---
Something like this?
TODO | 5 -
src/shared/generator.c | 30 ++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/TODO b/TODO
index 430a354e84..cc827701f0 100644
--- a/TODO
+++ b/TODO
@@ -113,9 +113,6 @@ Features:
* Maybe add support for the equivalent of ethtool advertise to .link files?
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
-* fstab-generator should generate systemd-fsck-root.service when
- running in the initrd, and operate on the right device.
-
* .timer units should optionally support CLOCK_BOOTTIME in addition to
CLOCK_MONOTONIC
* create a btrfs qgroup for /var/lib/machines, and add all container
@@ -153,8 +150,6 @@ Features:
* Introduce $LISTEN_NAMES to complement $LISTEN_FDS, containing a
colon separated list of identifiers for the fds passed.
-* when the fstab-generator runs in the initrd, it should create a /dev/null
mask for systemd-fsck-root.service, to avoid that the the root fs is fsck'ed
twice.
-
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 2dc34bf738..813ce1af9a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -28,8 +28,32 @@
#include generator.h
#include path-util.h
#include fstab-util.h
+#include fileio.h
#include dropin.h
+static int write_fsck_root_service(const char *dir) {
+const char *unit;
+int r;
+
+unit = strjoina(dir, /systemd-fsck-root.service);
+log_debug(Creating %s., unit);
+
+r = write_string_file_atomic(unit,
+# Automatically generated by a systemd-fstab-generator or
similar\n\n
+[Unit]\n
+Description=Root File System Check Placeholder\n
+DefaultDependencies=no\n
+Before=shutdown.target\n
+\n
+[Service]\n
+ExecStart=/bin/true\n
+Type=oneshot\n
+RemainAfterExit=yes\n);
+if (r 0)
+log_warning_errno(errno, Failed to write unit file %s: %m,
unit);
+return r;
+}
+
int generator_write_fsck_deps(
FILE *f,
const char *dir,
@@ -79,6 +103,12 @@ int generator_write_fsck_deps(
RequiresOverridable=%1$s\n
After=%1$s\n,
fsck);
+
+if (in_initrd() path_equal(where, /sysroot)) {
+(void) write_fsck_root_service(dir);
+fprintf(f,
+Wants=systemd-fsck-root.service\n);
+}
}
return 0;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On Wed, May 06, 2015 at 03:50:08PM +0200, Harald Hoyer wrote:
Works for me... booted with ro on the kernel cmdline:
$ systemctl status systemd-fsck-root.service
● systemd-fsck-root.service - File System Check on Root Device
Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static;
vendor preset: disabled)
Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago
Docs: man:systemd-fsck-root.service(8)
Main PID: 144 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/systemd-fsck-root.service
[1.440568] systemd[1]: Starting Root File System Check Placeholder...
[1.445484] systemd[1]: Started Root File System Check Placeholder.
[…]
[1.786864] systemd[1]: Starting File System Check on
/dev/gpt-auto-root...
[1.804183] systemd[1]: Started File System Check on /dev/gpt-auto-root.
[2.015962] systemd[1]: Mounting /sysroot...
[…]
[2.294428] systemd[1]: Switching root.
[…]
[2.570286] systemd[1]: Stopped Switch Root.
[…]
[2.571714] systemd[1]: Stopped File System Check on Root Device.
[2.571859] systemd[1]: Stopping File System Check on Root Device...
[…]
[2.624669] systemd[1]: Started Remount Root and Kernel File Systems.
Although Stopping File System Check on Root Device is strange...
Hm, that's strange. This would suggest that sd-fsck-root.service is not
wanted by anything in your system. I wonder if this is because you
have gpt-auto-root, and I'm using plain old fstab.
$ systemctl show -p WantedBy,RequiredBy,RequiredByOverridable systemd-fsck-root
RequiredBy=
RequiredByOverridable=
WantedBy=local-fs.target
Zbyszek
On 06.05.2015 07:26, Zbigniew Jędrzejewski-Szmek wrote:
In the initramfs, we run systemd-fsck@sysroot-device.service.
In the real system we run systemd-fsck-root.service. Generate
a fake systemd-fsck-root.service if we are running a unit check
for the root file system. We don't really care if the real fsck unit
fails, because the failure will be handled in some other way.
This fake unit is created and pulled in only when we actually plan to
check the file system for /sysroot. This way we avoid having an
active/exited systemd-fsck-root.service in the main filesystem if
we didn't do anything.
https://bugzilla.redhat.com/show_bug.cgi?id=1201979
C.f. 956eaf2b8d6c024705ddadc7393bc707de02.
---
Something like this?
TODO | 5 -
src/shared/generator.c | 30 ++
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/TODO b/TODO
index 430a354e84..cc827701f0 100644
--- a/TODO
+++ b/TODO
@@ -113,9 +113,6 @@ Features:
* Maybe add support for the equivalent of ethtool advertise to .link
files?
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030112.html
-* fstab-generator should generate systemd-fsck-root.service when
- running in the initrd, and operate on the right device.
-
* .timer units should optionally support CLOCK_BOOTTIME in addition to
CLOCK_MONOTONIC
* create a btrfs qgroup for /var/lib/machines, and add all container
@@ -153,8 +150,6 @@ Features:
* Introduce $LISTEN_NAMES to complement $LISTEN_FDS, containing a
colon separated list of identifiers for the fds passed.
-* when the fstab-generator runs in the initrd, it should create a
/dev/null mask for systemd-fsck-root.service, to avoid that the the root fs
is fsck'ed twice.
-
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 2dc34bf738..813ce1af9a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -28,8 +28,32 @@
#include generator.h
#include path-util.h
#include fstab-util.h
+#include fileio.h
#include dropin.h
+static int write_fsck_root_service(const char *dir) {
+const char *unit;
+int r;
+
+unit = strjoina(dir, /systemd-fsck-root.service);
+log_debug(Creating %s., unit);
+
+r = write_string_file_atomic(unit,
+# Automatically generated by a systemd-fstab-generator or
similar\n\n
+[Unit]\n
+Description=Root File System Check Placeholder\n
+DefaultDependencies=no\n
+Before=shutdown.target\n
+\n
+[Service]\n
+ExecStart=/bin/true\n
+Type=oneshot\n
+RemainAfterExit=yes\n);
+if (r 0)
+log_warning_errno(errno, Failed to write unit file %s:
%m, unit);
+return r;
+}
+
int generator_write_fsck_deps(
FILE *f,
const char *dir,
@@ -79,6 +103,12 @@ int generator_write_fsck_deps(
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
One final question on this topic: I'm not sure from the available discussion of the 'Alias=' directive in systemd.unit(5) whether it might be possible for me to have two units: /lib/systemd/system/dummy-adopted-service.service ... [Unit] DefaultDependencies=no [Service] Type=forking PIDFile=/var/run/already-forked-process.pid ExecStart=/bin/true [Install] Alias=the-service.service Wanted-By=sysinit.target /lib/systemd/system/real-service.service ... [Install] Alias=the-service.service such that clients always phrase their dependencies in terms of the aliased name (the-service.service). At startup time, the virtual unit name would always happen to be satisfied by dummy-adopted-service.service, but any subsequent restarts would be accomplished by systemd noticing that real-service.service exists and using it in preference over dummy-adopted-service.service. My gut feeling is that this approach doesn't play well with the way that 'systemctl enable' wants to place alias symlinks into /etc/systemd/system/. I.e., I think that systemd will only ever recognize one provider of the virtual/aliased service name. Am I wrong in that assessment in the preceding paragraph? On Mon, Apr 20, 2015 at 12:49 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoos...@gmail.com) wrote: inexperienced poking around the internal default suite of units packaged with systemd. This is not available, though often requested. But I doubt this can ever work, since running before 'everything' or running after 'everything' is not particularly usefully defined as this all breaks down as soon as you have two services that want to be run like this Okay, I appreciate that there's no built-in meta-unit that would permit me to say start me to the exclusion of absolutely everything else. I agree that would fail the what if two processes each tried to play that game? test. I was just hoping that some unit exists that is synonymous with the point upon which all traditional systemd work is dependent. I suppose nothing still exists matching that kind of weaker description? E.g., .slice or something like that. You could order yourself before local-fs-pre.target plus the various early-boot services we ship. That list is pretty limited and relatively stable, but there's nothing nicer currently, no. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On 2015-05-06 at 09:16 +0300, Andrei Borzenkov wrote: On Wed, May 6, 2015 at 5:52 AM, Ivan Shapovalov intelfx...@gmail.com wrote: On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote: On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: - do `systemd-run` twice and somehow set up the dependencies between two transient units I'd be happy to take a patch that allows configuring deps for transient units when constructing them. Hi Lennart, I've just done this (also added manager-side support for JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this turned out to be insufficient for my usecase. I have to start two transient services, say, A.service and B.service, and - B.service needs A.service (i. e. B.service Requires=A.service and After=A.service) - A.service must be stopped as soon as B.service exits (i. e. A.service BindsTo=B.service) And there is a contradiction: I can't make a dependency on an inexistent unit. If I create A.service before B.service, I can't set BindsTo=, and if I create B.service before A.service, I can't set Requires= and After=. Locally, I've solved this by allowing inverse dependencies to be set over the bus. That is, I make B.service BoundBy=A.service. Is this acceptable for upstream? What about adding option --define-only (I do not care about actual name) that adds unit definition but does not start unit? Then you can define any number of transient units and then systemctl start them later. I'm unsure how to fit this into the GC logic. Transient units get unloaded (and hence removed from disk) once they become inactive. If we create a transient unit without starting it at the same time (before the GC has a chance to run), it will be immediately removed. -- Ivan Shapovalov / intelfx / 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] journal-.gitignore-add-audit_type-from-name
On Thu, 30.04.15 19:42, Daniel Buch (boogiewasth...@gmail.com) wrote: Zbigniew merged a similar patch today. Thanks! From 785b1367fedb912e91074360c0961209ac5dc9f8 Mon Sep 17 00:00:00 2001 From: Daniel Buch boogiewasth...@gmail.com Date: Thu, 30 Apr 2015 21:20:57 +0200 Subject: [PATCH] journal: .gitignore add audit_type-from-name* --- src/journal/.gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/journal/.gitignore b/src/journal/.gitignore index 0f094f5..94adfb3 100644 --- a/src/journal/.gitignore +++ b/src/journal/.gitignore @@ -2,3 +2,5 @@ /libsystemd-journal.pc /audit_type-list.txt /audit_type-to-name.h +/audit_type-from-name.h +/audit_type-from-name.gperf -- 2.3.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote: Works for me... booted with ro on the kernel cmdline: $ systemctl status systemd-fsck-root.service ● systemd-fsck-root.service - File System Check on Root Device Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static; vendor preset: disabled) Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago Docs: man:systemd-fsck-root.service(8) Main PID: 144 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-fsck-root.service I think tis is really confusing for the admin. he now thinks that this is actually the exit status of the root fsck, but it's atcually just /bin/true. I am pretty sure it's best if we say that systemd-fsck-root.service really always is the fsck of the root fs, regardless if booted with an initrd or not, even if this might mean slightly suboptimal deps within the initrd if you have multiple file systems to mount that early. This would certainly be the friendliest, most discoverable option for admins. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] LPC 2015 Boot, Init, and Config microconf RFC and Invitation
The Boot, Init, and Config microconference is inviting interested parties to comment on proposed topics and show their interest in attending. Proposed topics are at http://wiki.linuxplumbersconf.org/2015:boot_init_and_config, and include containers, tinification, systemd tuning, k/dbus, early kernel tracing, other embedded/fastboot improvements, and an alternative net boot protocol. There are likely more proposed topics than will comfortably fit in a 3-hour microconf, please indicate your attendance and interest on the wiki page so that we can plan accordingly. If you are interested in leading a topic, please let us know! Sincerely, John Mehaffey, Kate Stewart, Matthew Wilson ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) wrote: I still think that being able to define and start group of units as one unit (pun unintended) is better in the long run. This really far exceeds original scope of systemd-run which was quickly start something under systemd supervision. When we have complex set of units with interdependency either systemd-run is the wrong tool for it or it should do it right, not paper over. Hmm, you actually have a point, and we already *do* support queuing groups of units, and that should suffice for this usecase, so that we don't need to allow definiton of reverse deps. This is actually already used for the time-based systemd-run stuff, where we create both a transient timer and a transient service unit and then start the timer unit. Ivan, what you are trying to do hence should already work just fine in the lower level apis, using the auxiliary list of units that the StartTransientUnt() bus call takes. systemd-run doesn't generically open this up yet though (and i dont know how it could do so nicely). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
В Wed, 6 May 2015 19:13:46 +0200 Lennart Poettering lenn...@poettering.net пишет: Also, I think it's a bit pointless optimizing fsck invocations in setups like this. I mean, if you cared about fsck runtime you probably wouldnt use ext234 anyway, which are really the only file systems used for / or /usr that still require an fsck... It is not about optimization, I used wrong example, sorry for confusion. It is about situation when e.g. root on loop device needs to mount filesystem that contains loop first. It creates dependency loop between root-fsck and fsck for container. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: systemctl: null-initialize pointer with cleanup attribute
On Wed, 06.05.15 08:32, Daniel Buch (boogiewasth...@gmail.com) wrote: Patch attached. (git send-email currently brokken) Looks good! Applied! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
В Wed, 6 May 2015 18:37:00 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 06.05.15 05:52, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote: On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: - do `systemd-run` twice and somehow set up the dependencies between two transient units I'd be happy to take a patch that allows configuring deps for transient units when constructing them. Hi Lennart, I've just done this (also added manager-side support for JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this turned out to be insufficient for my usecase. I have to start two transient services, say, A.service and B.service, and - B.service needs A.service (i. e. B.service Requires=A.service and After=A.service) - A.service must be stopped as soon as B.service exits (i. e. A.service BindsTo=B.service) And there is a contradiction: I can't make a dependency on an inexistent unit. If I create A.service before B.service, I can't set BindsTo=, and if I create B.service before A.service, I can't set Requires= and After=. Locally, I've solved this by allowing inverse dependencies to be set over the bus. That is, I make B.service BoundBy=A.service. Is this acceptable for upstream? Ah, Yuck. Grrr.. Hmpf. I figure the best way indeed is to allow reverse deps to be passed when using transient units. Not pretty, but probably OK. But please be careful, and do no blanket open up all kinds of deps, just those where there's a valid case for them, like in yours above. I still think that being able to define and start group of units as one unit (pun unintended) is better in the long run. This really far exceeds original scope of systemd-run which was quickly start something under systemd supervision. When we have complex set of units with interdependency either systemd-run is the wrong tool for it or it should do it right, not paper over. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd mount inactive
On Thu, 30.04.15 15:20, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Lennart Poettering lenn...@poettering.net wrote on 04/30/2015 02:39:45 AM: On Wed, 29.04.15 12:09, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I applied those other commits you listed, and I took a look at the lvm2 package, which was being compile with --disable-udev_sync and --disable-udev_rules. I enabled both of those and recompiled both lvm2 and systemd. Nothing changed. Sometimes var.mount is still bound to an inactive /dev/mapper/name. Well, it will be bound to it, but systemd should not act on it anymore and unmount it. Also, th device should become active as soon as udev ran and reprobed everything. Do I need the *.rules files from lvm2? Well, you do need the DM ones at least. That's actually where the interesting bits are sicne they properly probe the LUKS device and make it available for other components including systemd to pick it up. I added a couple udev rules that are present in the Ubuntu dmsetup package for my distribution, and now I get a couple errors from systemd-udevd: systemd-udevd[153]: conflicting device node '/dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96' found, link to '/dev/dm-1' will not be created systemd-udevd[154]: conflicting device node '/dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c' found, link to '/dev/dm-0' will not be created With status as: dev-mapper-91caea2d\x2d0e19\x2d441e\x2d9ea7\x2d7be1ed345e96.device loadedactivating tentative /dev/mapper/91caea2d-0e19-441e-9ea7-7be1ed345e96 dev-mapper-d8668b2e\x2d3a40\x2d46df\x2d8c64\x2df369a1a7a09c.device loadedactivating tentative /dev/mapper/d8668b2e-3a40-46df-8c64-f369a1a7a09c The system seems to work just fine though, so I'm wondering if I should ignore these errors and move on. I'm sure what the impact is. If they stay tentative then this isn't working correctly. After udev is up and probed the devcies they should really be set to plugged and not tentative anymore. There's something still wrong with your udev rules I fear... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: fix coding style
On Wed, 06.05.15 11:45, Susant Sahani (sus...@redhat.com) wrote:
Actually, we allow the line break there too, even though we prefer to
not have it there. Applied anyway. Thanks!
---
src/udev/net/ethtool-util.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/udev/net/ethtool-util.c b/src/udev/net/ethtool-util.c
index ec67126..927b8ab 100644
--- a/src/udev/net/ethtool-util.c
+++ b/src/udev/net/ethtool-util.c
@@ -93,8 +93,7 @@ int ethtool_get_driver(int *fd, const char *ifname, char
**ret) {
return 0;
}
-int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed,
Duplex duplex)
-{
+int ethtool_set_speed(int *fd, const char *ifname, unsigned int speed,
Duplex duplex) {
struct ethtool_cmd ecmd = {
.cmd = ETHTOOL_GSET
};
--
2.4.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On Wed, 06.05.15 05:52, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote: On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: - do `systemd-run` twice and somehow set up the dependencies between two transient units I'd be happy to take a patch that allows configuring deps for transient units when constructing them. Hi Lennart, I've just done this (also added manager-side support for JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this turned out to be insufficient for my usecase. I have to start two transient services, say, A.service and B.service, and - B.service needs A.service (i. e. B.service Requires=A.service and After=A.service) - A.service must be stopped as soon as B.service exits (i. e. A.service BindsTo=B.service) And there is a contradiction: I can't make a dependency on an inexistent unit. If I create A.service before B.service, I can't set BindsTo=, and if I create B.service before A.service, I can't set Requires= and After=. Locally, I've solved this by allowing inverse dependencies to be set over the bus. That is, I make B.service BoundBy=A.service. Is this acceptable for upstream? Ah, Yuck. Grrr.. Hmpf. I figure the best way indeed is to allow reverse deps to be passed when using transient units. Not pretty, but probably OK. But please be careful, and do no blanket open up all kinds of deps, just those where there's a valid case for them, like in yours above. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On Wed, 06.05.15 09:16, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Wed, May 6, 2015 at 5:52 AM, Ivan Shapovalov intelfx...@gmail.com wrote: On 2015-04-24 at 11:10 +0200, Lennart Poettering wrote: On Fri, 24.04.15 04:07, Ivan Shapovalov (intelfx...@gmail.com) wrote: - do `systemd-run` twice and somehow set up the dependencies between two transient units I'd be happy to take a patch that allows configuring deps for transient units when constructing them. Hi Lennart, I've just done this (also added manager-side support for JoinsNamespaceOf= and RequiresMountsFor=, while at it). However, this turned out to be insufficient for my usecase. I have to start two transient services, say, A.service and B.service, and - B.service needs A.service (i. e. B.service Requires=A.service and After=A.service) - A.service must be stopped as soon as B.service exits (i. e. A.service BindsTo=B.service) And there is a contradiction: I can't make a dependency on an inexistent unit. If I create A.service before B.service, I can't set BindsTo=, and if I create B.service before A.service, I can't set Requires= and After=. Locally, I've solved this by allowing inverse dependencies to be set over the bus. That is, I make B.service BoundBy=A.service. Is this acceptable for upstream? What about adding option --define-only (I do not care about actual name) that adds unit definition but does not start unit? Then you can define any number of transient units and then systemctl start them later. This is incompatible with the GC logic. We drop unreferenced units agressively as soon as they are not active, not failed and not referenced anymore... And we really should continue to do so. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On Wed, 06.05.15 19:12, Lennart Poettering (lenn...@poettering.net) wrote: On Wed, 06.05.15 15:50, Harald Hoyer (harald.ho...@gmail.com) wrote: Works for me... booted with ro on the kernel cmdline: $ systemctl status systemd-fsck-root.service ● systemd-fsck-root.service - File System Check on Root Device Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static; vendor preset: disabled) Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago Docs: man:systemd-fsck-root.service(8) Main PID: 144 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-fsck-root.service I think tis is really confusing for the admin. he now thinks that this is actually the exit status of the root fsck, but it's atcually just /bin/true. I am pretty sure it's best if we say that systemd-fsck-root.service really always is the fsck of the root fs, regardless if booted with an initrd or not, even if this might mean slightly suboptimal deps within the initrd if you have multiple file systems to mount that early. This would certainly be the friendliest, most discoverable option for admins. Also, I think it's a bit pointless optimizing fsck invocations in setups like this. I mean, if you cared about fsck runtime you probably wouldnt use ext234 anyway, which are really the only file systems used for / or /usr that still require an fsck... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Wed, 06.05.15 09:28, Matt Hoosier (matt.hoos...@gmail.com) wrote: One final question on this topic: I'm not sure from the available discussion of the 'Alias=' directive in systemd.unit(5) whether it might be possible for me to have two units: /lib/systemd/system/dummy-adopted-service.service ... [Unit] DefaultDependencies=no [Service] Type=forking PIDFile=/var/run/already-forked-process.pid ExecStart=/bin/true [Install] Alias=the-service.service Wanted-By=sysinit.target /lib/systemd/system/real-service.service ... [Install] Alias=the-service.service such that clients always phrase their dependencies in terms of the aliased name (the-service.service). At startup time, the virtual unit name would always happen to be satisfied by dummy-adopted-service.service, but any subsequent restarts would be accomplished by systemd noticing that real-service.service exists and using it in preference over dummy-adopted-service.service. My gut feeling is that this approach doesn't play well with the way that 'systemctl enable' wants to place alias symlinks into /etc/systemd/system/. I.e., I think that systemd will only ever recognize one provider of the virtual/aliased service name. Yes, each name may only refert to one single unit at a time. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On Wed, 06.05.15 01:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: In the initramfs, we run systemd-fsck@sysroot-device.service. In the real system we run systemd-fsck-root.service. Generate a fake systemd-fsck-root.service if we are running a unit check for the root file system. We don't really care if the real fsck unit fails, because the failure will be handled in some other way. This fake unit is created and pulled in only when we actually plan to check the file system for /sysroot. This way we avoid having an active/exited systemd-fsck-root.service in the main filesystem if we didn't do anything. Hmpf, I really don't like creating fake units like this that fork of /bin/true like this. I am still convinced that always doing the fsck for the root fs in systemd-fsck-root.service is the right way to go, even if the this means more parallelization than strictly necessary for a few setups in the initrd. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On 2015-05-06 at 18:59 +0200, Lennart Poettering wrote: On Wed, 06.05.15 19:53, Andrei Borzenkov (arvidj...@gmail.com) wrote: I still think that being able to define and start group of units as one unit (pun unintended) is better in the long run. This really far exceeds original scope of systemd-run which was quickly start something under systemd supervision. When we have complex set of units with interdependency either systemd-run is the wrong tool for it or it should do it right, not paper over. Hmm, you actually have a point, and we already *do* support queuing groups of units, and that should suffice for this usecase, so that we don't need to allow definiton of reverse deps. This is actually already used for the time-based systemd-run stuff, where we create both a transient timer and a transient service unit and then start the timer unit. Ivan, what you are trying to do hence should already work just fine in the lower level apis, using the auxiliary list of units that the StartTransientUnt() bus call takes. systemd-run doesn't generically open this up yet though (and i dont know how it could do so nicely). Yeah, auxiliary units could help here, though they suffer from the same kind of problem: either auxiliary units are read from message and created before the main one, or vice versa. The problems are the same as with two consecutive StartTransientUnit calls. -- Ivan Shapovalov / intelfx / 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] [PATCH] Generate a fake systemd-fsck-root.service in the initramfs
On 06.05.2015 15:58, Zbigniew JÄdrzejewski-Szmek wrote: On Wed, May 06, 2015 at 03:50:08PM +0200, Harald Hoyer wrote: Works for me... booted with ro on the kernel cmdline: $ systemctl status systemd-fsck-root.service â systemd-fsck-root.service - File System Check on Root Device Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static; vendor preset: disabled) Active: inactive (dead) since Mi 2015-05-06 15:37:58 CEST; 1min 44s ago Docs: man:systemd-fsck-root.service(8) Main PID: 144 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-fsck-root.service [1.440568] systemd[1]: Starting Root File System Check Placeholder... [1.445484] systemd[1]: Started Root File System Check Placeholder. [â¦] [1.786864] systemd[1]: Starting File System Check on /dev/gpt-auto-root... [1.804183] systemd[1]: Started File System Check on /dev/gpt-auto-root. [2.015962] systemd[1]: Mounting /sysroot... [â¦] [2.294428] systemd[1]: Switching root. [â¦] [2.570286] systemd[1]: Stopped Switch Root. [â¦] [2.571714] systemd[1]: Stopped File System Check on Root Device. [2.571859] systemd[1]: Stopping File System Check on Root Device... [â¦] [2.624669] systemd[1]: Started Remount Root and Kernel File Systems. Although Stopping File System Check on Root Device is strange... Hm, that's strange. This would suggest that sd-fsck-root.service is not wanted by anything in your system. I wonder if this is because you have gpt-auto-root, and I'm using plain old fstab. $ systemctl show -p WantedBy,RequiredBy,RequiredByOverridable systemd-fsck-root RequiredBy= RequiredByOverridable= WantedBy=local-fs.target Zbyszek Yeah, strange... changed the cmdline and fstab to UUID. # cat /proc/cmdline initrd=\9e3d4b6532ff41e1ab40d6b4e5609907\4.1.0-0.rc2.git0.1.fc23.x86_64\initrd quiet libahci.ignore_sss=1 raid=noautodetect selinux=0 rhgb plymouth.enable=0 rd.plymouth=0 rw root=UUID=d5e53483-30bc-4119-8c0c-841d47a2f76b rootflags=noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache,subvol=root:foo:hoyer.harald.OS:x86_64 resume=UUID=03ea4b3f-94fd-40c8-81e8-802734082be8 ro # cat /etc/fstab UUID=d5e53483-30bc-4119-8c0c-841d47a2f76b / btrfs subvol=root:foo:hoyer.harald.OS:x86_64,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache 0 0 UUID=d5e53483-30bc-4119-8c0c-841d47a2f76b /usrbtrfs subvol=usr:hoyer.harald.OS:x86_64,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache 0 0 UUID=d5e53483-30bc-4119-8c0c-841d47a2f76b /home/haraldbtrfs subvol=harald,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache 0 0 UUID=03ea4b3f-94fd-40c8-81e8-802734082be8 swap swap defaults 0 0 # systemctl show -p WantedBy,RequiredBy,RequiredByOverridable systemd-fsck-root RequiredBy= RequiredByOverridable= WantedBy= # systemctl status systemd-fsck-root.service â systemd-fsck-root.service - File System Check on Root Device Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; static; vendor preset: disabled) Active: inactive (dead) since Mi 2015-05-06 16:43:58 CEST; 6min ago Docs: man:systemd-fsck-root.service(8) Main PID: 142 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-fsck-root.service # journalctl -b -o short-monotonic |fgrep Root [0.110026] kernel: ACPI: PCI Root Bridge [PCI0] (domain [bus 00-fe]) [1.434239] systemd[1]: Starting Root File System Check Placeholder... [1.439182] systemd[1]: Started Root File System Check Placeholder. [2.149291] systemd[1]: Reached target Initrd Root File System. [2.149580] systemd[1]: Starting Initrd Root File System. [2.150506] systemd[1]: Starting Reload Configuration from the Real Root... [2.223119] systemd[1]: Started Reload Configuration from the Real Root. [2.287822] systemd[1]: Reached target Switch Root. [2.287926] systemd[1]: Starting Switch Root. [2.288312] systemd[1]: Starting Switch Root... [2.570400] systemd[1]: Stopped Switch Root. [2.573577] systemd[1]: Stopped target Switch Root. [2.573613] systemd[1]: Stopping Switch Root. [2.573926] systemd[1]: Stopped target Initrd Root File System. [2.573941] systemd[1]: Stopping Initrd Root File System. [2.604283] systemd[1]: Stopped File System Check on Root Device. [2.604324] systemd[1]: Stopping File System Check on Root Device... [2.604843] systemd[1]: Starting Remount Root and Kernel File Systems... [2.614664] systemd[1]: Started Remount Root and Kernel File Systems. Anyway, after forcing it in: # ll /lib/systemd/system/local-fs.target.wants/systemd-fsck-root.service lrwxrwxrwx 1 root root 28 6. Mai 16:53 /lib/systemd/system/local-fs.target.wants/systemd-fsck-root.service - ../systemd-fsck-root.service I get # systemctl status systemd-fsck-root.service ●
Re: [systemd-devel] Shutting down service using systemd-nspawn
I implemented this now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=c6c8f6e218995852350e5e35c080dec788c42c3f Thanks a lot. Sorry, have seen your mail to late - I'm trying out a new mua (sup) and I'm not that familiar with it yet. Do you think it makes sense to add something like `--pass-signals SIGHUP,SIGINT,SIGWINCH` as well? Making `systemd-nspawn` to pass those signals to PID 1 if it receives those signals. Use case: Either make PID 1 to react on those signals or test how it will react if you're using `systemd-nspawn` to test some software you develop. Thanks a lot. /pp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
