[systemd-devel] systemd installation
Hi experts, I am new to systemd and have some questions, Is it work for rhel 5 and 6 ? From where I can download package for rhel 5 and 6 After installing will it provide basic functionality or I have to start configuring all services which are currently configured with initscripts Any document I can reffer to ? Regards, Dhaval ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Journalctl and sshd disconnects
Hi, Couple of questions... At the moment (195) journalctl _SYSTEMD_UNIT=sshd.service prints out most sshd logs, but skips user disconnections/logouts. These seem to be logged under the UID of the user that logged out and are stored in a separate journal. Why is this? journalctl _COMM=sshd matches all logs, including disconnects, but _EXE=/usr/sbin/sshd skips disconnections. There seems to be some inconsistency here, so I was wondering what's the best way to filter for all sshd info, rather than having to resort to dumping the journal and grep'ing. Thanks, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/5] journal: fix memleak, call set_free before return
---
src/journal/coredumpctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c
index 5c442ff..aa946ae 100644
--- a/src/journal/coredumpctl.c
+++ b/src/journal/coredumpctl.c
@@ -57,7 +57,7 @@ static Set *new_matches(void) {
tmp = strdup(MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1);
if (!tmp) {
log_oom();
-set_clear_free(set);
+set_free(set);
return NULL;
}
@@ -65,7 +65,7 @@ static Set *new_matches(void) {
if (r 0) {
log_error(failed to add to set: %s, strerror(-r));
free(tmp);
-set_clear_free(set);
+set_free(set);
return NULL;
}
--
1.7.11.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/5] localectl: fix memleak, jump to finish before returning
---
src/locale/localectl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index c05eba0..84feb25 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -354,7 +354,8 @@ static int list_locales(DBusConnection *bus, char **args,
unsigned n) {
h-locrectab_offset + h-locrectab_size st.st_size ||
h-sumhash_offset + h-sumhash_size st.st_size) {
log_error(Invalid archive file.);
-return -EBADMSG;
+r = -EBADMSG;
+goto finish;
}
e = (const struct namehashent*) ((const uint8_t*) p +
h-namehash_offset);
--
1.7.11.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/5] localectl: fix memleak, use _cleanup_strv_free_
l might contain zero strings, however there is still memory
allocated for NULL terminator, use _cleanup_strv_free_ instead to
prevent tiny leak in such case.
---
src/locale/localectl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/locale/localectl.c b/src/locale/localectl.c
index 84feb25..7d3ac0a 100644
--- a/src/locale/localectl.c
+++ b/src/locale/localectl.c
@@ -483,7 +483,8 @@ static int nftw_cb(
}
static int list_vconsole_keymaps(DBusConnection *bus, char **args, unsigned n)
{
-char **l, **i;
+char _cleanup_strv_free_ **l = NULL;
+char **i;
keymaps = set_new(string_hash_func, string_compare_func);
if (!keymaps)
@@ -513,7 +514,6 @@ static int list_vconsole_keymaps(DBusConnection *bus, char
**args, unsigned n) {
STRV_FOREACH(i, l)
puts(*i);
-strv_free(l);
return 0;
}
--
1.7.11.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/5] coredumpctl: null check before dereferencing
---
src/journal/coredumpctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/journal/coredumpctl.c b/src/journal/coredumpctl.c
index aa946ae..800e43f 100644
--- a/src/journal/coredumpctl.c
+++ b/src/journal/coredumpctl.c
@@ -220,9 +220,10 @@ static int retrieve(sd_journal *j, const char *name, const
char **var) {
field = strlen(name) + 1; // name + =
assert(len = field);
+assert(var);
*var = strndup((const char*)data + field, len - field);
-if (!var)
+if (!*var)
return log_oom();
return 0;
--
1.7.11.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add zsh completion
On Fri, Oct 26, 2012 at 05:58:41AM -0400, Daniel Wallace wrote: From: Daniel Wallace daniel.wall...@gatech.edu I updated the zsh completion from zsh, and added completion for all the other *ctl commands --- Makefile.am| 4 + bash-completion/systemd-zsh-completion.zsh | 718 + 2 files changed, 722 insertions(+) create mode 100644 bash-completion/systemd-zsh-completion.zsh Why duplicate the entire completion file here, and not just offer the additions to ZSH's upstream? Have you talked to the ZSH devs about this? /confused ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com): On Thu, 2012-10-25 at 20:30 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: On Thu, 25.10.12 11:59, Michael H. Warfield (m...@wittsend.com) wrote: I've got some more problems relating to shutting down containers, some of which may be related to mounting tmpfs on /run to which /var/run is symlinked to. We're doing halt / restart detection by monitoring utmp in that directory but it looks like utmp isn't even in that directory anymore and mounting tmpfs on it was always problematical. We may have to have a more generic method to detect when a container has shut down or is restarting in that case. I can't parse this. The system call reboot() is virtualized for containers just fine and the container managaer (i.e. LXC) can check for that easily. The problem we have had was with differentiating between reboot and halt to either shut the container down cold or restarted it. You say easily and yet we never came up with an easy solution and monitored utmp instead for the next runlevel change. What is your easy solution for that problem? I think you're on older kernels, where we had to resort to that. Pretty recently Daniel Lezcano's patch was finally accepted upstream, which lets a container call reboot() and lets the parent of init tell whether it called reboot or shutdown by looking at wTERMSIG(status). Now THAT is wonderful news! I hadn't realized that had been accepted. So we no longer need to rely on the old utmp kludge? Yup :) It was very liberating, in terms of what containers can do with mounting. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
Adding in the lxc-devel list. On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: Hey Serge, On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: ... Oh, sorry - I take back that suggestion :) Note that we have mount hooks, so templates could install a mount hook to mount a tmpfs onto /dev and populate it. Ok... I've done some cursory search and turned up nothing but some comments about pre mount hooks. Where is the documentation about this feature and how I might use / implement it? Some examples would probably suffice. Is there a require release version of lxc-utils? I think I found what I needed in the changelog here: http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg01490.html I'll play with it and report back. Also the Lifecycle management hooks section in https://help.ubuntu.com/12.10/serverguide/lxc.html This isn't working... Based on what was in both of those articles, I added this entry to another container (Plover) to test... lxc.hook.mount = /var/lib/lxc/Plover/mount When I run lxc-start -n Plover, I see this: [root@forest ~]# lxc-start -n Plover lxc-start: unknow key lxc.hook.mount lxc-start: failed to read configuration file I'm running the latest rc... [root@forest ~]# rpm -qa | grep lxc lxc-0.8.0.rc2-1.fc16.x86_64 lxc-libs-0.8.0.rc2-1.fc16.x86_64 lxc-doc-0.8.0.rc2-1.fc16.x86_64 Is it something in git that hasn't made it to a release yet? nm... I see it. It's in git and hasn't made it to a release. I'm working on a git build to test now. If this is something that solves some of this, we need to move things along here and get these things moved out. According to git, 0.8.0rc2 was 7 months ago? What's the show stoppers here? While the git repo says 7 months ago, the date stamp on the lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. Sounds like we've accumulated some features (like the hooks) we are going to need like months ago to deal with this systemd debacle. How close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just waiting on some more features? Note that I'm thinking that having lxc-start guess how to fill in /dev is wrong, because different distros and even different releases of the same distros have different expectations. For instance ubuntu lucid wants /dev/shm to be a directory, while precise+ wants a symlink. So somehow the template should get involved, be it by adding a hook, or simply specifying a configuration file which lxc uses internally to decide how to create /dev. I agree this needs to be by some sort of convention or template that we can adjust. Personally I'd prefer if /dev were always populated by the templates, and containers (i.e. userspace) didn't mount a fresh tmpfs for /dev. But that does complicate userspace, and we've seen it in debian/ubuntu as well (i.e. at certain package upgrades which rely on /dev being cleared after a reboot). -serge Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
Quoting Lennart Poettering (lenn...@poettering.net): On Thu, 25.10.12 14:02, Serge Hallyn (serge.hal...@canonical.com) wrote: Ok... I've done some cursory search and turned up nothing but some comments about pre mount hooks. Where is the documentation about this feature and how I might use / implement it? Some examples would probably suffice. Is there a require release version of lxc-utils? I think I found what I needed in the changelog here: http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg01490.html I'll play with it and report back. Also the Lifecycle management hooks section in https://help.ubuntu.com/12.10/serverguide/lxc.html Note that I'm thinking that having lxc-start guess how to fill in /dev is wrong, because different distros and even different releases of the same distros have different expectations. For instance ubuntu lucid wants /dev/shm to be a directory, while precise+ wants a symlink. So somehow the template should get involved, be it by adding a hook, or simply specifying a configuration file which lxc uses internally to decide how to create /dev. /dev/shm can be created/mounted/symlinked by the OS in the container. This is nothing LXC should care about. My recommendation for LXC would be to unconditionally pre-mount /dev as tmpfs, and add exactly the device nodes /dev/null, /dev/zero, /dev/full, /dev/urandom, /dev/random, /dev/tty, /dev/ptmx to it. That is the minimal set you need to boot a machine. All further submounts/symlinks/dirs can be created by the OS boot logic in the container. I'm thinking we'll do that, optionally. Templates (including fedora and ubuntu) can simply always set the option to mount and fill /dev. Others (like busybox and mini-sshd) won't. That's what libvirt-lxc and nspawn do, and is what we defined in: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface It would be good if LXC would do the same in order to minimize the manual user configuration necessary. Lennart Agreed it simplifies things for full system containers with modern distros. thanks, -serge ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
Quoting Michael H. Warfield (m...@wittsend.com): Adding in the lxc-devel list. On Thu, 2012-10-25 at 22:59 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 15:42 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 14:02 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): On Thu, 2012-10-25 at 13:23 -0400, Michael H. Warfield wrote: Hey Serge, On Thu, 2012-10-25 at 11:19 -0500, Serge Hallyn wrote: ... Oh, sorry - I take back that suggestion :) Note that we have mount hooks, so templates could install a mount hook to mount a tmpfs onto /dev and populate it. Ok... I've done some cursory search and turned up nothing but some comments about pre mount hooks. Where is the documentation about this feature and how I might use / implement it? Some examples would probably suffice. Is there a require release version of lxc-utils? I think I found what I needed in the changelog here: http://www.mail-archive.com/lxc-devel@lists.sourceforge.net/msg01490.html I'll play with it and report back. Also the Lifecycle management hooks section in https://help.ubuntu.com/12.10/serverguide/lxc.html This isn't working... Based on what was in both of those articles, I added this entry to another container (Plover) to test... lxc.hook.mount = /var/lib/lxc/Plover/mount When I run lxc-start -n Plover, I see this: [root@forest ~]# lxc-start -n Plover lxc-start: unknow key lxc.hook.mount lxc-start: failed to read configuration file I'm running the latest rc... [root@forest ~]# rpm -qa | grep lxc lxc-0.8.0.rc2-1.fc16.x86_64 lxc-libs-0.8.0.rc2-1.fc16.x86_64 lxc-doc-0.8.0.rc2-1.fc16.x86_64 Is it something in git that hasn't made it to a release yet? nm... I see it. It's in git and hasn't made it to a release. I'm working on a git build to test now. If this is something that solves some of this, we need to move things along here and get these things moved out. According to git, 0.8.0rc2 was 7 months ago? What's the show stoppers here? While the git repo says 7 months ago, the date stamp on the lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. Sounds like we've accumulated some features (like the hooks) we are going to need like months ago to deal with this systemd debacle. How close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just waiting on some more features? Daniel has simply been too busy. Stéphane has made a new branch which cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Lxc-users] Unable to run systemd in an LXC / cgroup container.
On Fri, 2012-10-26 at 09:07 -0500, Serge Hallyn wrote: Quoting Michael H. Warfield (m...@wittsend.com): nm... I see it. It's in git and hasn't made it to a release. I'm working on a git build to test now. If this is something that solves some of this, we need to move things along here and get these things moved out. According to git, 0.8.0rc2 was 7 months ago? What's the show stoppers here? While the git repo says 7 months ago, the date stamp on the lxc-0.8.0-rc2 tarball is from July 10, so about 3-1/2 months ago. Sounds like we've accumulated some features (like the hooks) we are going to need like months ago to deal with this systemd debacle. How close are we to either 0.8.0rc3 or 0.8.0? Any blockers or are we just waiting on some more features? Daniel has simply been too busy. Don't I know THAT feeling all too well. Over on the Samba Team (where I'm the chief security consultant on the team) we're all too busy with juggling our domain and our web cert. On top of that, I've got my day job (of course). On top of that, I've got about six other OpenSource projects I'm juggling (including this one). On top of that, I've got a consulting customer that's going through fits. And the beat goes on. I'll test out things as fast as I can. I need this. This suddenly got very interesting as soon as we had a thread to pick at on the systemd ball of yarn. Stéphane has made a new branch which cherrypicks 50 bugfixes for 0.8.0, with the remaining patches (about twice as many) left for 0.9.0. I'm hoping we get 0.8.0 next week :) I'm hoping the hook patches are in that cherry picked basket. We really need them if that's what it takes to make this work. Looking forward to it. :-)=) I'm going to look further into this whole redirect /dev/console to a log hang thing. That's not good and may need to be resolved soon as well. I can live with losing the vty's although I disagree with Stéphan's arguments. They (systemd) are behaving significantly different from sysvinit and upstart and they claim they want to be transparent? Not. No matter. We need to make that work properly as well, agree with them or disagree with them. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] Add zsh completion
On Fri, Oct 26, 2012 at 08:41:50AM -0400, Dave Reisner wrote: On Fri, Oct 26, 2012 at 05:58:41AM -0400, Daniel Wallace wrote: From: Daniel Wallace daniel.wall...@gatech.edu I updated the zsh completion from zsh, and added completion for all the other *ctl commands --- Makefile.am| 4 + bash-completion/systemd-zsh-completion.zsh | 718 + 2 files changed, 722 insertions(+) create mode 100644 bash-completion/systemd-zsh-completion.zsh Why duplicate the entire completion file here, and not just offer the additions to ZSH's upstream? Have you talked to the ZSH devs about this? /confused I did email the zsh-workers list, and the only response I got was Do what works and since systemd keeps changing and releases far more often than zsh does, I feel that it should just be in the upstream package, instead of in /usr/share/zsh/functions/Completion/Unix/_systemd. so I updated it and sent it here :) Thanks -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology pgpH66uihfRTk.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: On Thu, 25.10.12 11:59, Michael H. Warfield (m...@wittsend.com) wrote: http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes Unfortunately, in our case, merely getting a mount in there is a complication in that it also has to be populated but, at least, we understand the problem set now. Ok... Serge and I were corresponding on the lxc-users list and he had a suggestion that worked but I consider to be a bit of a sub-optimal workaround. Ironically, it was to mount devtmpfs on /dev. We don't (currently) have a method to auto-populate a tmpfs mount with the needed devices and this provided it. It does have a problem that makes me uncomfortable in that the container now has visibility into the hosts /dev system. I'm a security expert and I'm not comfortable with that solution even with the controls we have. We can control access but still, not happy with that. That's a pretty bad idea, access control to the device nodes in devtmpfs is controlled by the host's udev instance. That means if your group/user lists in the container and the host differ you already lost. Also access control in udev is dynamic, due to stuff like uaccess and similar. You really don't want to to have that into the container, i.e. where device change ownership all the time with UIDs/GIDs that make no sense at all in the container. Concur. In general I think it's a good idea not to expose any real devices to the container, but only the virtual ones that are programming APIs. That means: no /dev/sda, or /dev/ttyS0, but /dev/null, /dev/zero, /dev/random, /dev/urandom. And creating the latter in a tmpfs is quite simple. If I run lxc-console (which attaches to one of the vtys) it gives me nothing. Under sysvinit and upstart I get vty login prompts because they have started getty on those vtys. This is important in case network access has not started for one reason or another and the container was started detached in the background. The getty behaviour of systemd in containers is documented here: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface Sorry. This is unacceptable. We need some way that these will be active and you will be consistent with other containers. If LXC mounts ptys on top of the VT devices that's a really bad idea too, since /dev/tty1 and friends expose a number of APIs beyond the mere tty device that you cannot emulate with that. It includes files in /sys, as well as /dev/vcs and /dev/vcsa, various ioctls, and so on. Heck, even the most superficial of things, the $TERM variable will be incorrect. LXC shouldn't do that. REGARDLESS. I'm in this situation now testing what I thought was a hang condition (which is proving to be something else). I started a container detached redirecting the console to a file (a parameter I was missing) and the log to another file (which I had been doing). But, for some reason, sshd is not starting up. I have no way to attach to the bloody console of the container and I have no getty's on a vty I can attach to using lxc-console and I can't remote access a container which, for all other intents and purposes, appears to be running fine. Parameterize this bloody thing so we can have control over it. LXC really shouldn't pretent a pty was a VT tty, it's not. From the libvirt guys it has been proposed that we introduce a new env var to pass to PID 1 of the container, that simply lists ptys to start gettys on. That way we don't pretend anything about ttys that the ttys can't hold and have a clean setup. I SUSPECT the hang condition is something to do with systemd trying to start and interactive console on /dev/console, which sysvinit and upstart do not do. Yes, this is documented, please see the link I already posted, and which I linked above a second time. I've got some more problems relating to shutting down containers, some of which may be related to mounting tmpfs on /run to which /var/run is symlinked to. We're doing halt / restart detection by monitoring utmp in that directory but it looks like utmp isn't even in that directory anymore and mounting tmpfs on it was always problematical. We may have to have a more generic method to detect when a container has shut down or is restarting in that case. I can't parse this. The system call reboot() is virtualized for containers just fine and the container managaer (i.e. LXC) can check for that easily. Lennart -- Lennart Poettering - Red Hat, Inc. -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: On Thu, 25.10.12 11:59, Michael H. Warfield (m...@wittsend.com) wrote: I've got some more problems relating to shutting down containers, some of which may be related to mounting tmpfs on /run to which /var/run is symlinked to. We're doing halt / restart detection by monitoring utmp in that directory but it looks like utmp isn't even in that directory anymore and mounting tmpfs on it was always problematical. We may have to have a more generic method to detect when a container has shut down or is restarting in that case. I can't parse this. The system call reboot() is virtualized for containers just fine and the container managaer (i.e. LXC) can check for that easily. I strongly suspect that the condition I'm dealing with (not being able to restart the container) is an artifact of the devtmpfs kludge. I'm seeing some errors relating to /dev/loop* busy that seems to be related to the hung resources resulting in the inability to remove the zombie container. Disregard until I can get further information following a switch to a template based setup. Lennart Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] Unable to run systemd in an LXC / cgroup container.
On Fri, 2012-10-26 at 11:58 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: On Thu, 25.10.12 11:59, Michael H. Warfield (m...@wittsend.com) wrote: http://wiki.1tux.org/wiki/Lxc/Installation#Additional_notes Unfortunately, in our case, merely getting a mount in there is a complication in that it also has to be populated but, at least, we understand the problem set now. Ok... Serge and I were corresponding on the lxc-users list and he had a suggestion that worked but I consider to be a bit of a sub-optimal workaround. Ironically, it was to mount devtmpfs on /dev. We don't (currently) have a method to auto-populate a tmpfs mount with the needed devices and this provided it. It does have a problem that makes me uncomfortable in that the container now has visibility into the hosts /dev system. I'm a security expert and I'm not comfortable with that solution even with the controls we have. We can control access but still, not happy with that. That's a pretty bad idea, access control to the device nodes in devtmpfs is controlled by the host's udev instance. That means if your group/user lists in the container and the host differ you already lost. Also access control in udev is dynamic, due to stuff like uaccess and similar. You really don't want to to have that into the container, i.e. where device change ownership all the time with UIDs/GIDs that make no sense at all in the container. Concur. In general I think it's a good idea not to expose any real devices to the container, but only the virtual ones that are programming APIs. That means: no /dev/sda, or /dev/ttyS0, but /dev/null, /dev/zero, /dev/random, /dev/urandom. And creating the latter in a tmpfs is quite simple. If I run lxc-console (which attaches to one of the vtys) it gives me nothing. Under sysvinit and upstart I get vty login prompts because they have started getty on those vtys. This is important in case network access has not started for one reason or another and the container was started detached in the background. The getty behaviour of systemd in containers is documented here: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface Sorry. This is unacceptable. We need some way that these will be active and you will be consistent with other containers. If LXC mounts ptys on top of the VT devices that's a really bad idea too, since /dev/tty1 and friends expose a number of APIs beyond the mere tty device that you cannot emulate with that. It includes files in /sys, as well as /dev/vcs and /dev/vcsa, various ioctls, and so on. Heck, even the most superficial of things, the $TERM variable will be incorrect. LXC shouldn't do that. REGARDLESS. I'm in this situation now testing what I thought was a hang condition (which is proving to be something else). I started a container detached redirecting the console to a file (a parameter I was missing) and the log to another file (which I had been doing). But, for some reason, sshd is not starting up. I have no way to attach to the bloody console of the container and I have no getty's on a vty I can attach to using lxc-console and I can't remote access a container which, for all other intents and purposes, appears to be running fine. Parameterize this bloody thing so we can have control over it. Here's another weirdism that's in your camp... The reason that sshd did not start was because the network did not start (IPv6 was up but IPv4 was not and the startup of several services failed as a consequence). Trying to restart the network manually resulted in this: [root@alcove mhw]# ifdown eth0 ./network-functions: line 237: cd: /var/run/netreport: No such file or directory [root@alcove mhw]# ifup eth0 ./network-functions: line 237: cd: /var/run/netreport: No such file or directory [root@alcove mhw]# ls /var/run/ dbus messagebus.pid rpcbind.sock systemd user log mount syslogd.pid udev What the hell is this? /var/run is symlinked to /run and is mounted with a tmpfs. So I created that directory and could ifup the the network and start sshd. So I did a little check on the run levels... Hmmm... F17 container (Alcove) in an F17 host (Forest). WHAT is going ON here? Is this why the network didn't start? [root@forest mhw]# runlevel N 5 [root@alcove mhw]# runlevel unknown [root@alcove mhw]# chkconfig Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. modules_dep 0:off 1:off 2:on3:on4:on5:on6:off netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:off 3:on4:off 5:off 6:off Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/
Re: [systemd-devel] Unable to run systemd in an LXC / cgroup container.
On Fri, 2012-10-26 at 12:11 -0400, Michael H. Warfield wrote: On Thu, 2012-10-25 at 23:38 +0200, Lennart Poettering wrote: On Thu, 25.10.12 11:59, Michael H. Warfield (m...@wittsend.com) wrote: I SUSPECT the hang condition is something to do with systemd trying to start and interactive console on /dev/console, which sysvinit and upstart do not do. Yes, this is documented, please see the link I already posted, and which I linked above a second time. This may have been my fault. I was using the -o option to lxc-start (output logfile) and failed to specify the -c (console output redirect) option. It seems to fire up nicely (albeit with other problems) with that additional option. Continuing my research. Confirming. Using the -c option for the console file works. Unfortunately, thanks to no getty's on the ttys so lxc-console does not work and no way to connect to that console redirect and the failure of the network to start, I'm still trying to figure out just what is face planting in a container I can not access. :-/=/ Punch out the punch list one PUNCH at at time here. I've got some more problems relating to shutting down containers, some of which may be related to mounting tmpfs on /run to which /var/run is symlinked to. We're doing halt / restart detection by monitoring utmp in that directory but it looks like utmp isn't even in that directory anymore and mounting tmpfs on it was always problematical. We may have to have a more generic method to detect when a container has shut down or is restarting in that case. I can't parse this. The system call reboot() is virtualized for containers just fine and the container managaer (i.e. LXC) can check for that easily. Apparently, in recent kernels, we can. Unfortunately, I'm still finding that I can not restart a container I have previously halted. I have no problem with sysvinit and upstart systems on this host, so it is a container problem peculiar to systemd containers. Continuing to research that problem. Lennart -- Lennart Poettering - Red Hat, Inc. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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
[systemd-devel] One of my fundamental problems with systemd...
My most fundamental problem with systemd is its insistence in hiding and obfuscating errors in ways that makes debugging almost impossible. Almost every upgrade problem I've had in Fedora has been related to systemd's failure to provide comprehendable error messages to things like errors in fstab (#1 fsck up). The most recent problem has been an issue trying to get LXC containers to work. The networking is not coming up in the container at boot. It's not starting. What do I get? I finally dug it out of the console barf. A message that says this: [FAILED] Failed to start LSB: Bring up/down networking. See 'systemctl status network.service' for details. Ok fine... So I get logged in and I run this... [root@alcove mhw]# systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed (Result: exit-code) since Wed, 24 Oct 2012 18:23:07 +0400; 1min 57s ago Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=209/STDOUT) CGroup: name=systemd:/system/lxc/Alcove/system/network.service Tells me nothing. Does not tell me where the problem is... If I then try to manually start the network I get this... [root@alcove mhw]# service network start Starting network (via systemctl): network[275]: Bringing up loopback interface: ./network-functions: line 237: cd: /var/run/netreport: No such file or directory network[275]: [ OK ] network[275]: Bringing up interface eth0: ./network-functions: line 237: cd: /var/run/netreport: No such file or directory network[275]: [ OK ] network[275]: touch: cannot touch `/var/lock/subsys/network': No such file or directory [ OK ] OK... This I can understand. There are missing directories in /var/run and in /var/lock. Don't tell me how that script should have done this or that or the other. That's NOT the problem. The problem is that systemd did not communicate back WHAT THE REAL PROBLEM WAS. Why is it so difficult for systemd to respond with intelligent error message??? The message said to run systemctl status network.service but that result was worthless. I'll now edit that startup script to fix this nonsense but it's pointing to a fundamental failure in systemd in communicating errors back to administrators in an actionable manner. Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] One of my fundamental problems with systemd...
On Fri, Oct 26, 2012 at 3:39 PM, Michael H. Warfield m...@wittsend.com wrote:
My most fundamental problem with systemd is its insistence in hiding and
obfuscating errors in ways that makes debugging almost impossible.
Almost every upgrade problem I've had in Fedora has been related to
systemd's failure to provide comprehendable error messages to things
like errors in fstab (#1 fsck up).
The most recent problem has been an issue trying to get LXC containers
to work. The networking is not coming up in the container at boot.
It's not starting. What do I get? I finally dug it out of the console
barf. A message that says this:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ok fine... So I get logged in and I run this...
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: failed (Result: exit-code) since Wed, 24 Oct 2012 18:23:07
+0400; 1min 57s ago
Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited,
status=209/STDOUT)
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
Tells me nothing. Does not tell me where the problem is...
On the contrary, it does quite clearly indicate where the problem is.
The information may be represented differently than you expect, but it
is clear on the status of the service - including the return value of
the execution.
If I then try to manually start the network I get this...
[root@alcove mhw]# service network start
Starting network (via systemctl): network[275]: Bringing up loopback
interface: ./network-functions: line 237: cd: /var/run/netreport: No such
file or directory
network[275]: [ OK ]
network[275]: Bringing up interface eth0: ./network-functions: line 237: cd:
/var/run/netreport: No such file or directory
network[275]: [ OK ]
network[275]: touch: cannot touch `/var/lock/subsys/network': No such file or
directory
[ OK ]
OK... This I can understand. There are missing directories in /var/run
and in /var/lock. Don't tell me how that script should have done this
or that or the other. That's NOT the problem. The problem is that
systemd did not communicate back WHAT THE REAL PROBLEM WAS. Why is it
so difficult for systemd to respond with intelligent error message???
The message said to run systemctl status network.service but that
result was worthless.
I'll now edit that startup script to fix this nonsense but it's pointing
to a fundamental failure in systemd in communicating errors back to
administrators in an actionable manner.
Try and be reasonable here. Here's what I read in your message:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ahh, so let's read that output:
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
ok, just describes the service
Loaded: loaded (/etc/rc.d/init.d/network)
ok, it's loaded. it's a sysV init script. Maybe the script is old and
wasn't written for systemd?
Active: failed (Result: exit-code) since Wed, 24 Oct 2012 18:23:07
+0400; 1min 57s ago
hmm, EXIT CODE failure. It exited with a non-zero status.
Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited,
status=209/STDOUT)
ok so, the script returned a strange error code.
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
shrug, doesn't seem to matter.
...
Now, from just this I can conclude that your `/etc/rc.d/init.d/network
start` produced an error.
How is that useless information? It is exactly what the status of the
network service is - failed, with an error code.
Now, from what I remember newer versions of systemd produce a short
'tail' of the services' error log in case it fails, looking like this:
# systemctl status connman.service
connman.service - Connection service
Loaded: loaded (/etc/systemd/system/connman.service; disabled)
Active: inactive (dead)
CGroup: name=systemd:/system/connman.service
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
wlan0 [ wifi ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
eth1 [ ethernet ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: eth0 {remove} index 2
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: wlan0 {remove} index 3
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: eth1 {remove} index 4
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Exit
Oct 19 10:44:01 htpc connmand[3168]: eth0 {remove} index 2
Oct 19 10:44:01 htpc connmand[3168]: wlan0 {remove} index 3
Oct 19 10:44:01 htpc connmand[3168]: eth1 {remove} index 4
Oct 19 10:44:01 htpc connmand[3168]: Exit
This should help.
Re: [systemd-devel] One of my fundamental problems with systemd...
Am 27.10.2012 01:51, schrieb Kok: Active: failed (Result: exit-code) since Wed, 24 Oct 2012 18:23:07 +0400; 1min 57s ago hmm, EXIT CODE failure. It exited with a non-zero status. Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=209/STDOUT) ok so, the script returned a strange error code. CGroup: name=systemd:/system/lxc/Alcove/system/network.service shrug, doesn't seem to matter. ... Now, from just this I can conclude that your `/etc/rc.d/init.d/network start` produced an error. How is that useless information? It is exactly what the status of the network service is - failed, with an error code because compared with old sysvinit there is no helpful information exited with non-zero code does not help you much to debug sysv services were bash-scripts and gave you the output what excatly goes wrong while systemd does not, it becomes better in the last releases but at the begin systemd was simply a blackbox 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] One of my fundamental problems with systemd...
On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote:
On Fri, Oct 26, 2012 at 3:39 PM, Michael H. Warfield m...@wittsend.com
wrote:
My most fundamental problem with systemd is its insistence in hiding and
obfuscating errors in ways that makes debugging almost impossible.
Almost every upgrade problem I've had in Fedora has been related to
systemd's failure to provide comprehendable error messages to things
like errors in fstab (#1 fsck up).
The most recent problem has been an issue trying to get LXC containers
to work. The networking is not coming up in the container at boot.
It's not starting. What do I get? I finally dug it out of the console
barf. A message that says this:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ok fine... So I get logged in and I run this...
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: failed (Result: exit-code) since Wed, 24 Oct 2012
18:23:07 +0400; 1min 57s ago
Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited,
status=209/STDOUT)
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
Tells me nothing. Does not tell me where the problem is...
On the contrary, it does quite clearly indicate where the problem is.
The information may be represented differently than you expect, but it
is clear on the status of the service - including the return value of
the execution.
If I then try to manually start the network I get this...
[root@alcove mhw]# service network start
Starting network (via systemctl): network[275]: Bringing up loopback
interface: ./network-functions: line 237: cd: /var/run/netreport: No such
file or directory
network[275]: [ OK ]
network[275]: Bringing up interface eth0: ./network-functions: line 237:
cd: /var/run/netreport: No such file or directory
network[275]: [ OK ]
network[275]: touch: cannot touch `/var/lock/subsys/network': No such file
or directory
[ OK ]
OK... This I can understand. There are missing directories in /var/run
and in /var/lock. Don't tell me how that script should have done this
or that or the other. That's NOT the problem. The problem is that
systemd did not communicate back WHAT THE REAL PROBLEM WAS. Why is it
so difficult for systemd to respond with intelligent error message???
The message said to run systemctl status network.service but that
result was worthless.
I'll now edit that startup script to fix this nonsense but it's pointing
to a fundamental failure in systemd in communicating errors back to
administrators in an actionable manner.
Try and be reasonable here. Here's what I read in your message:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ahh, so let's read that output:
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
ok, just describes the service
Loaded: loaded (/etc/rc.d/init.d/network)
ok, it's loaded. it's a sysV init script. Maybe the script is old and
wasn't written for systemd?
Active: failed (Result: exit-code) since Wed, 24 Oct 2012
18:23:07 +0400; 1min 57s ago
hmm, EXIT CODE failure. It exited with a non-zero status.
Process: 91 ExecStart=/etc/rc.d/init.d/network start (code=exited,
status=209/STDOUT)
ok so, the script returned a strange error code.
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
shrug, doesn't seem to matter.
...
Now, from just this I can conclude that your `/etc/rc.d/init.d/network
start` produced an error.
How is that useless information? It is exactly what the status of the
network service is - failed, with an error code.
Now, from what I remember newer versions of systemd produce a short
'tail' of the services' error log in case it fails, looking like this:
# systemctl status connman.service
connman.service - Connection service
Loaded: loaded (/etc/systemd/system/connman.service; disabled)
Active: inactive (dead)
CGroup: name=systemd:/system/connman.service
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
wlan0 [ wifi ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
eth1 [ ethernet ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: eth0 {remove} index 2
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: wlan0 {remove} index 3
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: eth1 {remove} index 4
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Exit
Oct 19 10:44:01 htpc connmand[3168]: eth0 {remove} index 2
Oct 19 10:44:01
Re: [systemd-devel] One of my fundamental problems with systemd...
On Fri, 2012-10-26 at 20:06 -0400, Michael H. Warfield wrote:
On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote:
On Fri, Oct 26, 2012 at 3:39 PM, Michael H. Warfield m...@wittsend.com
wrote:
My most fundamental problem with systemd is its insistence in hiding and
obfuscating errors in ways that makes debugging almost impossible.
Almost every upgrade problem I've had in Fedora has been related to
systemd's failure to provide comprehendable error messages to things
like errors in fstab (#1 fsck up).
The most recent problem has been an issue trying to get LXC containers
to work. The networking is not coming up in the container at boot.
It's not starting. What do I get? I finally dug it out of the console
barf. A message that says this:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ok fine... So I get logged in and I run this...
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: failed (Result: exit-code) since Wed, 24 Oct 2012
18:23:07 +0400; 1min 57s ago
Process: 91 ExecStart=/etc/rc.d/init.d/network start
(code=exited, status=209/STDOUT)
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
Tells me nothing. Does not tell me where the problem is...
On the contrary, it does quite clearly indicate where the problem is.
The information may be represented differently than you expect, but it
is clear on the status of the service - including the return value of
the execution.
If I then try to manually start the network I get this...
[root@alcove mhw]# service network start
Starting network (via systemctl): network[275]: Bringing up loopback
interface: ./network-functions: line 237: cd: /var/run/netreport: No
such file or directory
network[275]: [ OK ]
network[275]: Bringing up interface eth0: ./network-functions: line 237:
cd: /var/run/netreport: No such file or directory
network[275]: [ OK ]
network[275]: touch: cannot touch `/var/lock/subsys/network': No such
file or directory
[ OK ]
OK... This I can understand. There are missing directories in /var/run
and in /var/lock. Don't tell me how that script should have done this
or that or the other. That's NOT the problem. The problem is that
systemd did not communicate back WHAT THE REAL PROBLEM WAS. Why is it
so difficult for systemd to respond with intelligent error message???
The message said to run systemctl status network.service but that
result was worthless.
I'll now edit that startup script to fix this nonsense but it's pointing
to a fundamental failure in systemd in communicating errors back to
administrators in an actionable manner.
Try and be reasonable here. Here's what I read in your message:
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.
Ahh, so let's read that output:
[root@alcove mhw]# systemctl status network.service
network.service - LSB: Bring up/down networking
ok, just describes the service
Loaded: loaded (/etc/rc.d/init.d/network)
ok, it's loaded. it's a sysV init script. Maybe the script is old and
wasn't written for systemd?
Active: failed (Result: exit-code) since Wed, 24 Oct 2012
18:23:07 +0400; 1min 57s ago
hmm, EXIT CODE failure. It exited with a non-zero status.
Process: 91 ExecStart=/etc/rc.d/init.d/network start
(code=exited, status=209/STDOUT)
ok so, the script returned a strange error code.
CGroup: name=systemd:/system/lxc/Alcove/system/network.service
shrug, doesn't seem to matter.
...
Now, from just this I can conclude that your `/etc/rc.d/init.d/network
start` produced an error.
How is that useless information? It is exactly what the status of the
network service is - failed, with an error code.
Now, from what I remember newer versions of systemd produce a short
'tail' of the services' error log in case it fails, looking like this:
# systemctl status connman.service
connman.service - Connection service
Loaded: loaded (/etc/systemd/system/connman.service; disabled)
Active: inactive (dead)
CGroup: name=systemd:/system/connman.service
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
wlan0 [ wifi ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: Remove interface
eth1 [ ethernet ]
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: eth0 {remove} index 2
Oct 19 10:44:01 htpc connmand[3168]: connmand[3168]: wlan0 {remove} index 3
Oct 19 10:44:01 htpc connmand[3168]:
Re: [systemd-devel] One of my fundamental problems with systemd...
On Fri, Oct 26, 2012 at 5:48 PM, Michael H. Warfield m...@wittsend.com wrote: It's still failing and it's giving me conflicting errors about directory already exists and then file does not exist (on the directory). This POS is driving me nuts with lack of intelligent debugging information! Throwing tantrums isn't going to help. Neither is repeating the same complaints again and again. Perhaps you can help the project constructively by showing us how we can improve or add the missing debugging information? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
On Fri, Oct 26, 2012 at 6:06 PM, Michael H. Warfield m...@wittsend.com wrote: On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote: This should help. Obviously, journalctl should help you a lot as well. And journalctl gave me jack shit trying to figure this out and I really DON'T need yet another obscure command to dig out errors that should have been presented in the first place. fine, be that way. Please stop using systemd. You're obviously not interested in actually talking on a normal level to developers that can, and may actually want to help you. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
On Fri, 2012-10-26 at 18:32 -0700, Kok, Auke-jan H wrote: On Fri, Oct 26, 2012 at 6:06 PM, Michael H. Warfield m...@wittsend.com wrote: On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote: This should help. Obviously, journalctl should help you a lot as well. And journalctl gave me jack shit trying to figure this out and I really DON'T need yet another obscure command to dig out errors that should have been presented in the first place. fine, be that way. Please stop using systemd. You're obviously not interested in actually talking on a normal level to developers that can, and may actually want to help you. Excuse me? I'm a kernel maintainer and a member of the Samba team. I have dedicated almost 2 decades to promoting and developing several dozen open source projects I will not enumerate here. I'm willing to help but I'm extremely frustrated at this point. When things don't work and I can't drill down to the reason and people give me platitudes I get frustrated. Would you like access to this container? If you are on IPv6, I'll give you immediate root shell access. Send me and RSA key and I will send you the FQDN and give you sudo access! Then you can tell me! IPv4 would take a little longer. I've done this VMware and others. I believe in solving problems not making excuses for why it didn't work. Auke Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] One of my fundamental problems with systemd...
On Fri, 2012-10-26 at 21:50 -0400, Michael H. Warfield wrote: On Fri, 2012-10-26 at 18:32 -0700, Kok, Auke-jan H wrote: On Fri, Oct 26, 2012 at 6:06 PM, Michael H. Warfield m...@wittsend.com wrote: On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote: This should help. Obviously, journalctl should help you a lot as well. And journalctl gave me jack shit trying to figure this out and I really DON'T need yet another obscure command to dig out errors that should have been presented in the first place. fine, be that way. Please stop using systemd. You're obviously not interested in actually talking on a normal level to developers that can, and may actually want to help you. Obviously, if I am to maintain an environment based on these distributions, that is impossible. Fedora has made it abjectly impossible to dispose of systemd an to even drop back to upstart at this point. That is not an option. Excuse me? I'm a kernel maintainer and a member of the Samba team. I have dedicated almost 2 decades to promoting and developing several dozen open source projects I will not enumerate here. I'm willing to help but I'm extremely frustrated at this point. When things don't work and I can't drill down to the reason and people give me platitudes I get frustrated. Would you like access to this container? If you are on IPv6, I'll give you immediate root shell access. Send me and RSA key and I will send you the FQDN and give you sudo access! Then you can tell me! IPv4 would take a little longer. I've done this VMware and others. I believe in solving problems not making excuses for why it didn't work. Hmmm... I'll tell you what. I'll even set up your very own LXC container running systemd at my colo facility (I have a rack at an ISP) so you have lots of bandwidth to play with. I'll get it up and running and you can access it and tell me what causes the errors that force me to go through those manual steps. I'll provide you with a complete development and test bed to make this work. I'll work with you. All in my infrastructure and my resources. All I want is for this to work so I can move beyond Fedora 15. How does that sound? I'm at your disposal. Auke Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] One of my fundamental problems with systemd...
On Fri, 2012-10-26 at 22:05 -0400, Michael H. Warfield wrote: On Fri, 2012-10-26 at 21:50 -0400, Michael H. Warfield wrote: On Fri, 2012-10-26 at 18:32 -0700, Kok, Auke-jan H wrote: On Fri, Oct 26, 2012 at 6:06 PM, Michael H. Warfield m...@wittsend.com wrote: On Fri, 2012-10-26 at 16:51 -0700, Kok, Auke-jan H wrote: This should help. Obviously, journalctl should help you a lot as well. And journalctl gave me jack shit trying to figure this out and I really DON'T need yet another obscure command to dig out errors that should have been presented in the first place. fine, be that way. Please stop using systemd. You're obviously not interested in actually talking on a normal level to developers that can, and may actually want to help you. Obviously, if I am to maintain an environment based on these distributions, that is impossible. Fedora has made it abjectly impossible to dispose of systemd an to even drop back to upstart at this point. That is not an option. Excuse me? I'm a kernel maintainer and a member of the Samba team. I have dedicated almost 2 decades to promoting and developing several dozen open source projects I will not enumerate here. BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... Just for references, if there is any question as to who I am, please check with Jeff Boerio jeff.boe...@intel.com or Bruce Monroe bruce.mon...@intel.com on your CERT teams in case there's some question about just who I am. I think they can provide sufficient references for me. I'm willing to help but I'm extremely frustrated at this point. When things don't work and I can't drill down to the reason and people give me platitudes I get frustrated. Would you like access to this container? If you are on IPv6, I'll give you immediate root shell access. Send me and RSA key and I will send you the FQDN and give you sudo access! Then you can tell me! IPv4 would take a little longer. I've done this VMware and others. I believe in solving problems not making excuses for why it didn't work. Hmmm... I'll tell you what. I'll even set up your very own LXC container running systemd at my colo facility (I have a rack at an ISP) so you have lots of bandwidth to play with. I'll get it up and running and you can access it and tell me what causes the errors that force me to go through those manual steps. I'll provide you with a complete development and test bed to make this work. I'll work with you. All in my infrastructure and my resources. All I want is for this to work so I can move beyond Fedora 15. How does that sound? I'm at your disposal. Auke Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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] One of my fundamental problems with systemd...
On Fri, Oct 26, 2012 at 10:16:47PM -0400, Michael H. Warfield wrote: BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... I prefer judging myself. And at the moment I see you using words like: - crap - POS -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd: mount the EFI variable filesystem
Add efivarfs to the mount_table in mount-setup.c, so the EFI variable
filesystem will be mounted when systemd executed.
The EFI variable filesystem will merge in v3.7 or v3.8 linux kernel.
Cc: Kay Sievers k...@vrfy.org
Cc: Lennart Poettering lenn...@poettering.net
Cc: Mantas MikulÄnas graw...@gmail.com
Cc: Zbigniew JÄdrzejewski-Szmek zbys...@in.waw.pl
Cc: Matt Fleming matt.flem...@intel.com
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Matthew Garrett m...@redhat.com
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
src/core/kmod-setup.c |1 +
src/core/mount-setup.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/core/kmod-setup.c b/src/core/kmod-setup.c
index cc2a2d9..14a4778 100644
--- a/src/core/kmod-setup.c
+++ b/src/core/kmod-setup.c
@@ -33,6 +33,7 @@
static const char * const kmod_table[] = {
autofs4, /sys/class/misc/autofs,
ipv6,/sys/module/ipv6,
+ efivarfs, /sys/firmware/efi/efivars,
unix,/proc/net/unix
};
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 0fd112f..8ce4ddc 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -66,6 +66,7 @@ static const MountPoint mount_table[] = {
{ sysfs,/sys, sysfs,NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,true, true },
{ devtmpfs, /dev, devtmpfs, mode=755,
MS_NOSUID|MS_STRICTATIME,true, true },
{ securityfs, /sys/kernel/security, securityfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,false, false },
+ { efivarfs, /sys/firmware/efi/efivars, efivarfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,false, false },
{ tmpfs,/dev/shm, tmpfs,mode=1777,
MS_NOSUID|MS_NODEV|MS_STRICTATIME, true, true },
{ devpts, /dev/pts, devpts, mode=620,gid=
STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false, true },
{ tmpfs,/run, tmpfs,mode=755,
MS_NOSUID|MS_NODEV|MS_STRICTATIME, true, true },
--
1.6.0.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
sent too quickly.. On Sat, Oct 27, 2012 at 05:22:30AM +0200, Olav Vitters wrote: On Fri, Oct 26, 2012 at 10:16:47PM -0400, Michael H. Warfield wrote: BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... I prefer judging myself. And at the moment I see you using words like: - crap - POS - barf - fsck (though meaning fuck) It is not needed to tell what you did. Just be nice and people will show the same courtesy. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
On Sat, 2012-10-27 at 05:24 +0200, Olav Vitters wrote: sent too quickly.. On Sat, Oct 27, 2012 at 05:22:30AM +0200, Olav Vitters wrote: On Fri, Oct 26, 2012 at 10:16:47PM -0400, Michael H. Warfield wrote: BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... I prefer judging myself. And at the moment I see you using words like: - crap - POS - barf - fsck (though meaning fuck) It is not needed to tell what you did. Just be nice and people will show the same courtesy. Offense not intended. It's the terms we use in several other forums with no offense take. In fact, in the Openswan forum barf has a specific command and meaning. If you have a problem with Openswan you are quite often asked for the barf (dump). Maybe I'm too old and too abrasive and too use to the old culture where this was common. -- Regards, Olav Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! 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
