Re: [systemd-devel] pam_systemd closing user's session prematurely
On Tue, Oct 16, 2012 at 04:27:24PM -0400, Ray Strode wrote: > Hi, > > On Tue, Oct 16, 2012 at 2:20 PM, Lennart Poettering > wrote: > > I have now commited a fix that achieves the same as yours but doesn't > > key this of the static service database: I simply extended the > > OpenSession() bus call to inform clients whether they are a new session > > or just got the previous data returned. With that boolean we can then > > later do or skip the unrelease and should be safe. Adding this > > OpenSession() seemed like the cleanest way to pass this information to > > pam_systemd, and should be without risk, since we never included > > OpenSession() in any docs, as we consider it a private API. > Cool. Though, won't this break logins after logind is upgraded until > reboot? Or does logind get restarted on package install? Aparently a reboot is not needed, but 'systemctl restart systemd-login.service' is. Oct 16 21:43:14 fedora-15 sshd[12846]: pam_systemd(sshd:session): Failed to parse message: Message has only 5 arguments, but more were expected Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] mount: make sure m->where is set before unit_add_exec_dependencies()
If you enter unit_add_exec_dependencies with m->where = NULL, you'll
very likely end up aborting somewhere under socket_needs_mount.
(When systemd goes to check to see if the journald socket requires your
mount, it'll do path_startswith(path, m->where)... *kaboom*)
This patch should ensure that:
a) both branches in mount_add_one() set m->where, and
b) mount_add_extras() calls unit_add_exec_dependencies() *after*
setting m->where.
---
src/core/mount.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index e1c240e..14f4863 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -547,10 +547,6 @@ static int mount_add_extras(Mount *m) {
Unit *u = UNIT(m);
int r;
-r = unit_add_exec_dependencies(u, &m->exec_context);
-if (r < 0)
-return r;
-
if (UNIT(m)->fragment_path)
m->from_fragment = true;
@@ -562,6 +558,10 @@ static int mount_add_extras(Mount *m) {
path_kill_slashes(m->where);
+r = unit_add_exec_dependencies(u, &m->exec_context);
+if (r < 0)
+return r;
+
if (!UNIT(m)->description) {
r = unit_set_description(u, m->where);
if (r < 0)
@@ -1459,6 +1459,14 @@ static int mount_add_one(
delete = false;
free(e);
+if (!MOUNT(u)->where) {
+MOUNT(u)->where = strdup(where);
+if (!MOUNT(u)->where) {
+r = -ENOMEM;
+goto fail;
+}
+}
+
if (u->load_state == UNIT_ERROR) {
u->load_state = UNIT_LOADED;
u->load_error = 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] pam_systemd closing user's session prematurely
Hi, >> Please test! > Will do. I did: $ loginctl show-session $XDG_SESSION_ID $ su - # exit $ loginctl show-session $XDG_SESSION_ID and in both cases State=active So patch seems to work. Thanks Ray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_systemd closing user's session prematurely
Hi, On Tue, Oct 16, 2012 at 2:20 PM, Lennart Poettering wrote: > I have now commited a fix that achieves the same as yours but doesn't > key this of the static service database: I simply extended the > OpenSession() bus call to inform clients whether they are a new session > or just got the previous data returned. With that boolean we can then > later do or skip the unrelease and should be safe. Adding this > OpenSession() seemed like the cleanest way to pass this information to > pam_systemd, and should be without risk, since we never included > OpenSession() in any docs, as we consider it a private API. Cool. Though, won't this break logins after logind is upgraded until reboot? Or does logind get restarted on package install? > Thanks for tracking this down and for your patch! Well, Owen Taylor tracked it down actually. > Please test! Will do. --Ray ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_systemd closing user's session prematurely
On Fri, 12.10.12 15:45, Ray Strode (halfl...@gmail.com) wrote: > Hi, Heya, > Some GDM/gnome-shell users having a rather strange issue where they > can't unlock their screen because logind thinks their session is no > longer active: > > https://bugzilla.gnome.org/show_bug.cgi?id=685988 > I've attached a patch that bypasses ReleaseSession if CreateSession > returns the session the user is already in, but I fear it's wrong if > ReleaseSession was specifically designed for su, since we're > essentially bypassing it for the su case with my patch. I have now commited a fix that achieves the same as yours but doesn't key this of the static service database: I simply extended the OpenSession() bus call to inform clients whether they are a new session or just got the previous data returned. With that boolean we can then later do or skip the unrelease and should be safe. Adding this OpenSession() seemed like the cleanest way to pass this information to pam_systemd, and should be without risk, since we never included OpenSession() in any docs, as we consider it a private API. Thanks for tracking this down and for your patch! Please test! 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] systemd hibernation process
On Tue, 16.10.12 18:13, Federico Di Pierro (nierr...@gmail.com) wrote: > Hi! > I was trying to understand how does systemd hibernation process work. > What i mean is: with pm-utils i had to put "tuxonice" in a > /etc/pm/config.d/ file, within the SLEEP_MODULE array, to make pm work with > it. > Systemd instead seems to do this without any input from the user...that's > great, but how? It obviously doesn't read the SLEEP_MODULE array (i have no > more pm-utils installed). So, where's the magic thing? And, how to change > hibernate backend? systemd talks directly to the kernel, by echoing into sysfs. We do not support any but the in-kernel suspend framework, as we generally do not support kernel subsystems that are maintained out-of-kernel. 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] Hang when mounting NFS via systemd
On 10/16/2012 02:39 AM, Lennart Poettering wrote: > On Mon, 08.10.12 19:57, Bardur Arantsson (s...@scientician.net) wrote: > >> >> On 09/24/2012 12:56 PM, Lennart Poettering wrote: >>> On Sun, 23.09.12 17:21, Bardur Arantsson (s...@scientician.net) wrote: >>> Hi all, >> [--snip--] >>> >>> This indicates a bug i systemd actually. For some reason systemd appears >>> to believe that your NFS share is a device to wait for. >>> >>> I tried to fix this in git with two commits. Please test! >>> >>> Lennart >>> >> >> It seems to work perfectly now (v194) when I do the mounting post-boot >> in a shell, using >> >># systemctl start data.mount >> >> However, it still hangs during boot, waits for the defined timeout >> period and then... proceeds to work perfectly. >> >> I'm not sure, but could it have something to do with my use of two >> automounts where one is nested inside the other? I have > > It might be sufficient to do "systemctl enable > NetworkManager-wait-online.service". Only then the NFS mounts will be > delayed until NM considers the system to be online. > That worked great, thanks! (There's still a slightly delay, but that seems to be my DHCP server being slow to respond.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd hibernation process
Hi! I was trying to understand how does systemd hibernation process work. What i mean is: with pm-utils i had to put "tuxonice" in a /etc/pm/config.d/ file, within the SLEEP_MODULE array, to make pm work with it. Systemd instead seems to do this without any input from the user...that's great, but how? It obviously doesn't read the SLEEP_MODULE array (i have no more pm-utils installed). So, where's the magic thing? And, how to change hibernate backend? Thank you very much! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl segfault in gcrypt code
On Tue, Oct 16, 2012 at 04:13:15PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Oct 16, 2012 at 01:01:04AM +0200, Lennart Poettering wrote: > > On Mon, 15.10.12 23:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > > > > On Mon, Oct 15, 2012 at 10:01:31PM +0200, Lennart Poettering wrote: > > > > On Sat, 13.10.12 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm having trouble debugging the problem below. Maybe somebody has an > > > > > idea... When I run journalctl, on a specific (large) set of journal > > > > > logs, it segfaults. Always in the same place. > > > > > > > > Hmm, I have not see this so far. Have you tried valgrind on this? > > > Yeah, but it didn't say anything useful. > > > > > > ==32666== Invalid write of size 1 > > > ==32666==at 0x5076B12: md_close (md.c:771) > > > ==32666==by 0x41282D: journal_file_close (journal-file.c:109) > > > ==32666==by 0x4110FE: sd_journal_close (sd-journal.c:1620) > > > ==32666==by 0x406DEA: main (journalctl.c:990) > > > ==32666== Address 0x402d000 is not stack'd, malloc'd or (recently) free'd > > > ==32666== > > > ==32666== > > > ==32666== Process terminating with default action of signal 11 (SIGSEGV) > > > ==32666== Access not within mapped region at address 0x402D000 > > > ==32666==at 0x5076B12: md_close (md.c:771) > > > ==32666==by 0x41282D: journal_file_close (journal-file.c:109) > > > ==32666==by 0x4110FE: sd_journal_close (sd-journal.c:1620) > > > ==32666==by 0x406DEA: main (journalctl.c:990) > > > ==32666== If you believe this happened as a result of a stack > > > ==32666== overflow in your program's main thread (unlikely but > > > ==32666== possible), you can try to increase the size of the > > > ==32666== main thread stack using the --main-stacksize= flag. > > > ==32666== The main thread stack size used in this run was 8388608. > > > --32666-- Caught __NR_exit; running __libc_freeres() > > > --32666-- Discarding syms at 0x33981230-0x3398887c in > > > /usr/lib64/libnss_files-2.16.90.so due to munmap() > > > ==32666== > > > ==32666== HEAP SUMMARY: > > > ==32666== in use at exit: 17,860,820 bytes in 57 blocks > > > ==32666== total heap usage: 73,740 allocs, 73,683 frees, 33,511,230,790 > > > bytes allocated > > > > > > When I compile with --disable-gcrypt, everything seems to work fine > > > (no valgrind warnings). So the problem seems related to gcrypt, > > > but I can't see anything wrong by looking at the code. > > > > I wonder if valgrind actually tracks mmap()s properly. I wonder if the > > mmap_cache is mistakingly unmapping a map it shoudln't. It might be > > worth loking for munmap() invocations in mmap-cache.c and printing the > > range unmapped and comparing that with the address valgrind mentions as > > freed. > Seems that mmaps/unmmaps are not the problem: > > mmap 0x7f7c38c03000 2f5000 > mmap 0x7f7c3890e000 2f5000 > mmap 0x7f7c38618000 2f5000 > ... > mmap 0x7f7c0c53f000 2f5000 > mmap 0x7f7c0bd3e000 80 > mmap 0x7f7c0b53d000 80 > mmap 0x7f7c0b247000 2f5000 > mmap 0x7f7c0af51000 2f5000 > munmap 0x7f7c38c03000 2f5000 > ... > munmap 0x7f7c0c53f000 2f5000 > Segmentation fault (core dumped) > > and > a->ctx->macpads > $2 = (byte *) 0x7f7c3a3b2f88 "" > > So, no overlap, everything mmaped and unmmaped in order. BTW, this is on top of Colin's patches: (journal: Set the last_unused pointer... and journal: Properly track the number of allocated windows). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: Properly track the number of allocated windows.
On Tue, 16.10.12 12:03, Colin Guthrie (co...@mageia.org) wrote: > Checks were already in place to make sure that the number of > windows was limited to 64, but the count was never incremented > or decremented. Commited both! Thanks a ton for tracking this down! 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] journalctl segfault in gcrypt code
On Tue, Oct 16, 2012 at 01:01:04AM +0200, Lennart Poettering wrote: > On Mon, 15.10.12 23:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > > On Mon, Oct 15, 2012 at 10:01:31PM +0200, Lennart Poettering wrote: > > > On Sat, 13.10.12 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > > wrote: > > > > > > > Hi, > > > > > > > > I'm having trouble debugging the problem below. Maybe somebody has an > > > > idea... When I run journalctl, on a specific (large) set of journal > > > > logs, it segfaults. Always in the same place. > > > > > > Hmm, I have not see this so far. Have you tried valgrind on this? > > Yeah, but it didn't say anything useful. > > > > ==32666== Invalid write of size 1 > > ==32666==at 0x5076B12: md_close (md.c:771) > > ==32666==by 0x41282D: journal_file_close (journal-file.c:109) > > ==32666==by 0x4110FE: sd_journal_close (sd-journal.c:1620) > > ==32666==by 0x406DEA: main (journalctl.c:990) > > ==32666== Address 0x402d000 is not stack'd, malloc'd or (recently) free'd > > ==32666== > > ==32666== > > ==32666== Process terminating with default action of signal 11 (SIGSEGV) > > ==32666== Access not within mapped region at address 0x402D000 > > ==32666==at 0x5076B12: md_close (md.c:771) > > ==32666==by 0x41282D: journal_file_close (journal-file.c:109) > > ==32666==by 0x4110FE: sd_journal_close (sd-journal.c:1620) > > ==32666==by 0x406DEA: main (journalctl.c:990) > > ==32666== If you believe this happened as a result of a stack > > ==32666== overflow in your program's main thread (unlikely but > > ==32666== possible), you can try to increase the size of the > > ==32666== main thread stack using the --main-stacksize= flag. > > ==32666== The main thread stack size used in this run was 8388608. > > --32666-- Caught __NR_exit; running __libc_freeres() > > --32666-- Discarding syms at 0x33981230-0x3398887c in > > /usr/lib64/libnss_files-2.16.90.so due to munmap() > > ==32666== > > ==32666== HEAP SUMMARY: > > ==32666== in use at exit: 17,860,820 bytes in 57 blocks > > ==32666== total heap usage: 73,740 allocs, 73,683 frees, 33,511,230,790 > > bytes allocated > > > > When I compile with --disable-gcrypt, everything seems to work fine > > (no valgrind warnings). So the problem seems related to gcrypt, > > but I can't see anything wrong by looking at the code. > > I wonder if valgrind actually tracks mmap()s properly. I wonder if the > mmap_cache is mistakingly unmapping a map it shoudln't. It might be > worth loking for munmap() invocations in mmap-cache.c and printing the > range unmapped and comparing that with the address valgrind mentions as > freed. Seems that mmaps/unmmaps are not the problem: mmap 0x7f7c38c03000 2f5000 mmap 0x7f7c3890e000 2f5000 mmap 0x7f7c38618000 2f5000 ... mmap 0x7f7c0c53f000 2f5000 mmap 0x7f7c0bd3e000 80 mmap 0x7f7c0b53d000 80 mmap 0x7f7c0b247000 2f5000 mmap 0x7f7c0af51000 2f5000 munmap 0x7f7c38c03000 2f5000 ... munmap 0x7f7c0c53f000 2f5000 Segmentation fault (core dumped) and a->ctx->macpads $2 = (byte *) 0x7f7c3a3b2f88 "" So, no overlap, everything mmaped and unmmaped in order. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: append .service when unit does not have valid suffix
On Tue, 16.10.12 11:01, Lukas Nykryn (lnyk...@redhat.com) wrote:
> systemctl status a and systemctl status a.service lead to same output but
> systemctl status a.b and systemctl status a.b.service do not.
Thanks! Appplied!
> ---
> src/shared/unit-name.c |6 +-
> 1 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
> index cfe3133..b0539c7 100644
> --- a/src/shared/unit-name.c
> +++ b/src/shared/unit-name.c
> @@ -491,10 +491,6 @@ char *unit_name_mangle(const char *name) {
> return NULL;
>
> for (f = name, t = r; *f; f++) {
> -
> -if (*f == '.')
> -dot = true;
> -
> if (*f == '/')
> *(t++) = '-';
> else if (!strchr("@" VALID_CHARS, *f))
> @@ -503,7 +499,7 @@ char *unit_name_mangle(const char *name) {
> *(t++) = *f;
> }
>
> -if (!dot)
> +if (unit_name_to_type(name) < 0)
> strcpy(t, ".service");
> else
> *t = 0;
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] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
On Tue, 16.10.12 15:35, Michael Biebl (mbi...@gmail.com) wrote: > > 2012/10/16 Lennart Poettering : > > Now, Thomas' patch actually changes much less than people might > > think. This is because sd_booted() simply checks whether > > /sys/fs/cgroup/systemd is mounted. But to run --user on a foreign system > > you need to set that tree up anyway, as that is a requirement for > > systemd either way. > > So, if you have non-systemd init + systemd --user, sd_booted() will > return true, even if the system has not been booted with systemd. Well, If people do stupid things people do stupid things. I am all for adding a high-level warning, like we just did, but if people really insist on ignoring it then they can do this, but I don't have to care anymore. I am all for adding one level of safety checks, but adding more than one, nah, thank you very much... > This could lead to very interesting/unexpected results, like system > software misbehaving (e.g. rsyslog checks for sd_booted()), or in > Debian we use the [ -d /sys/fs/cgroup/systemd ] check at several > places to check whether we have booted with systemd. > > I'm wondering if it would be possible / make sense to use a separate > sysfs tree for users session in such a case, like > /sys/fs/cgroup/systemd-user We definitely want less tres rather than more. And in this case we can't win anyway, so it sounds like a very bad choice... 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] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
2012/10/16 Lennart Poettering : > Now, Thomas' patch actually changes much less than people might > think. This is because sd_booted() simply checks whether > /sys/fs/cgroup/systemd is mounted. But to run --user on a foreign system > you need to set that tree up anyway, as that is a requirement for > systemd either way. So, if you have non-systemd init + systemd --user, sd_booted() will return true, even if the system has not been booted with systemd. This could lead to very interesting/unexpected results, like system software misbehaving (e.g. rsyslog checks for sd_booted()), or in Debian we use the [ -d /sys/fs/cgroup/systemd ] check at several places to check whether we have booted with systemd. I'm wondering if it would be possible / make sense to use a separate sysfs tree for users session in such a case, like /sys/fs/cgroup/systemd-user Michael -- 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 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
On Tue, 16.10.12 09:33, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Lennart Poettering at 16/10/12 01:18 did gyre and gimble: > > On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: > > > >> Running as a user instance won't work at all if systemd isn't running as > >> system > >> manager, so refuse to start in that case. > > > > Applied. Thanks! > > Did you see Auke's side of this thread? Care to comment on it officially > regarding the general principle? Well, we do not really support running systemd --user on a system that wasn't booted with systemd --system. Of course, while I don't want to see an bug reports related to doing something like this I can't stop people from actually doing this if they set up the environment right. Now, Thomas' patch actually changes much less than people might think. This is because sd_booted() simply checks whether /sys/fs/cgroup/systemd is mounted. But to run --user on a foreign system you need to set that tree up anyway, as that is a requirement for systemd either way. So, effectively this added check doesn't change much: people who were capable of setting up the environment properly for running --user on top of a foreign system won't even notice. But for everybody else a clean error will hopefully be the push into the right direction and clarify that we are not interested in any bug reports if they run systemd in this mode. So yeah, this just makes the error nicer and gets a message across that people are on their own if they ignore it. It doesn't actually enforce anything that wasn't enforced before... Hope that makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] journal: Set the last_unused pointer correctly when attaching an unused window
It seems the previous code was copy/pasted from context_detach_window()
but not updated.
---
src/journal/mmap-cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/mmap-cache.c b/src/journal/mmap-cache.c
index 7813f03..251aefe 100644
--- a/src/journal/mmap-cache.c
+++ b/src/journal/mmap-cache.c
@@ -205,8 +205,8 @@ static void context_attach_window(Context *c, Window *w) {
if (w->in_unused) {
/* Used again? */
LIST_REMOVE(Window, unused, c->cache->unused, w);
-if (!c->cache->last_unused)
-c->cache->last_unused = w;
+if (c->cache->last_unused == w)
+c->cache->last_unused = w->unused_prev;
w->in_unused = false;
}
--
1.7.12.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] journal: Properly track the number of allocated windows.
Checks were already in place to make sure that the number of
windows was limited to 64, but the count was never incremented
or decremented.
---
src/journal/mmap-cache.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/journal/mmap-cache.c b/src/journal/mmap-cache.c
index 88fe523..7813f03 100644
--- a/src/journal/mmap-cache.c
+++ b/src/journal/mmap-cache.c
@@ -130,6 +130,7 @@ static void window_free(Window *w) {
assert(w);
window_unlink(w);
+w->cache->n_windows--;
free(w);
}
@@ -157,6 +158,7 @@ static Window *window_add(MMapCache *m) {
w = new0(Window, 1);
if (!w)
return NULL;
+m->n_windows++;
} else {
/* Reuse an existing one */
--
1.7.12.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald leaking maps?
'Twas brillig, and Colin Guthrie at 16/10/12 01:06 did gyre and gimble: > 'Twas brillig, and Lennart Poettering at 16/10/12 00:27 did gyre and gimble: >> On Thu, 11.10.12 23:31, Colin Guthrie (gm...@colin.guthr.ie) wrote: >> >>> Hi, >>> >>> This has been discussion on IRC but I've not heard anything about it >>> specifically nor have I seen any commits relating to it. >>> >>> Using journald without persistent logs (i.e. /run only), I see the >>> memory footprint of journald increasing over time. >>> >>> Checking the maps shows a very high count: >>> >>> [root@jimmy ~]# cat /proc/$(pidof systemd-journald)/maps | grep >>> /run/log/journal/6cb2a4b2bd6df042e57da8a401d4/system.journal | wc -l >>> 1641 >> >> That indeed looks like a lot. >> >>> Something is obviously not good there! journald is using something in >>> the region of 250MB res. >>> >>> What's the best way to debug this? >> >> If maps are leaked it would be good to figure out of what. So could you >> go through /proc/$PID/maps and check for a) files with the "(deleted)" >> suffix, and b) for map for the same range of the same file? >> >> If you find a) then there's probably something borked with releasing >> mmap()s when rotating. If we you find b) then we are apparently too >> stupid to reuse existing mmaps (which is the whole point of >> mmap-cache.c where all this code resides...). > > I've attached the map.txt file. I only have one journal file so it's not > rotated/deleted or anything. > > Can't see any overlaps and with the script below. > > OLDRANGE=; for RANGE in $(cat maps.txt | cut -d' ' -f1); do A=$(echo > $RANGE | cut -d'-' -f1); if [ -n "$OLDRANGE" ]; then if [ "$A" != "$B" > ]; then echo "FAIL $OLDRANGE $RANGE"; fi; fi; B=$(echo $RANGE | cut > -d'-' -f2); OLDRANGE=$RANGE; done > > > FAIL 7f45518d8000-7f455196c000 7f4551bb5000-7f4551c48000 > FAIL 7f4551bb5000-7f4551c48000 7f455211b000-7f455211d000 > > > > So this just identifies a few lines at the end which has gaps in the > mmapping apparently, but no overlaps. > > Does this tell you anything? OK, I think I see the problem. Essentially n_windows is never incremented (or decremented) so the 64 map limit is never imposed. Nice idea, shame about the implementation :p There are also a couple other issues I've spotted in mmap-cache.c so I'll do some tests and prep a patch shortly. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
I would like to be able to run systemd on systems that did not boot up with systemd. For testing purposes and because I have some projects that reuse systemd as a transaction computation engine. Thanks. Colin Guthrie wrote: >'Twas brillig, and Lennart Poettering at 16/10/12 01:18 did gyre and >gimble: >> On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: >> >>> Running as a user instance won't work at all if systemd isn't >running as system >>> manager, so refuse to start in that case. >> >> Applied. Thanks! > >Did you see Auke's side of this thread? Care to comment on it >officially >regarding the general principle? > >Col > > >-- > >Colin Guthrie >gmane(at)colin.guthr.ie >http://colin.guthr.ie/ > >Day Job: > Tribalogic Limited http://www.tribalogic.net/ >Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ >___ >systemd-devel mailing list >systemd-devel@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: append .service when unit does not have valid suffix
systemctl status a and systemctl status a.service lead to same output but
systemctl status a.b and systemctl status a.b.service do not.
---
src/shared/unit-name.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/shared/unit-name.c b/src/shared/unit-name.c
index cfe3133..b0539c7 100644
--- a/src/shared/unit-name.c
+++ b/src/shared/unit-name.c
@@ -491,10 +491,6 @@ char *unit_name_mangle(const char *name) {
return NULL;
for (f = name, t = r; *f; f++) {
-
-if (*f == '.')
-dot = true;
-
if (*f == '/')
*(t++) = '-';
else if (!strchr("@" VALID_CHARS, *f))
@@ -503,7 +499,7 @@ char *unit_name_mangle(const char *name) {
*(t++) = *f;
}
-if (!dot)
+if (unit_name_to_type(name) < 0)
strcpy(t, ".service");
else
*t = 0;
--
1.7.6.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] core/swap.c: Do not add Before=swap.target to swap units.
Am 16.10.2012 02:22, schrieb Lennart Poettering: > On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: > >> The fstab generator adds Before=swap.target by default, and when creating >> a custom .swap unit, you can also add Before=swap.target to the unit. >> >> However, it is impossible to not have this ordering dependency right now. >> Virtually all existing setups likely use the fstab generator, so this >> change is unlikely to break anything. > > Thanks! > > Seems for .mount units we don't generate target deps either in the core > code either, hence we should make the handling of swap unit and mount > units more similar. > > Commited! > > (It feels so good to commit a patch that just deletes code! ;-)) Thank you, this speeds up my boot process for another few nanoseconds or so :) I'd like to add this for completeness: Once you add the swap unit to swap.target.wants, and have DefaultDependencies=yes, you also get Before=swap.target implicitly. I realized this very late, as it is only stated in the systemd.target manpage, but not in the description of DefaultDependencies in systemd.unit. 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] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
'Twas brillig, and Lennart Poettering at 16/10/12 01:18 did gyre and gimble: > On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: > >> Running as a user instance won't work at all if systemd isn't running as >> system >> manager, so refuse to start in that case. > > Applied. Thanks! Did you see Auke's side of this thread? Care to comment on it officially regarding the general principle? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
