Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Am 28.02.2017 um 02:19 schrieb Marc Lehmann: > Package: systemd > Version: 232-18 > Severity: normal > > Dear Maintainer, > > I upgraded to stretch, using kernel 4.4.47. When rebooting, system could > not clean up device mapper targets, leading to a hard crash for all cache > targets, requiring

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Package: systemd Version: 232-18 Severity: normal Dear Maintainer, I upgraded to stretch, using kernel 4.4.47. When rebooting, system could not clean up device mapper targets, leading to a hard crash for all cache targets, requiring many hours of heavy I/O after bootup and creating a high-risk

Bug#856306: add tilegx architecture support to systemd

Hi Martin, On Mon, Feb 27, 2017 at 09:11:00PM +0100, Martin Pitt wrote: > The fix landed in upstream master. By "certainly miss stretch" you mean > support > for tilegx at large, or this particular patch? Because we have some other That was way faster than I expected. I do mean tilegx support

Processed: Re: Bug#856306: add tilegx architecture support to systemd

Processing control commands: > tag -1 fixed-upstream Bug #856306 [src:systemd] add tilegx architecture support to systemd Added tag(s) fixed-upstream. -- 856306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856306 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Bug#856306: add tilegx architecture support to systemd

Control: tag -1 fixed-upstream Hello Helmut, Helmut Grohne [2017-02-27 17:09 +0100]: > I don't think cherry-picking is necessary or useful, because it will > certainly miss stretch, it will very likely hit buster, and > cherry-picking it in the bootstrap tooling is easy. The fix landed in

Processed: bug 856306 is forwarded to https://github.com/systemd/systemd/pull/5474

Processing commands for cont...@bugs.debian.org: > forwarded 856306 https://github.com/systemd/systemd/pull/5474 Bug #856306 [src:systemd] add tilegx architecture support to systemd Changed Bug forwarded-to-address to 'https://github.com/systemd/systemd/pull/5474' from

Bug#856306: add tilegx architecture support to systemd

Control: forwarded -1 https://lists.freedesktop.org/archives/systemd-devel/2017-February/038375.html On Mon, Feb 27, 2017 at 03:16:20PM +0100, Michael Biebl wrote: > Please file that issue directly upstream and report back with the bug > number so we can mark it as fowarded accordingly. Done.

Processed: Re: Bug#856306: add tilegx architecture support to systemd

Processing control commands: > forwarded -1 > https://lists.freedesktop.org/archives/systemd-devel/2017-February/038375.html Bug #856306 [src:systemd] add tilegx architecture support to systemd Set Bug forwarded-to-address to

Bug#856306: add tilegx architecture support to systemd

Dear Helmut Am 27.02.2017 um 14:51 schrieb Helmut Grohne: > systemd fails to cross build for tilegx (and likely fails to build Please file that issue directly upstream and report back with the bug number so we can mark it as fowarded accordingly. Once it has been accepted upstream, we can

Bug#856306: add tilegx architecture support to systemd

Source: systemd Tags: upstream patch User: helm...@debian.org Usertags: rebootstrap systemd fails to cross build for tilegx (and likely fails to build natively as well), because the LIB_ARCH_TUPLE is missing. It has since been added to dpkg's cputable. Thus I am attaching the obvious patch

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

Am 27.02.2017 um 13:57 schrieb Martin Pitt: > Felipe Sateler [2017-02-27 9:39 -0300]: >> For avoidance of doubt, RuntimeMaxUse does not refer to RSS, but >> rather to the "disk" space used in /run when the persistent journal is >> not active. So this flag does not control what you want. AFAIK,

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

Felipe Sateler [2017-02-27 9:39 -0300]: > For avoidance of doubt, RuntimeMaxUse does not refer to RSS, but > rather to the "disk" space used in /run when the persistent journal is > not active. So this flag does not control what you want. AFAIK, there > is no way to control max memory usage.

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

The observed behaviour is *with* the persistent journal. Forwarding to inetutils-syslogd and using Storage=none results in steady memory consumption at 20% of the peak memory I experienced while testing Storage=persistent (and that's for both journald and syslogd combined). On 17-02-27 07:23

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

Ahh. Is there currently any functionality in journald for controlling flushing to limit RSS or is this just a case where journald's built-in logging capabilities are not currently suited to constrained systems? On 17-02-27 07:04 AM, Michael Biebl wrote: Am 27.02.2017 um 10:41 schrieb

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

On Mon, Feb 27, 2017 at 6:41 AM, Stephan Sokolow (You actually CAN reply) wrote: > > In my testing, 7.7% RSS appeared to be a hard lower limit well above the > 2/3/4 MiB I specified while experimenting. For avoidance of doubt, RuntimeMaxUse does not refer to RSS, but

Bug#854805: systemd: dbus interraction problems leading to timeouts

Am 27.02.2017 um 11:04 schrieb Vincent Danjean: > I forgot to update this bug report. > On my machine, I did some cleanup (apt-get autoremove + manual > removal of package that are not available in stretch any more). > This solve the problem: the machine boots correctly without > any

Bug#856265: marked as done (systemd-journald: RuntimeMaxUse is not properly obeyed)

Your message dated Mon, 27 Feb 2017 13:04:00 +0100 with message-id <9f79cc95-f1b9-684e-38ac-27749e35d...@debian.org> and subject line Re: Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed has caused the Debian Bug report #856265, regarding systemd-journald: RuntimeMaxUse is not

Bug#854805: systemd: dbus interraction problems leading to timeouts

Le 27/02/2017 à 09:51, Stephan Sokolow (You actually CAN reply) a écrit : > I'm not sure if it's relevant, but I managed to get similar > connection timeouts (specifically, `systemctl` consistently failing > with timeouts on `org.freedesktop.systemd1`) when I ran `apt-get > install systemd-cron`

Bug#753576: systemd stopped responding to dbus.socket connections

Oh, wait. I forgot step 0. Update and upgrade first. It's such a habit that I lump it in with importing the VMs. On 17-02-27 04:04 AM, Stephan Sokolow (You actually CAN reply) wrote: I'm not sure if it's the same problem, but, I have something that at least has similar symptoms which may be

Bug#753576: systemd stopped responding to dbus.socket connections

I'm not sure if it's the same problem, but, I have something that at least has similar symptoms which may be easier to reproduce: Release: The VirtualBox version of the bento/debian-8.6 Vagrant VM Reproduction: 1. apt-get install systemd-cron 2. Futz around until you realize jessie's systemd

Bug#854805: systemd: dbus interraction problems leading to timeouts

I'm not sure if it's relevant, but I managed to get similar connection timeouts (specifically, `systemctl` consistently failing with timeouts on `org.freedesktop.systemd1`) when I ran `apt-get install systemd-cron` and then changed my mind after I realized my systemd was too early to support