The out-of-space issue seems to be resolved, for now, and the systemd CentOS CI
script
should respect the (apparently) newly introduced rate-limiting machinery.
I went through the PRs updated in the last few hours and re-triggered all
CentOS CI
jobs, so it now eating through the backlog. Given
This might take a little bit longer than anticipated, as the Jenkins slave also
ran
out of space.
On 5/28/19 10:02 PM, František Šumšal wrote:
> Hello!
>
> Thanks for the heads up. This was unfortunately caused by two simultaneous
> issues:
>
> 1) CentOS CI pool ran out of pre-installed
Hello!
Thanks for the heads up. This was unfortunately caused by two simultaneous
issues:
1) CentOS CI pool ran out of pre-installed machines
2) I forgot to handle such situation in the systemd CentOS CI code :-)
After giving the CentOS CI a few hours to get back on its tracks, I'll shortly
Looks like CentOS CI test suites are failing on multiple PRs with errors
like those listed below. Any advise on how to get these passing again or
who I could reach out to for help getting this back in order?
2019-05-28 16:04:26,307 [agent-control/] ERROR: Execution failed
Traceback (most recent
On 28.05.19 16:59, Lennart Poettering wrote:
> On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote:
>
>>> Regarding the syscall groupings: yes, the groups exist precisely to
>>> improve cases like this. That said, I think we should be careful not
>>> have an inflation of groups, and
On 28.05.19 16:59, Lennart Poettering wrote:
> On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote:
>
>>> Regarding the syscall groupings: yes, the groups exist precisely to
>>> improve cases like this. That said, I think we should be careful not
>>> have an inflation of groups, and
On Di, 28.05.19 14:04, Josef Moellers (jmoell...@suse.de) wrote:
> > Regarding the syscall groupings: yes, the groups exist precisely to
> > improve cases like this. That said, I think we should be careful not
> > have an inflation of groups, and we should ask twice whether a group
> > is really
On Mon, 20 May 2019 at 11:49:42 +0200, Lennart Poettering wrote:
> Ideally some infrastructure like PK would supply this mechanism
> instead of us btw.
polkit is for controlled privilege escalation where an unprivileged user
asks a privileged system service to do something, and the system service
Hi Lennart,
On 28.05.2019 14:02, Lennart Poettering wrote:
The kernel devices are currently single-use only. Most of these fields
are exported via sysfs too however:
grep . /sys/class/watchdog/watchdog0/*
Oh, that's very useful and indeed, there is timeleft property there and
it's
On 28.05.2019 14:00, Zbigniew Jędrzejewski-Szmek wrote:
This currently isn't exported by systemd, and there's even no log
message at debug level. I guess this could be exposed, but I don't
think it'd be very useful. If the watchdog ping works, most people
don't need to look at it. If it doesn't,
On 28.05.19 13:57, Lennart Poettering wrote:
> On Di, 28.05.19 11:43, Josef Moellers (jmoell...@suse.de) wrote:
>
>> Hi,
>>
>> We just had an issue with a partner who tried to filter out the "open"
>> system call:
>>
>> . This may, in general, not be a very clever idea because how is one to
>>
On Di, 28.05.19 13:50, Wiktor Kwapisiewicz (wik...@metacode.biz) wrote:
> Hi Zbyszek,
>
> On 28.05.2019 13:43, Zbigniew Jędrzejewski-Szmek wrote:
> > What kind of information are you after?
>
> One interesting statistic I'd like to see changing is the time when the
> watchdog was notified last.
>
On Tue, May 28, 2019 at 01:50:53PM +0200, Wiktor Kwapisiewicz wrote:
> Hi Zbyszek,
>
> On 28.05.2019 13:43, Zbigniew Jędrzejewski-Szmek wrote:
> >What kind of information are you after?
>
> One interesting statistic I'd like to see changing is the time when
> the watchdog was notified last.
>
>
On Di, 28.05.19 11:43, Josef Moellers (jmoell...@suse.de) wrote:
> Hi,
>
> We just had an issue with a partner who tried to filter out the "open"
> system call:
>
> . This may, in general, not be a very clever idea because how is one to
> load a shared library to start with, but this example has
On 28.05.19 12:25, Martin Wilck wrote:
> On Tue, 2019-05-28 at 11:43 +0200, Josef Moellers wrote:
>> Hi,
>>
>> We just had an issue with a partner who tried to filter out the
>> "open"
>> system call:
>>
>> . This may, in general, not be a very clever idea because how is one
>> to
>> load a shared
Hi Zbyszek,
On 28.05.2019 13:43, Zbigniew Jędrzejewski-Szmek wrote:
What kind of information are you after?
One interesting statistic I'd like to see changing is the time when the
watchdog was notified last.
For example, there is Timeleft in this wdctl output [0]:
# wdctl
Identity:
On Tue, May 28, 2019 at 12:59:27PM +0200, Wiktor Kwapisiewicz wrote:
> Hello,
>
> I've enabled "RuntimeWatchdogSec=30" in /etc/systemd/system.conf
> (after reading excellent "systemd for Administrators" series [0]).
>
> Before enabling that "wdctl" printed nice statistics but now it only
>
On Di, 28.05.19 12:04, Martin Wilck (mwi...@suse.de) wrote:
> We are facing problems during udev coldplug on certain very big systems
> (read: > 1000 CPUs, several TiB RAM). Basically, the systems get
> totally unresponsive immediately after coldplug starts, and remain so
> for minutes, causing
Hello,
I've enabled "RuntimeWatchdogSec=30" in /etc/systemd/system.conf (after
reading excellent "systemd for Administrators" series [0]).
Before enabling that "wdctl" printed nice statistics but now it only
informs that the "watchdog already in use, terminating." I guess this is
obvious as
On Tue, 2019-05-28 at 11:43 +0200, Josef Moellers wrote:
> Hi,
>
> We just had an issue with a partner who tried to filter out the
> "open"
> system call:
>
> . This may, in general, not be a very clever idea because how is one
> to
> load a shared library to start with, but this example has
We are facing problems during udev coldplug on certain very big systems
(read: > 1000 CPUs, several TiB RAM). Basically, the systems get
totally unresponsive immediately after coldplug starts, and remain so
for minutes, causing uevents to time out. Attempts to track it down
have shown that access
Hi,
We just had an issue with a partner who tried to filter out the "open"
system call:
. This may, in general, not be a very clever idea because how is one to
load a shared library to start with, but this example has revealed
something problematic ...
SystemCallFilter=~open
The problem
22 matches
Mail list logo
