Re: [systemd-devel] [PATCH] cgtop: useful error messages when bootup fails
Uggh, sorry for sending that super-buggy patch. Here is a better
version.
On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote:
cgtop quits on startup if all the cgroup mounts it expects are not ready.
Provide user with some indication of why cgtop failed.
From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001
From: Shawn Landden shawnland...@gmail.com
Date: Mon, 21 May 2012 22:54:41 -0700
Subject: [PATCH] cgtop: useful error messages when bootup fails
cgtop quits on startup if all the cgroup mounts it expects are not ready.
Provide user with some indication of why cgtop failed.
---
src/cgtop/cgtop.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/cgtop/cgtop.c b/src/cgtop/cgtop.c
index ddb5709..493687e 100644
--- a/src/cgtop/cgtop.c
+++ b/src/cgtop/cgtop.c
@@ -340,18 +340,30 @@ static int refresh(Hashmap *a, Hashmap *b, unsigned iteration) {
assert(a);
r = refresh_one(name=systemd, /, a, b, iteration, 0);
-if (r 0)
+if (r 0) {
+if (r == -ENOENT)
+log_error(Is /sys/fs/cgroup/systemd mounted?: %s, strerror(-r));
return r;
-
+}
r = refresh_one(cpuacct, /, a, b, iteration, 0);
-if (r 0)
+if (r 0) {
+if (r == -ENOENT)
+log_error(Is /sys/fs/cgroup/cpu,cpuacct mounted?: %s, strerror(-r));
return r;
-
+}
r = refresh_one(memory, /, a, b, iteration, 0);
if (r 0)
+if (r == -ENOENT)
+log_error(Is /sys/fs/cgroup/memory mounted?: %s, strerror(-r));
return r;
-return refresh_one(blkio, /, a, b, iteration, 0);
+r = refresh_one(blkio, /, a, b, iteration, 0);
+if (r 0) {
+if (r == -ENOENT)
+log_error(Is /sys/fs/cgroup/blkio mounted?: %s, strerror(-r));
+return r;
+}
+return 0;
}
static int group_compare(const void*a, const void *b) {
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 2012-05-22 at 08:40 +0200, Sjoerd Simons wrote:
On Mon, 2012-05-21 at 21:35 -0700, shawn wrote:
If journal_file_open() failed, due to (e.g.) -ENOSPC on open()
new_file might still be NULL.
On error, leave pointer to the old JournalFile (now closed),
and require caller to check for error approiately.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020
Reported-by: Sjoerd Simons sjo...@luon.net
The bugzilla link seems wrong ?
yes, I was looking at your patch, (via debian BTS) but I copied the url
wrong. (corrected patch attached) That is how I knew to forward it to
you. I read your patch, however there are many reasons other than ENOSPC
why open() could fail leaving a null pointer, and my patch takes care of
that.
This actually remind me though, i did submit a patch for this issue to
bugzilla (slightly different then your solution) more then a month ago.
And a companion patch to not make the issue occur so easily, bugs filed
here:
https://bugs.freedesktop.org/show_bug.cgi?id=48688
https://bugs.freedesktop.org/show_bug.cgi?id=48685
If the systemd bugzilla is just somewhat of a decoy i'm happy to repost
the patches to the list ofcourse :)
Well the first patch I submitted to systemd bugzilla sure didn't get any
traction
--
-Shawn Landden
From 54a970dcf59b59ade587002925be027b71d81545 Mon Sep 17 00:00:00 2001
From: Shawn Landden shawnland...@gmail.com
Date: Mon, 21 May 2012 19:46:54 -0700
Subject: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()
If journal_file_open() failed, due to (e.g.) -ENOSPC on open()
new_file might still be NULL.
On error, leave pointer to the old JournalFile (now closed),
and require caller to check for error approiately.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48685
Reported-by: Sjoerd Simons sjo...@luon.net
---
src/journal/journal-file.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 5dd6e57..9f5f26e 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -1871,9 +1871,16 @@ int journal_file_rotate(JournalFile **f) {
old_file-header-state = STATE_ARCHIVED;
r = journal_file_open(old_file-path, old_file-flags, old_file-mode, old_file, new_file);
-journal_file_close(old_file);
+
+if (r 0) {
+r = -errno;
+goto finish;
+}
*f = new_file;
+
+finish:
+journal_file_close(old_file);
return r;
}
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD
Dear systemd folks, hopefully it is alright to report my findings here. If you have any suggestions to improve the startup time, please do not hesitate to tell me. ;-) Hardware • ASRock E350M1 with dual core 1.6 GHz Fusion CPU [1] • Crucial m4 SSD connected via SATA-3-cable [2] • one Ext4 partition Software • default Debian Sid/unstable installed using `grml-debootstrap` and Grml live system • `aptitude purge mdadm lvm2` • `aptitude install systemd` (version 44-1) • `linux-image-3.2.0-2-amd64` (version 3.2.17-1) Results === 1. Passing `init=/bin/systemd` to the Linux kernel command line the GDM 3 login screen showed up noticeably faster. 2. GDM 3 did not list the available users though, which had to be entered manually. After logging out again users are displayed fine. 3. Systemd says start up took 7.5 seconds. $ systemd-analyze Startup finished in 4077ms (kernel) + 3390ms (userspace) = 7468ms 4. All units take less than a second to start. $ systemd-analyze blame 948ms avahi-daemon.service 729ms postfix.service 656ms rsyslog.service 632ms systemd-logind.service 559ms console-kit-log-system-start.service 523ms bootlogs.service 520ms chrony.service 467ms udev.service 451ms rc.local.service 436ms loadcpufreq.service 427ms keymap.service 424ms ssh.service 396ms cron.service 388ms dev-mqueue.mount 367ms systemd-modules-load.service 360ms sys-kernel-debug.mount 340ms udev-trigger.service 327ms systemd-sysctl.service 324ms dev-hugepages.mount 296ms sys-kernel-security.mount 281ms network-manager.service 279ms saned.service 279ms systemd-user-sessions.service 277ms gdm3.service 264ms media.mount 247ms systemd-remount-api-vfs.service 215ms pppd-dns.service 211ms resolvconf.service 199ms systemd-tmpfiles-setup.service 195ms screen-cleanup.service 191ms kbd.service 159ms networking.service 151ms console-setup.service 147ms pulseaudio.service 143ms cpufrequtils.service 91ms hdparm.service 91ms mountoverflowtmp.service 88ms keyboard-setup.service 87ms sysfsutils.service 87ms debian-fixup.service 59ms remount-rootfs.service 59ms colord-sane.service 56ms console-kit-daemon.service 48ms colord.service 44ms polkitd.service 31ms accounts-daemon.service 26ms upower.service 22ms udisks.service 19ms boot-efi.mount 13ms rtkit-daemon.service 5. Also I experience the sudo issue [3]. Conclusions === 1. I should follow the optimization suggestions in the systemd Wiki [4]. 2. Improving loading time of the Linux kernel should be my priority right now. With four seconds it take more than half of the total Debian startup time. I would not have expected that. I guess I need to use `bootchart` to check if the long time is due to the slow 1.6 GHz dual Fusion CPU or if the storage is not set up correctly. 3. It will be interesting if GNOME 3.4 will speed up things too as mentioned in the Wiki [4]. Currently `gnome-shell` 3.2.2.1-4+b1 is installed. Thank you very much for this promising piece of software, Paul [1] http://www.asrock.com/mb/overview.asp?Model=E350M1 [2] http://www.crucial.com/store/partspecs.aspx?imodule=CT256M4SSD2 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667470 [4] http://freedesktop.org/wiki/Software/systemd/Optimizations 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] cgtop: useful error messages when bootup fails
On Mon, 21.05.12 23:04, shawn (shawnland...@gmail.com) wrote: Heya, Uggh, sorry for sending that super-buggy patch. Here is a better version. On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote: cgtop quits on startup if all the cgroup mounts it expects are not ready. Provide user with some indication of why cgtop failed. From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001 From: Shawn Landden shawnland...@gmail.com Date: Mon, 21 May 2012 22:54:41 -0700 Subject: [PATCH] cgtop: useful error messages when bootup fails cgtop quits on startup if all the cgroup mounts it expects are not ready. Provide user with some indication of why cgtop failed. Hmm, this is misleading. THis has little to do with being ready, as the cgroup VFS are mounted synchronously very early in PID 1 and it is basically very hard to run in parallel with that. So this check actually would check for something different: whether the system was booted with systemd at all, and whether the respective cgroup controller has been enabled in the kernel at all. But for the former an excplicit early check for sd_booted() would probably a nicer choice (though I must say I shiver at the idea that we add this to all our tools). And for the latter we should probably fix things so that the tool works fine even if cpuacct, memory and blkio (or any subset of them are not available), after all those controllers should be optional. How did you start cgtop so that you ran into this problem? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Mon, 2012-05-21 at 21:35 -0700, shawn wrote:
If journal_file_open() failed, due to (e.g.) -ENOSPC on open()
new_file might still be NULL.
On error, leave pointer to the old JournalFile (now closed),
and require caller to check for error approiately.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020
Reported-by: Sjoerd Simons sjo...@luon.net
The bugzilla link seems wrong ?
This actually remind me though, i did submit a patch for this issue to
bugzilla (slightly different then your solution) more then a month ago.
And a companion patch to not make the issue occur so easily, bugs filed
here:
https://bugs.freedesktop.org/show_bug.cgi?id=48688
https://bugs.freedesktop.org/show_bug.cgi?id=48685
If the systemd bugzilla is just somewhat of a decoy i'm happy to repost
the patches to the list ofcourse :)
src/journal/journal-file.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 5dd6e57..9f5f26e 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -1871,9 +1871,16 @@ int journal_file_rotate(JournalFile **f) {
old_file-header-state = STATE_ARCHIVED;
r = journal_file_open(old_file-path, old_file-flags,
old_file-mode, old_file, new_file);
-journal_file_close(old_file);
+
+if (r 0) {
+r = -errno;
+goto finish;
+}
*f = new_file;
+
+finish:
+journal_file_close(old_file);
return r;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 22.05.12 08:40, Sjoerd Simons (sjo...@luon.net) wrote: On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: If journal_file_open() failed, due to (e.g.) -ENOSPC on open() new_file might still be NULL. On error, leave pointer to the old JournalFile (now closed), and require caller to check for error approiately. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 Reported-by: Sjoerd Simons sjo...@luon.net The bugzilla link seems wrong ? This actually remind me though, i did submit a patch for this issue to bugzilla (slightly different then your solution) more then a month ago. And a companion patch to not make the issue occur so easily, bugs filed here: https://bugs.freedesktop.org/show_bug.cgi?id=48688 https://bugs.freedesktop.org/show_bug.cgi?id=48685 If the systemd bugzilla is just somewhat of a decoy i'm happy to repost the patches to the list ofcourse :) Nah, fdo bz is not a decoy. The reason I didnt merge this right away was actually that I wanted to rework the code in question in a bigger way, so that we have some logic in there that we automatically fallback to kmsg logging when the journal for some reason doesn't work. But I never found the time to. Anyway, since this is a bug I have now merged your patch 48685, and we can add the kmsg fallback logic later on. Thanks for your work! About 48688 I am not sure sure. i.e. should we really bind the keep_free stuff to the reserved percentage of the FS? They are two different things, or are they not? Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Fwd: [PATCH] journal: fix dereferenced pointer in journal_file_rotate()]
On Tue, 2012-05-22 at 13:26 +0200, Lennart Poettering wrote: On Tue, 22.05.12 08:40, Sjoerd Simons (sjo...@luon.net) wrote: On Mon, 2012-05-21 at 21:35 -0700, shawn wrote: If journal_file_open() failed, due to (e.g.) -ENOSPC on open() new_file might still be NULL. On error, leave pointer to the old JournalFile (now closed), and require caller to check for error approiately. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 Reported-by: Sjoerd Simons sjo...@luon.net The bugzilla link seems wrong ? This actually remind me though, i did submit a patch for this issue to bugzilla (slightly different then your solution) more then a month ago. And a companion patch to not make the issue occur so easily, bugs filed here: https://bugs.freedesktop.org/show_bug.cgi?id=48688 https://bugs.freedesktop.org/show_bug.cgi?id=48685 If the systemd bugzilla is just somewhat of a decoy i'm happy to repost the patches to the list ofcourse :) Nah, fdo bz is not a decoy. The reason I didnt merge this right away was actually that I wanted to rework the code in question in a bigger way, so that we have some logic in there that we automatically fallback to kmsg logging when the journal for some reason doesn't work. But I never found the time to. Aha! A note on the bug would have been great :). Anyway, since this is a bug I have now merged your patch 48685, and we can add the kmsg fallback logic later on. Thanks for your work! Np, thanks for merging :). About 48688 I am not sure sure. i.e. should we really bind the keep_free stuff to the reserved percentage of the FS? They are two different things, or are they not? I'm not sure either as i mentioned in the bugreport. The standard 5% is a bit odd though. Although I may be a bit odd, but my / partition tends to never have a lot of free space, which means it's basically always below the 5% (Which is still more then 0.5G on a 10G system..). I picked up using the reserved precentage mostly as it's the one place i could think of where there is currently a configuration for leave this much space free please. Furthermore it means that you get a no space error only when df shows you have 0 available space which is nice i'd think :).. It took me quite some time to figure out why journald was giving out of space errors while df was happily showing there was still quite a bit of space left. -- Sjoerd Simons sjo...@luon.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: rm_rf_children() add root_dev parameter
From: Harald Hoyer har...@redhat.com
if root_dev is set, remove subdirectories only, if the device is the
same as the root_dev. This prevents to remove files across device
boundaries.
---
src/shared/util.c | 39 ++-
src/shared/util.h |2 +-
2 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index bfa9509..e6afc50 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3131,7 +3131,7 @@ int get_ctty(pid_t pid, dev_t *_devnr, char **r) {
return 0;
}
-int rm_rf_children(int fd, bool only_dirs, bool honour_sticky) {
+int rm_rf_children(int fd, bool only_dirs, bool honour_sticky, struct stat
*root_dev) {
DIR *d;
int ret = 0;
@@ -3200,24 +3200,37 @@ int rm_rf_children(int fd, bool only_dirs, bool
honour_sticky) {
if (is_dir) {
int subdir_fd;
-
-subdir_fd = openat(fd, de-d_name,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_NOFOLLOW|O_NOATIME);
-if (subdir_fd 0) {
-if (ret == 0 errno != ENOENT)
-ret = -errno;
-continue;
+struct stat sb;
+if (root_dev) {
+if (fstatat(fd, de-d_name, sb,
AT_SYMLINK_NOFOLLOW)) {
+if (ret == 0 errno != ENOENT)
+ret = -errno;
+continue;
+}
}
-r = rm_rf_children(subdir_fd, only_dirs,
honour_sticky);
-if (r 0 ret == 0)
-ret = r;
+/* if root_dev is set, remove subdirectories only, if
device is same as dir */
+if ((root_dev == NULL) || (sb.st_dev ==
root_dev-st_dev)) {
-if (!keep_around)
-if (unlinkat(fd, de-d_name, AT_REMOVEDIR)
0) {
+subdir_fd = openat(fd, de-d_name,
+
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC|O_NOFOLLOW|O_NOATIME);
+if (subdir_fd 0) {
if (ret == 0 errno != ENOENT)
ret = -errno;
+continue;
}
+r = rm_rf_children(subdir_fd, only_dirs,
honour_sticky, root_dev);
+if (r 0 ret == 0)
+ret = r;
+
+if (!keep_around)
+if (unlinkat(fd, de-d_name,
AT_REMOVEDIR) 0) {
+if (ret == 0 errno !=
ENOENT)
+ret = -errno;
+}
+}
+
} else if (!only_dirs !keep_around) {
if (unlinkat(fd, de-d_name, 0) 0) {
@@ -3251,7 +3264,7 @@ int rm_rf(const char *path, bool only_dirs, bool
delete_root, bool honour_sticky
return 0;
}
-r = rm_rf_children(fd, only_dirs, honour_sticky);
+r = rm_rf_children(fd, only_dirs, honour_sticky, NULL);
if (delete_root) {
diff --git a/src/shared/util.h b/src/shared/util.h
index 58db27f..698b60b 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -348,7 +348,7 @@ int get_ctty(pid_t, dev_t *_devnr, char **r);
int chmod_and_chown(const char *path, mode_t mode, uid_t uid, gid_t gid);
int fchmod_and_fchown(int fd, mode_t mode, uid_t uid, gid_t gid);
-int rm_rf_children(int fd, bool only_dirs, bool honour_sticky);
+int rm_rf_children(int fd, bool only_dirs, bool honour_sticky, struct stat
*root_dev);
int rm_rf(const char *path, bool only_dirs, bool delete_root, bool
honour_sticky);
int pipe_eof(int fd);
--
1.7.10.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: rm_rf_children() add root_dev parameter
Am 22.05.2012 15:19, schrieb har...@redhat.com: From: Harald Hoyer har...@redhat.com if root_dev is set, remove subdirectories only, if the device is the same as the root_dev. This prevents to remove files across device boundaries. --- src/shared/util.c | 39 ++- src/shared/util.h |2 +- 2 files changed, 27 insertions(+), 14 deletions(-) please ignore.. it's already in ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] switch-root: do not use close old_root_fd after rm_rf_children()
From: Harald Hoyer har...@redhat.com
rm_rf_children() has already closed the fd with closedir().
---
src/core/switch-root.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/core/switch-root.c b/src/core/switch-root.c
index ed0a31e..9832a52 100644
--- a/src/core/switch-root.c
+++ b/src/core/switch-root.c
@@ -111,8 +111,10 @@ int switch_root(const char *new_root) {
if (fstat(old_root_fd, rb) 0)
log_warning(Failed to stat old root directory,
leaving: %m);
-else
+else {
rm_rf_children(old_root_fd, false, false, rb);
+old_root_fd = -1;
+}
}
r = 0;
--
1.7.10.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] switch-root: do not use close_nointr_nofail()
Am 22.05.2012 15:19, schrieb har...@redhat.com: From: Harald Hoyer har...@redhat.com rm_rf_children() might have already closed the fd with closedir(). We just don't know. revised patch sent ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] switch-root: do not use close old_root_fd after rm_rf_children()
On Tue, 22.05.12 15:28, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com rm_rf_children() has already closed the fd with closedir(). Thanks! Applied! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD
2012/5/22 Paul Menzel paulepan...@users.sourceforge.net: 2. GDM 3 did not list the available users though, which had to be entered manually. After logging out again users are displayed fine. The user list is populated via accountsservice. A D-Bus activated system service. accounts-daemon.service shows up in your list above. So I'm wondering if there is genuine bug / race in the way gdm interacts with accountsdaemon. -- 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] [PATCH] cgtop: useful error messages when bootup fails
On Tue, 2012-05-22 at 13:12 +0200, Lennart Poettering wrote: On Mon, 21.05.12 23:04, shawn (shawnland...@gmail.com) wrote: Heya, Uggh, sorry for sending that super-buggy patch. Here is a better version. On Mon, 2012-05-21 at 22:59 -0700, Shawn Landden wrote: cgtop quits on startup if all the cgroup mounts it expects are not ready. Provide user with some indication of why cgtop failed. From 33fa72fdbed3e82d9910e8ecf4b04502fe266ebf Mon Sep 17 00:00:00 2001 From: Shawn Landden shawnland...@gmail.com Date: Mon, 21 May 2012 22:54:41 -0700 Subject: [PATCH] cgtop: useful error messages when bootup fails cgtop quits on startup if all the cgroup mounts it expects are not ready. Provide user with some indication of why cgtop failed. Hmm, this is misleading. THis has little to do with being ready, as the cgroup VFS are mounted synchronously very early in PID 1 and it is basically very hard to run in parallel with that. So this check actually would check for something different: whether the system was booted with systemd at all, and whether the respective cgroup controller has been enabled in the kernel at all. But for the former an excplicit early check for sd_booted() would probably a nicer choice (though I must say I shiver at the idea that we add this to all our tools). And for the latter we should probably fix things so that the tool works fine even if cpuacct, memory and blkio (or any subset of them are not available), after all those controllers should be optional. 100% agree. How did you start cgtop so that you ran into this problem? On an armel system running systemd, but which doesn' have the memory (or blkid) cgroups sections, I presume because I didn't compile them in. (I'd rather not have the overhead of the memory one) I had to use strace to get any idea why it didn't work. I ran across a similar issue with nspawn before. Alot of these tools require specific kernel features, and why they fail correctly they don't really give useful error messages. Lennart -- -Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there a general inittab entry replacement available?
Hi, I found out about systemd because openSUSE uses it now. I read the annoncement and the three updates of it and some more and can say I like systemd a lot. It just seems to be the right way to do process/service management. As it happens I also like IBM DB2 a lot (for other reasons). DB2 is closed source (I hope you dont stop reading now) and it installs an inittab entry. fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor Coordinator You know that this does no longer work. I guess the details how such processes are started with SysV init (environment, time of first start, how to respawn, ...) are common or even standardized, and from what I read so far I think it can be easily modeled with systemd for someone knowing SysV init and systemd a little better than me. I found some getty examples but I must admit I failed to understand all the details yet. Inittab is a very old, very widely spread concept so I have hope you even have thought about porting something like this in a generic way already and I just failed to find it? Thought I ask before I try to reinvent the wheel in a try and error fashion :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 9:26 PM, Bardur Arantsson s...@scientician.net wrote: On 05/22/2012 08:03 PM, Lennart Poettering wrote: just a quick heads-up. I just commited to git some work that rips out the fstab parsing from PID 1 and places this in a generator instead. The idea is that sooner or later we only parse native unit files from PID 1, and everything else is transformed as needed with generators. This makes the core a bit smaller and simplifies a lot of things. This is quite a substantial change, and hence I am not sure I got it all right. I am writing this mail for two reasons: to warn you that current git might break your boot more likely then usually, and secondly: please test this, especially if you have a more complex setup with nofail, noauto and x-systemd.automount in the mix! Speaking of which... does the code actually check for x-systemd.automount or x-systemd-automount now? The doc and code were inconsistent about this. (I brought it up here: http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/4990 previously) http://cgit.freedesktop.org/systemd/systemd/commit/?id=92a39ae1989a7583d696afd4c89990aea802e9ea Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 9:27 PM, Joachim Banzhaf joachim.banz...@googlemail.com wrote: I found out about systemd because openSUSE uses it now. I read the annoncement and the three updates of it and some more and can say I like systemd a lot. It just seems to be the right way to do process/service management. As it happens I also like IBM DB2 a lot (for other reasons). DB2 is closed source (I hope you dont stop reading now) and it installs an inittab entry. fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor Coordinator You know that this does no longer work. I guess the details how such processes are started with SysV init (environment, time of first start, how to respawn, ...) are common or even standardized, and from what I read so far I think it can be easily modeled with systemd for someone knowing SysV init and systemd a little better than me. I found some getty examples but I must admit I failed to understand all the details yet. Inittab is a very old, very widely spread concept so I have hope you even have thought about porting something like this in a generic way already and I just failed to find it? Thought I ask before I try to reinvent the wheel in a try and error fashion :) No there is no support for inittab. All proper services started by systemd can behave the way like inittab provided in the past. But they need systemd .service files. Should be trivial to manually write and add a service file for the above mentioned use case, there is no built-in support in systemd. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 09:27:34PM +0200, Joachim Banzhaf wrote: As it happens I also like IBM DB2 a lot (for other reasons). DB2 is closed source (I hope you dont stop reading now) and it installs an inittab entry. fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor Coordinator You know that this does no longer work. Inittab is a very old, very widely spread concept so I have hope you even have thought about porting something like this in a generic way already and I just failed to find it? inittab is not used on general Linux for few years already. Most distros switched to upstart some time ago, upstart isn't parsing inittab (except for default runlevel). The line you provided translates to following systemd unit: /etc/systemd/system/fmc.service --- [Unit] Description=DB2 Fault Monitor Coordinator [Service] ExecStart=/opt/ibm/db2/V10.1/bin/db2fmcd Restart=always [Install] WantedBy=multi-user.target --- It simple, but let me describe it: fmc becomes service name - fmc.service 2345 is not directly mappable. There are no runlevels with systemd. multi-user.target is roughly equivalent of all system services started. If your inittab had 1 here (single user), you would want WantedBy=rescue.target in [Install] session. Please see man systemd.special for description of other targets. respawn becomes Restart=always The command itself lands in ExecStart=; because this command do not daemonize (requisite for being in inittab), you can skip Type= declaration. It will default to simple. You can put comment in Description field. You are now only systemctl enable fmc.service away of emulating inittab. Above unit definition is really simple but fully replaces inittab entry. However, please look at man pages of systemd.exec and systemd.service. You will find many way to augment this unit (various limits, chroot, running as specific user, group etc). -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Thanks for your answers, all three of them! Am 22.05.2012 21:42, schrieb Tomasz Torcz: Restart=always AFAIK SysV init restarts the service on failures immediatelly for some times, then uses a delay of some minutes before it retries, which seems sensible. If I understand systemd.service man correctly this is not possible? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Am 22.05.2012 22:06, schrieb Joachim Banzhaf: Thanks for your answers, all three of them! Am 22.05.2012 21:42, schrieb Tomasz Torcz: Restart=always AFAIK SysV init restarts the service on failures immediatelly for some times, then uses a delay of some minutes before it retries, which seems sensible. If I understand systemd.service man correctly this is not possible? Restart=always RestartSec=1 this way it doe snot flood your system and prevents race conditions, after too much retries systemd will stop restarting (no value at my hands) i use this for ALL relevant services (mail, http, mysql, samba, asterisk) since months on every production server with no single problem signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, May 22, 2012 at 10:06:04PM +0200, Joachim Banzhaf wrote: Thanks for your answers, all three of them! Am 22.05.2012 21:42, schrieb Tomasz Torcz: Restart=always AFAIK SysV init restarts the service on failures immediatelly for some times, then uses a delay of some minutes before it retries, which seems sensible. If I understand systemd.service man correctly this is not possible? You are looking for StartLimitInterval=, StartLimitBurst= in that manpage. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to set complex environment for apache?
Me again :) I use apache to serve php pages that connect to a DB2 database via the php_pdo interface. For this to work, I have to set a DB2 specific environment. To make that easy, there is a shell script provided that does the necessary adjustments (db2profile). With SysV init I sourced that script in /etc/sysctl/apache2 and all was fine. That does no longer work. I guess systemd interprets that file differently? Are there alternatives? I mean, other than mimicking db2profile which would need to be verifyed (and posibly adapted) after every software update. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Am 22.05.2012 22:13, schrieb Tomasz Torcz: On Tue, May 22, 2012 at 10:06:04PM +0200, Joachim Banzhaf wrote: Thanks for your answers, all three of them! Am 22.05.2012 21:42, schrieb Tomasz Torcz: Restart=always AFAIK SysV init restarts the service on failures immediatelly for some times, then uses a delay of some minutes before it retries, which seems sensible. If I understand systemd.service man correctly this is not possible? You are looking for StartLimitInterval=, StartLimitBurst= in that manpage. Not in my version. Maybe openSUSE is a bit behind (v37) - you guys move fast! Anyways, if systemd gives up eventually by default, like Harald said, that is good enough for me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
It sets and modifies environment variables. I'll have a look and try, thanks. sorry for smartphone brevity ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
On 05/22/2012 10:46 PM, Joachim Banzhaf wrote: It sets and modifies environment variables. I'll have a look and try, See also Environment= and EnvironmentFile= in systemd.exec(5). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
On 05/22/2012 10:16 PM, Joachim Banzhaf wrote: Me again :) I use apache to serve php pages that connect to a DB2 database via the php_pdo interface. For this to work, I have to set a DB2 specific environment. To make that easy, there is a shell script provided that does the necessary adjustments (db2profile). With SysV init I sourced that script in /etc/sysctl/apache2 and all was fine. That does no longer work. I guess systemd interprets that file differently? Are there alternatives? I mean, other than mimicking db2profile which would need to be verifyed (and posibly adapted) after every software update. What does this script do? Depending on the details, ExecStartPre might be what you're looking for. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, May 22, 2012 at 11:13 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Lennart, Kay: I hate you damn it! :-D I have nothing against you beside that you talk total nonsense below. :) Man, how can a fstab file be so complex to justify it? It's simpler than the service files we already load. Now to simply parse /etc/fstab we need to call a generator, that parses (was being done already), generates a new file, that triggers inotify, that calls systemd, that parses it again. Ouch, that's cumbersome at least, slow at last! Inotify? Calls systemd? Parses again? Dome already? In the above paragraph almost all wrong. One suggestion at IRC was to just keep systemd mount units. But if we should go this route, then we should call to deprecate /etc/fstab. Last time we discussed about it, people said it was not going to happen since some tools were parsing and relying on it. Whats is the way to go? The only way I thing this is sane is if we call to deprecate /etc/fstab. Otherwise it's total bs :-P PS: please stop increasing my pid count... you know I hate it! PS2: ls /usr/lib/systemd/system/systemd-* crie out loud! I ignored the rest of it, it would not have ended good for you if I continued to comment. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
