Re: [systemd-devel] Detecting Systemd crash

[František Šumšal]

On 2/3/24 16:06, David Timber wrote:

Systemd crashed on me the other day. I was writing up some Systemd units and 
testing them out by daemon-reload every time I wanted to test them out. Not the 
best way to go on about, I know. My bad abusing Systemd to the point of 
crashing. Perhaps it was just a bit flip that caused this.

    systemd[2368]: Assertion 'path_is_absolute(p)' failed at
    src/basic/chase.c:628, function chase(). Aborting.
    systemd[1]: Assertion 'path_is_absolute(p)' failed at
    src/basic/chase.c:628, function chase(). Aborting.
    systemd[1]: Caught  from our own process.
    systemd-coredump[32497]: Due to PID 1 having crashed coredump
    collection will now be turned off.
    systemd-coredump[32497]: [🡕] Process 32496 (systemd) of user 0
    dumped core.
    systemd[1]: Caught , dumped core as pid 32496.
    systemd[1]: Freezing execution.

    ...

    systemd-journald[871]: Failed to send stream file descriptor to
    service manager: Transport endpoint is not connected

I didn't even bother trying producing stack trace. I can get on that if anyone 
wants it.


What you did was perfectly reasonable, systemd shouldn't just crash in that 
case. If you run the recent-ish systemd, a stack trace would be very welcome.


My machine started doing some weird things like Firefox not being able to do 
Ajax properly whilst being able to go to a new page, Chromium not being able to 
create a new tab whilst all the text editors worked just fine, all the 
systemctl commands timing out. So basically, I was using Linux without fork(). 
Anyway.
Well, I think any software can crash for any reason whatsoever. The problem 
with Systemd I realised from this incident is that I had no way of knowing that 
Systemd had crashed until I opened up the journal and kernel logs and saw that 
Systemd had crashed some time ago. In this particular incident, Systemd caught 
the signal and decided to just freeze. No idea why you'd want that because if 
it had just crashed, the kernel would have just panicked and I would have 
realised something went wrong.

1: So I decided that I need a some sort of "watchdog" that warns me when 
something like this happens. Using dbus to poll the status of the Systemd process, it 
could be a GUI app running under a seat, just a daemon that writes a warning message 
using `wall` or just send mail using a primed up MUA process. I wonder if someone already 
had the same idea and went on to make one.

2: How do I get Systemd to freeze to test such program? I mean, if I kill 
Systemd, the kernel would crash so I have to somehow tell Systemd to freeze?


Just trigger systemd's crash handler by sending it a SIGSEGV (kill -SEGV 1).

Re: [systemd-devel] Detecting Systemd crash

[František Šumšal]

On 2/3/24 16:55, Álvaro Cebrián Juan wrote:

Great question!

I am very interested in detecting systemd crashes too since I have experienced 
them recently and have been asked to come up with a solution to react when a 
PID1 crash happens.
In fact, in my recent experiences, a journald crash was enough to render the 
system into an unreliable/degraded state in which some top-level applications 
worked while others didn't.

So adding to David's 1st question, I need to detect systemd and journald 
crashes and then trigger a `systemctl reboot --force --force` command


You can tell systemd to do just that, by setting CrashReboot=yes in system.conf 
[0][1]. It defaults to 'no' to avoid reboot loops.

[0] 
https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf.html#LogColor=
[1] 
https://www.freedesktop.org/software/systemd/man/latest/systemd.html#systemd.crash_reboot



I have also read that Linux Magic System Request Key (SysRq) can help in such 
scenarios but I don't know how they work.

Any help would be very appreciated.
Thank you.

Some related links:
https://news.ycombinator.com/item?id=19023695 

https://news.ycombinator.com/item?id=36873927 

https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html 



El sáb, 3 feb 2024 a las 16:14, David Timber (mailto:d...@dev.snart.me>>) escribió:

Systemd crashed on me the other day. I was writing up some Systemd units
and testing them out by daemon-reload every time I wanted to test them
out. Not the best way to go on about, I know. My bad abusing Systemd to
the point of crashing. Perhaps it was just a bit flip that caused this.

     systemd[2368]: Assertion 'path_is_absolute(p)' failed at
     src/basic/chase.c:628, function chase(). Aborting.
     systemd[1]: Assertion 'path_is_absolute(p)' failed at
     src/basic/chase.c:628, function chase(). Aborting.
     systemd[1]: Caught  from our own process.
     systemd-coredump[32497]: Due to PID 1 having crashed coredump
     collection will now be turned off.
     systemd-coredump[32497]: [🡕] Process 32496 (systemd) of user 0
     dumped core.
     systemd[1]: Caught , dumped core as pid 32496.
     systemd[1]: Freezing execution.

     ...

     systemd-journald[871]: Failed to send stream file descriptor to
     service manager: Transport endpoint is not connected

I didn't even bother trying producing stack trace. I can get on that if
anyone wants it. My machine started doing some weird things like Firefox
not being able to do Ajax properly whilst being able to go to a new
page, Chromium not being able to create a new tab whilst all the text
editors worked just fine, all the systemctl commands timing out. So
basically, I was using Linux without fork(). Anyway.
Well, I think any software can crash for any reason whatsoever. The
problem with Systemd I realised from this incident is that I had no way
of knowing that Systemd had crashed until I opened up the journal and
kernel logs and saw that Systemd had crashed some time ago. In this
particular incident, Systemd caught the signal and decided to just
freeze. No idea why you'd want that because if it had just crashed, the
kernel would have just panicked and I would have realised something went
wrong.

1: So I decided that I need a some sort of "watchdog" that warns me when
something like this happens. Using dbus to poll the status of the
Systemd process, it could be a GUI app running under a seat, just a
daemon that writes a warning message using `wall` or just send mail
using a primed up MUA process. I wonder if someone already had the same
idea and went on to make one.

2: How do I get Systemd to freeze to test such program? I mean, if I
kill Systemd, the kernel would crash so I have to somehow tell Systemd
to freeze?

Re: [systemd-devel] Build failure with sshconfdir=no

[František Šumšal]

On 1/30/24 05:03, daechir wrote:

Hello,

Thank you for the quick fix. I am confirming a successful build now with 
sshconfdir=no. However, I noticed this in the logs:

systemd-tmpfiles[1078]: /usr/lib/tmpfiles.d/20-systemd-ssh-generator.conf:10: 
Path 'no/20-systemd-ssh-proxy.conf' not absolute.


I opened https://github.com/systemd/systemd/pull/31125 that should fix this.


And here is a list of files that are leftover when this option is used:
systemd-git /usr/lib/systemd/system-generators/systemd-ssh-generator
systemd-git /usr/lib/systemd/systemd-ssh-proxy
systemd-git /usr/lib/tmpfiles.d/20-systemd-ssh-generator.conf
systemd-git /usr/share/man/man1/systemd-ssh-proxy.1.gz
systemd-git /usr/share/man/man8/systemd-ssh-generator.8.gz

I am unsure if keeping all of the above is desired or not. For example, certain 
server environments may not need it. I shall let you decide. I am learning a 
lot about how systemd works just based off of these commits. Maybe I can write 
some patchwork in the future.


Except for 20-systemd-ssh-generator.conf (see above) all of these are expected 
to exist, as the sshconfdir and sshdconfdir options only affect ssh-related 
config files (and links) we create, they don't disable the helper programs 
themselves.



Thanks again.

Best,
Daechir

Sent with Proton Mail secure email.

On Tuesday, January 23rd, 2024 at 1:01 PM, emanuele  
wrote:


Ok




Il 22/01/24 17:56, František Šumšal ha scritto:




On 1/22/24 16:22, daechir wrote:




Hello,




I wanted to do a quick followup on this. I think I may have found
where the issue lies.




In https://github.com/systemd/systemd/blob/main/meson.build there's:




sshconfdir = get_option('sshconfdir')
if sshconfdir == ''




But above you shall find:




rpmmacrosdir = get_option('rpmmacrosdir')
if rpmmacrosdir != 'no'




So perhaps it should be:




sshconfdir = get_option('sshconfdir')
if sshconfdir != 'no'





No, this is correct, we set the path to some default value if it's not
set. However, sshconfdir (and sshdconfidir) is missing the "no" value
check when installing the config symlink. I prepped a fix for that,
would be great if you could give it a try:
https://github.com/systemd/systemd/pull/31047




This issue may not just effect sshconfdir but all below:




pamconfdir
sshconfdir
sshdconfdir
bashcompletiondir
zshcompletiondir




Best,
Daechir




Sent with Proton Mail secure email.




On Monday, January 15th, 2024 at 9:15 AM, daechir
daec...@protonmail.com wrote:




Hello,
There's a build failure with the meson option sshconfdir=no. The
error is as follows:





Running custom install script '/usr/bin/sh -c /usr/bin/ln -frsT --
"${DESTDIR:-}/usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf"
"${DESTDIR:-}no/20-systemd-ssh-proxy.conf"'
/usr/bin/ln: failed to create symbolic link
'$/systemd-git/pkg/systemd-gitno/20-systemd-ssh-proxy.conf': No such
file or directory





Best,
Daechir





Sent with Proton Mail secure email.

Re: [systemd-devel] Build failure with sshconfdir=no

[František Šumšal]

On 1/22/24 16:22, daechir wrote:

Hello,

I wanted to do a quick followup on this. I think I may have found where the 
issue lies.

In https://github.com/systemd/systemd/blob/main/meson.build there's:

sshconfdir = get_option('sshconfdir')
if sshconfdir == ''

But above you shall find:

rpmmacrosdir = get_option('rpmmacrosdir')
if rpmmacrosdir != 'no'

So perhaps it should be:

sshconfdir = get_option('sshconfdir')
if sshconfdir != 'no'


No, this is correct, we set the path to some default value if it's not set. However, 
sshconfdir (and sshdconfidir) is missing the "no" value check when installing 
the config symlink. I prepped a fix for that, would be great if you could give it a try: 
https://github.com/systemd/systemd/pull/31047


This issue may not just effect sshconfdir but all below:

pamconfdir
sshconfdir
sshdconfdir
bashcompletiondir
zshcompletiondir

Best,
Daechir

Sent with Proton Mail secure email.

On Monday, January 15th, 2024 at 9:15 AM, daechir  
wrote:



Hello,
There's a build failure with the meson option sshconfdir=no. The error is as 
follows:




Running custom install script '/usr/bin/sh -c /usr/bin/ln -frsT -- 
"${DESTDIR:-}/usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf" 
"${DESTDIR:-}no/20-systemd-ssh-proxy.conf"'
/usr/bin/ln: failed to create symbolic link 
'$/systemd-git/pkg/systemd-gitno/20-systemd-ssh-proxy.conf': No such file or 
directory




Best,
Daechir












Sent with Proton Mail secure email.

Re: udev rules in /etc/udev/rules.d/ ignored/not-loaded on boot; exec manually OK at shell ?

[František Šumšal]

On 12/22/23 12:33, pgnd wrote:

hi,

The issue at hand here is that udev rules in /etc/udev/rules.d are being 
ignored on boot.

ANY valid rule I add -- there -- fails to be read / loaded ...



Did you regenerate your initrd(s) after adding that rule? I.e. `sudo lsinitrd | 
grep 99-enp5s0-sysctl.rules ` should show it to make stuff work properly.

Re: [systemd-devel] Performance issues after migrating to systemd

[František Šumšal]

It would be great to start with `systemd-analyze blame` and `systemd-analyze 
critical-chain`
to see what's going on during boot and point out the time hog(s).

On 11/27/23 07:16, hari.prasat...@microchip.com wrote:

Hello All,

We recently migrated our Yocto project distribution for our embedded
Linux based system to Systemd from sysVinit. We have our graphics
launcher application known as EGT which is public with it's own repo as
below.

https://github.com/linux4sam/egt

We are facing performance issues after migrating to systemd. We have a
set of bench-marking applications whose scores have come down with this
migration especially the startup is too slow. We are trying to use
profiling tools like prof to see what's happening under the hood, but
any pointers on what might be going wrong or areas to check might be
useful. The main launcher service is located at

https://github.com/linux4sam/meta-atmel/blob/kirkstone/recipes-egt/apps/egt-launcher_1.3.bb

Any leads would be helpful.

Regards,
Hari

Re: [systemd-devel] Vague build failure related to systemd-executor

[František Šumšal]

On 11/8/23 16:21, Luca Boccassi wrote:

On Wed, 8 Nov 2023 at 15:00, daechir  wrote:


Hello,
I have been unable to build systemd from around the systemd-executor commit 
here: 
https://github.com/systemd/systemd/commit/bb5232b6a3b8af075ee06cc87416e5f49a6170d3.
 The error received is very vague and even when using verbose mode it's 
generally unhelpful.
The error is as follows:

FAILED: systemd-executor.p/src_core_exec-invoke.c.o
cc -Isystemd-executor.p -I. -I../systemd -Isrc/basic -I../systemd/src/basic 
-Isrc/fundamental -I../systemd/src/fundamental -Isrc/systemd 
-I../systemd/src/systemd -I../systemd/src/libsystemd/sd-bus 
-I../systemd/src/libsystemd/sd-device -I../systemd/src/libsystemd/sd-event 
-I../systemd/src/libsystemd/sd-hwdb -I../systemd/src/libsystemd/sd-id128 
-I../systemd/src/libsystemd/sd-journal -I../systemd/src/libsystemd/sd-netlink 
-I../systemd/src/libsystemd/sd-network -I../systemd/src/libsystemd/sd-resolve 
-Isrc/shared -I../systemd/src/shared -Isrc/core -I../systemd/src/core 
-I/usr/include/security -flto=auto -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu11 
-Wno-missing-field-initializers -Wno-unused-parameter -Warray-bounds 
-Warray-bounds=2 -Wdate-time -Wendif-labels -Werror=format=2 
-Werror=format-signedness -Werror=implicit-function-declaration 
-Werror=implicit-int -Werror=incompatible-pointer-types -Werror=int-conversion 
-Werror=missing-declarations -Werror=missing-prototypes -Werror=overflow 
-Werror=override-init -Werror=return-type -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Werror=strict-flex-arrays -Werror=undef -Wfloat-equal 
-Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-include-dirs 
-Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpointer-arith 
-Wredundant-decls -Wshadow -Wstrict-aliasing=2 -Wstrict-prototypes 
-Wsuggest-attribute=noreturn -Wunused-function -Wwrite-strings 
-Wzero-length-bounds -fdiagnostics-show-option -fno-common -fstack-protector 
-fstack-protector-strong -fstrict-flex-arrays --param=ssp-buffer-size=4 
-Wno-maybe-uninitialized -Wno-unused-result -ftrivial-auto-var-init=zero 
-Werror=shadow -march=native -O2 -pipe -fno-plt -fexceptions 
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security 
-fstack-clash-protection -fcf-protection -fPIE -fno-strict-aliasing 
-fstrict-flex-arrays=1 -fvisibility=hidden -ffunction-sections -fdata-sections 
-include config.h -MD -MQ systemd-executor.p/src_core_exec-invoke.c.o -MF 
systemd-executor.p/src_core_exec-invoke.c.o.d -o 
systemd-executor.p/src_core_exec-invoke.c.o -c ../systemd/src/core/exec-invoke.c
../systemd/src/core/exec-invoke.c: In function ‘exec_invoke’:
../systemd/src/core/exec-invoke.c:4341:79: error: ‘INIT_PROCESS’ undeclared 
(first use in this function); did you mean ‘PRIO_PROCESS’?
  4341 |   context->utmp_mode == 
EXEC_UTMP_INIT  ? INIT_PROCESS :
   |
   ^~~~
   |
   PRIO_PROCESS
../systemd/src/core/exec-invoke.c:4341:79: note: each undeclared identifier is 
reported only once for each function it appears in
../systemd/src/core/exec-invoke.c:4342:79: error: ‘LOGIN_PROCESS’ undeclared 
(first use in this function); did you mean ‘PRIO_PROCESS’?
  4342 |   context->utmp_mode == 
EXEC_UTMP_LOGIN ? LOGIN_PROCESS :
   |
   ^
   |
   PRIO_PROCESS
../systemd/src/core/exec-invoke.c:4343:39: error: ‘USER_PROCESS’ undeclared 
(first use in this function); did you mean ‘KILL_PROCESS’?
  4343 |   USER_PROCESS,
   |   ^~~~
   |   KILL_PROCESS
[688/1337] Linking target 
src/shared/libsystemd-shared-255.r68519.a9d942aeb0-1.so
ninja: build stopped: subcommand failed.


That's a libc define - which glibc version are you using?


This is caused by -Dutmp=false:

$ meson setup build-noutmp -Dutmp=false
...
$ ninja -C build-noutmp/
ninja: Entering directory `build-noutmp/'
[898/2336] Compiling C object systemd-executor.p/src_core_exec-invoke.c.o
FAILED: systemd-executor.p/src_core_exec-invoke.c.o
ccache cc -Isystemd-executor.p -I. -I.. -Isrc/basic -I../src/basic 
-Isrc/fundamental -I../src/fundamental -Isrc/systemd -I../src/systemd 
-I../src/libsystemd/sd-bus -I../src/libsystemd/sd-device 
-I../src/libsystemd/sd-event -I../src/libsystemd/sd-hwdb 
-I../src/libsystemd/sd-id128 -I../src/libsystemd/sd-journal 
-I../src/libsystemd/sd-netlink -I../src/libsystemd/sd-network 
-I../src/libsystemd/sd-resolve -Isrc/shared -I../src/shared -Isrc/core 
-I../src/core -I/usr/include/security -fdiagnostics-color=always 
-D_FI

Re: [systemd-devel] XML for Systemd DBus?

[František Šumšal]

On 8/9/23 17:48, Elsie Hupp wrote:

Note: I am on elementaryOS 6.0.

I am trying to generate a vala interface from the Systemd DBus interface, 
following the example here to get the XML to feed into `vala-dbus-binding-tool`:

https://wiki.gnome.org/Projects/Vala/DBusClientSamples

But I am getting the following error:

```bash
$ dbus-send --print-reply --type=method_call --dest=org.freedesktop.systemd1 
objectpath org.freedesktop.DBus.Introspectable.Introspect
dbus[208973]: arguments to dbus_message_new_method_call() were incorrect, assertion 
"_dbus_check_is_valid_path (path)" failed in file ../../../dbus/dbus-message.c 
line 1366.
This is normally a bug in some application using the D-Bus library.

   D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)



You need to specify a valid object path as well:

$ dbus-send --print-reply --type=method_call --dest=org.freedesktop.systemd1 
/org/freedesktop/systemd1 org.freedesktop.DBus.Introspectable.Introspect
method return time=1691596947.228708 sender=:1.1 -> destination=:1.862 
serial=15362 reply_serial=2
   string "https://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";>

 
...


```

I tried with a specific interface, as well:

```bash
$ dbus-send --print-reply --type=method_call 
--dest=org.freedesktop.systemd1.Device objectpath 
org.freedesktop.DBus.Introspectable.Introspect
dbus[164720]: arguments to dbus_message_new_method_call() were incorrect, assertion 
"_dbus_check_is_valid_path (path)" failed in file ../../../dbus/dbus-message.c 
line 1366.
This is normally a bug in some application using the D-Bus library.

   D-Bus not built with -rdynamic so unable to print a backtrace
Aborted
```

I did several web searches of the error messages, and none of them were 
particularly helpful.

How do I get the XML for the Systemd DBus interface? Is there a way I can work 
around this error, or is there a copy available somewhere online?


--
PGP Key ID: 0xFB738CE27B634E4B


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] *****SPAM***** Re: problem understanding why I am 'forced' to run systemd-journald

[František Šumšal]

On 10/5/22 11:56, Marc wrote:

I have seen that, but is that not something like 'accepting log entries and 
sending data to /dev/null'? I am looking for an option that does not process 
anything.


Not really, as the man page (that Michael already linked) states [0] using 
Storage=volatile will cause the journals to be stored only in memory (under 
/run/log/journal) without any disk writes. You can also disable journal 
completely using Storage=none, in which case journald would work only as a 
forwarder to syslog/kmsg and other configured services (if present). Again, I'd 
recommend going through the Storage= docs in the respective man page[0].

[0] https://www.freedesktop.org/software/systemd/man/journald.conf.html#Storage=


https://www.freedesktop.org/software/systemd/man/journald.conf.html#Stor
age=

→ volatile




Hello,

I have started to upgrade a few machines from CentOS7 to recent

versions of CentOS/Rocky. However I don't really get why there is a
systemd-journald process writing stuff to disk while I have explicitly
configured that logs should go to a remote syslog server.


Reading such pages [1] does not really explain the design idea behind

wanting to generated 2x the amount iops. One would think with all this
environmental co2 global warming stuff, design would be aimed at being
more efficient.


1. why do I need system-journald?

2. why is it not a service that can be disabled?

3. How can I make sure that none of the logs I have, are not having a

duplicate somewhere?


I have 'slower' distributed storage, so it is important to minimize

the amount of useless io being generated.

I was already complaining to Bill Gates, he should shut up about the

environment. If he did not hire 'lazy' people and spend a few billion
more on development we would have a lot less energy consumption, because
windows is using quite a lot of resources compared to linux. Now
upgrading, I have ~2x iops then before.


Can anyone help me with my 3 questions?



--
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B

Re: [systemd-devel] journalctl --vacuum-time does nothing

[František Šumšal]

Hello,

You might want to combine the vacuum option with `--rotate`, since journalctl
won't vacuum journals that are currently online, only archived ones
(`journalctl --header` to get the states of the respective journal files).

From the journalctl man page[1]:


These three switches may also be combined with --rotate into one command. If 
so, all active files are rotated first, and the requested vacuuming operation 
is executed right after. The rotation has the effect that all currently active 
files are archived (and potentially new, empty journal files opened as 
replacement), and hence the vacuuming operation has the greatest effect as it 
can take all log data written so far into account.


[0] 
https://www.freedesktop.org/software/systemd/man/journalctl.html#--vacuum-size=

On 5/15/22 11:12, baba wrote:

Hello,

root@debian:/# journalctl --list-boots
-7 23e0ab37a4774932a2574ca383925641 Sun 2022-05-08 10:47:07 CEST—Sun 2022-05-08 
11:05:24 CEST
-6 60441d099e984f1497ba7dea43f60163 Mon 2022-05-09 08:50:10 CEST—Mon 2022-05-09 
09:05:03 CEST
-5 d30aa08d14f54dc2a3b412f8f3738b85 Tue 2022-05-10 09:30:20 CEST—Tue 2022-05-10 
09:41:46 CEST
-4 03759ec71b984a73b9e577130fa21626 Wed 2022-05-11 10:31:05 CEST—Wed 2022-05-11 
10:40:36 CEST
-3 f9913cc67e0e49ae8323829c43838741 Thu 2022-05-12 09:25:45 CEST—Thu 2022-05-12 
09:40:44 CEST
-2 472f92993a7b4d5b9a48f85223160ec7 Fri 2022-05-13 10:12:50 CEST—Fri 2022-05-13 
10:40:21 CEST
-1 bc878a0a745c4009a68b625c30a0c9e2 Sat 2022-05-14 10:31:51 CEST—Sat 2022-05-14 
10:53:42 CEST
  0 f4dd9da7701b4f96b76396842934ddf4 Sun 2022-05-15 10:33:15 CEST—Sun 
2022-05-15 10:51:56 CEST
root@debian:/# journalctl --vacuum-time=3days
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from 
/var/log/journal/ac27c4f71b94428396fc1096906bddb6.
Vacuuming done, freed 0B of archived journals from /run/log/journal.

What's wrong?



--
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B

Re: [systemd-devel] systemd log_debug

[František Šumšal]

On 6/10/21 2:08 AM, Ted Toth wrote:

What do I need to do to enable log_debug logging in systemd (on
centos7), edit /etc/systemd/system.conf and set LogLevel=debug? If so,
how do I get systemd to reread the config file (kill -HUP 1)? Where do
I view the messages, journalctl -l?


If you want to do this at runtime, you can use:

# systemd-analyze set-log-level debug

The messages will be visible in journal with the rest of the messages, unless
you change the default log target (LogTarget= in /etc/systemd/system.conf or
via systemd-analyze set-log-target ).

Frantisek

--
PGP Key ID: 0xFB738CE27B634E4B



OpenPGP_signature
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Random branch in github.com/systemd/systemd

[František Šumšal]

On 1/2/20 5:13 PM, Mike Gilbert wrote:
> On Thu, Jan 2, 2020 at 9:08 AM Lennart Poettering
>  wrote:
>>> If possible, it would probably be wise to restrict access for pushing
>>> new branches like this.
>>
>> Hmm, how would we do that? Any suggestion? Happy to restrict that, but
>> not sure how to do that...
> 
> I thought maybe there was a setting in github for it, or maybe
> something to do with permissions?
> 
> I don't manage any multi-user github repos myself, so I don't have any
> tangible advice.

This is actually kinda hard, as there is (right now) no configuration option
to restrict creation of new branches.

In theory, we could 'abuse' branch protection rules[0] (which currently protect
the master branch against force pushes), but the branch pattern is not flexible
enough to manage that, precisely the `File.fnmatch()` function[1] it uses 
internally
doesn't have any negation logic to include all branches except for `master`.

I guess we could do something like this[2], which would cover most of the branch
names, in combination with some protection rule (either 'Require pull request 
reviews before merging' or 'Restrict who can push to matching branches'), but
it's not perfect.

[0] 
https://help.github.com/en/github/administering-a-repository/configuring-protected-branches
[1] https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch
[2] 
https://stackoverflow.com/questions/55053460/github-branch-name-pattern-negation/55057727#55057727

-- 
PGP Key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] website

[František Šumšal]

Hello,

I'd say calling it a 'terrible website' is somewhat subjective. I'm not a fan 
of single-page websites or websites
which won't load with a plethora of other javascript libraries. Also, as the 
person, who 'nominated' systemd for
having a 'terrible website' said in the thread you linked - "I like this kind 
of simplicity" - which is also true.
The current systemd homepage is pretty simple, without any additional 
distracting eye-candy, and it's getting the
job done really well, for a 'fancy' man page (and as a bonus, it works in 
elinks/links/lynx!).

Also, there is a second systemd website, again pretty bare-bones, generated 
using GH pages[0].

That said, this is just my personal opinion, not in any way affiliated with the 
systemd organization. Also, I'm
not trying to disrespect your offer, just pointing out different aspects of the 
current website :-).


[0] https://systemd.io/

On 11/13/19 6:37 PM, Nick Ham wrote:
> Dear systemd,
> 
> You've been nominated on Reddit (see 
> https://old.reddit.com/r/opensource/comments/dvnugk/what_are_some_preferably_popular_open_source)
>  for having a 'terrible website'. 
> 
> I am writing to offer help change that for you. I make the world's fastest 
> website generator called Nift (https://nift.cc ). It is 
> cross-platform (bsd/linux/osx/windows) and open source (MIT license), up to 
> 15 times faster than its closest rival Hugo and can handle building websites 
> with millions of pages.
> 
> Examples of websites made with Nift using HTML5 UP templates include:
> 
>  1. https://nift.cc 
>  2. https://tron.ai-bots.net 
>  3. https://lvsportsclinic.com 
>  4. https://n-ham.com 
> 
> Although Nift works awesomely for coding websites from scratch as well, HTML5 
> UP templates I have in mind for making websites for people with include:
> 
> https://html5up-nsm-templates.github.io/alpha/
> https://html5up-nsm-templates.github.io/helios/
> https://html5up-nsm-templates.github.io/landed/
> https://html5up-nsm-templates.github.io/telephasic/
> https://html5up-nsm-templates.github.io/twenty/
> https://html5up-nsm-templates.github.io/txt/
> 
> You can see the gitlab mirror of the source code for the Nift website at 
> https://gitlab.com/nifty-site-manager/nifty-site-manager.gitlab.io , the 
> files used to build the website are in the content and template directories 
> and the built website is in the site directory. It would look pretty much the 
> same for a systemd website made with Nift just using a different template and 
> having different content etc..
> 
> Let me know if you are potentially interested in pursuing a new website for 
> systemd. I can be contacted at cont...@n-ham.com 
> 
> Regards,
> Dr Nicholas Ham
> https://n-ham.com 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] perform fsck on everyt boot

[František Šumšal]

Hello,

FWIK passno > 0 in /etc/fstab configures only order in which the fsck
is performed, not the frequency. To configure the frequency as well,
I'd recommend taking a look at `man systemd-fsck@.service`, especially
the `fsck.mode=force` kernel command line parameter, which should do
exactly what you're trying to achieve.

On 11/11/19 1:33 PM, Belisko Marek wrote:
> Hi,
> 
> I'm using systemd 234 (build by yocto) and I've setup automount of
> sdcard in fstab. This works perfectly fine. But I have seen from time
> to time when system goes to emergency mode because sdcard filesystem
> (ext4) have an issue and cannot be mounted. I was thinking about
> forcing fsck for every boot. Reading manual it should be enough to set
> passno (6th column in fstab) to anything higher then 0. I set ti to 2
> but inspecting logs it doesn't seems fsck is performed. Am I still
> missing something? Thanks.
> 
> BR,
> 
> marek
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab obsolete?

[František Šumšal]

On 8/28/19 9:33 AM, Ulrich Windl wrote:
> Hi!
> 
> systemd in SLES 12 is causing endless frustration here:
> 
> Yesterday I was migrating some filesystems to a new device (multipath, 
> MD-RAID, LVM, filesystem, mountpoints, etc.), updating /etc/fstab and other 
> files as needed.
> After migration was successful, I also cleaned up the now obsolete resources 
> (multipath, MD-RAID, filesystem, mountpoints, etc.)
> Everything looked OK...
> 
> But some time later the application was stopped, as the new filesystems were 
> unmounted by systemd (even though active processes were using it) WITHOUT 
> giving a reason for "Stopped target Local File Systems" in syslog. Instead 
> systemd tried to mount the filesystems that had been removed from /etc/fstab!
> 
> It seems systemd does not like root to unmount a filesystem that is still 
> present in /etc/fstab.
> 
> So I tried to "start local filesystems" after realizing the problem this 
> morning. Then disaster (named "systemd") strikes back:
> It tried to mount the old filesystems that do no longer exist (and are no 
> longer present in /etc/fstab), resulting in a "dependency failed", and in 
> turn it transitioned a fully running server from multi-user mode to emergency 
> mode, shutting down all services, network, etc.
> 
> That is why I hate systemd!
> 
> I did a "daemon-reload" in the emergency shell, and then I was able to start 
> the default target again.

It looks like you forgot to issue `systemctl daemon-reload` after updating 
/etc/fstab, which is, actually, a documented incompatibility
with SysV scripts:

Excerpt from 
https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/:
> On SysV systems changes to init scripts or any other files that define the 
> boot process (such as /etc/fstab) usually had an immediate effect on 
> everything started later. This is different on systemd-based systems where 
> init script information and other boot-time configuration files are only 
> reread when "systemctl daemon-reload" is issued. (Note that some commands, 
> notably "systemctl enable"/"systemctl disable" do this implicitly however.) 
> This is by design, and a safety feature, since it ensures that half-completed 
> changes are not read at the wrong time.

As you stated later, running `systemctl daemon-reload` later fixes the issue, 
because that's what you're supposed
to do after updating pretty much any configuration when it comes to systemd.

Also, I'm still amazed how you expect people to help you with all the "insults" 
on systemd's behalf - maybe try to refrain from
doing them in the future, as the issue may not be in systemd. And even if it 
is, this attitude won't make it magically better.

> 
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

[František Šumšal]

On 8/26/19 9:43 AM, Ulrich Windl wrote:
 Mantas Mikulenas  schrieb am 23.08.2019 um 05:55 in
> Nachricht
> :
>> On Thu, Aug 22, 2019, 16:38 Ulrich Windl
> 
>> wrote:
>>
>> systemd tag bot  schrieb am
>>> 22.08.2019
>>> um
>>> 13:56 in Nachricht <20190822115637.1.05c510c92b339...@refi64.com>:
 A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
>>> the
 tarball here:
>>>
>>>
 * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
> to
   4194304 by default, i.e. the full 22bit range the kernel
>>> allows,
 up
   from the old 16bit range. This should improve security and
   robustness, as PID collisions are made less likely (though
>>>
>>> I doubt it's increasing robustness for any existing application as
>>> pid_traditionally was 16 bit. I don't know if some applications try to
>>> sprintf() a pid into a char[6], but if they do, it might cause an
>>> application
>>> failure...
>>>
>>
>>
>> I've been using this value for at least 5 years, and did expect many issues
>> at first, but so far haven't encountered any at all.
>>
>> (I do kind of suspect that if there are any programs affected by this and
>> without source code available, they would be so old that they wouldn't
>> really run on a bleeding-edge distro anyway...)
> 
> Having read some C questions in stackoverflow yesterday, I'm afraid there are
> quite a lot of programmers out there writing code you couldn't even imagine in
> your most terrible nightmares ;-)
> So distribution code may be safe, but some in-house stuff or even "commercial"
> stuff may be horrible:
> (Not to long ago I had a problem that some commercial application only started
> up if the text terminal was wider than 80 characters. Why? The C program 
> called
> "ps" internally, and that in turn truncated output lines depending on the 
> value
> of COLUMNS environment...)
> 
> I think you really don't know what the most terrible imaginable programmer can
> write... ;-)
> 
> Or maybe the infamous Ariane V failure: They reused software they had tested
> before, but the hardware was different ;-)

Frankly, if such software exists and is used somewhere, it should definitely get
fixed or obsoleted. Following your mindset of keeping backward compatibility
even with broken or not future-proof software, we should also revert all changes
regarding the unix timestamp and year 2038 (in general), because changing
the datatype size from 32bit to 64bit _might_ break someone's code.

By the time this change gets to your enterprise distro, it should be pretty well
tested by various distributions close to the upstream. And even if that's not 
enough,
you an simply override the value back when you package systemd for downstream. 
From
what I can tell from various reports from our customers in RHEL, bumping
kernel.pid_max to the full 22bit range will be more than a welcome change.

-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

[František Šumšal]

On 7/3/19 8:37 AM, Ulrich Windl wrote:
>>>> František Šumšal  schrieb am 02.07.2019 um 18:51 in
> Nachricht :
> 
>>
>> On 7/2/19 4:36 PM, Michael Biebl wrote:
>>> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
>>> :
>>>> Reading the output above, I can see, why the people contact this mailing
>>>> list.
>>>
>>> I agree here. While we do have `support-url` which distros can
>>> override, Apparently not all of them do.
>>> We could probably change our build system, that `support-url` needs to
>>> be set explicitly and if unset, no Support URL is printed in the
>>> journal output.
>>
>> This, or since the URL leads to [0], it would be also useful to extend
>> the "About systemd-devel" section to provide some kind of warning that
>> this ML is mainly/only for upstream systemd, not for systemd shipped by
>> distributions.
>>
>> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> 
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency shell.

I, too, like my systems to be booted up only a half way with half of the 
services
being in an unknown/inconsistent state.

> Combined
> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see anything on
> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

Well, you see the service it's waiting for. Then there are several things
which should help you when things go south:

1) If the service fails and it's crucial to the boot process, you'll end up
   in the (apparently pretty despised by you) emergency shell, where you can
   go through all necessary logs to see what went wrong
2) By adding a simple "debug" to the kernel command line, or making use of
   systemd.log_level and systemd.log_target kernel cmdline options you can
   dump the entire boot process logic to the console. You can't do this by
   default, as it unnecessarily over-saturates the console line, which leads
   to a significant slow down of the entire boot process. Also, as everything
   is logged (as would any sane person expect), it would, again - unnecessarily,
   bloat the system journal

You can't simply blame systemd that it refuses to boot when there's a service,
marked as the system administrator as crucial, yet which is apparently broken
in some way.

> While the individual cause of such failures may not be systemd, the overall
> effect of user frustration is very much due to systemd, giving it its bad
> reputation.
> So don't worry if people come to complain about many things here.

The main issue is not about people complaining (that's actually something we
want/need to), but in the version many of these users use. The systemd has
come a long way for the past few years, and there's been thousands of changes
to make things smooth and painless. But, of course, not all distributions
use the bleeding-edge version of systemd, which then introduces certain 
problems:

1) An user complains about something which has been already fixed, yet not
   backported to their distro
2) Some distributions (like RHEL) base their systemd package on a certain 
version
   (like 219 in RHEL 7) and then backport only some patches from the upstream. 
Thus,
   upstream developers shouldn't/can't be expected to know what mixture of 
patches the
   user uses.

In both cases, the downstream bug tracker is way to go. The downstream 
maintainers
know their systemd package much better and can tell you, if it's an 
downstream-only
issue, and a backport is necessary, or if it's indeed an upstream issue and they
can guide you here (or they'd do that on your behalf).

> Removing or changing the support URL might help to reduce the traffic here,
> but it definitely wouldn't help against the bad reputation of systemd.

Honestly, I'm kind of impressed you stamp the "bad bad systemd" phrase all over
the place several times in your emails, yet you still expect people to be able
to (willingly) help you.

> To make systemd better, you really have to listen to the users' problems and
> actually MAKE IT BETTER.

I know this might surprise you, but that's how systemd got where it is now. We
just need to filter out problems which have been already fixed, so we can focus
on solving the outstanding ones (instead of going through hundreds of bug 
reports).

>>
>>> Just an idea...
>>>
>>>
>>> Michael
>>>
>>
>> -- 
>> PGP Key ID: 0xFB738CE27B634E4B
> 
> 
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

[František Šumšal]

On 7/2/19 4:36 PM, Michael Biebl wrote:
> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
> :
>> Reading the output above, I can see, why the people contact this mailing
>> list.
> 
> I agree here. While we do have `support-url` which distros can
> override, Apparently not all of them do.
> We could probably change our build system, that `support-url` needs to
> be set explicitly and if unset, no Support URL is printed in the
> journal output.

This, or since the URL leads to [0], it would be also useful to extend
the "About systemd-devel" section to provide some kind of warning that
this ML is mainly/only for upstream systemd, not for systemd shipped by
distributions.

[0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel

> Just an idea...
> 
> 
> Michael
> 

-- 
PGP Key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CentOS CI test suites failing

[František Šumšal]

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 there's over 20 jobs to run,
it might take a good portion of the night (it's a midnight here), so please be 
patient :-)

I'll check the status once again in the morning and try to go through any 
unexpected
failures (hopefully there won't be any).

On 5/28/19 10:35 PM, František Šumšal wrote:
> 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 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
>> merge a patch[0] to handle it on the systemd side, and start slowly 
>> re-triggering
>> failed jobs for PRs.
>>
>> [0] https://github.com/systemd/systemd-centos-ci/pull/120
>>
>> On 5/28/19 8:39 PM, zach wrote:
>>> 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 call last):
>>>   File "./agent-control.py", line 371, in 
>>> node, ssid = ac.allocate_node(args.version, args.arch)
>>>   File "./agent-control.py", line 82, in allocate_node
>>> jroot = json.loads(res)
>>>   File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
>>> return _default_decoder.decode(s)
>>>   File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode
>>> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>>>   File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode
>>> raise ValueError("No JSON object could be decoded")
>>> ValueError: No JSON object could be decoded
>>> Traceback (most recent call last):
>>>   File "./agent-control.py", line 449, in 
>>> ac.free_session(ssid)
>>> NameError: name 'ssid' is not defined
>>> mv: cannot stat ‘artifacts_*’: No such file or director 
>>>
>>>
>>> ___
>>> systemd-devel mailing list
>>> systemd-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>>
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CentOS CI test suites failing

[František Šumšal]

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 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
> merge a patch[0] to handle it on the systemd side, and start slowly 
> re-triggering
> failed jobs for PRs.
> 
> [0] https://github.com/systemd/systemd-centos-ci/pull/120
> 
> On 5/28/19 8:39 PM, zach wrote:
>> 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 call last):
>>   File "./agent-control.py", line 371, in 
>> node, ssid = ac.allocate_node(args.version, args.arch)
>>   File "./agent-control.py", line 82, in allocate_node
>> jroot = json.loads(res)
>>   File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
>> return _default_decoder.decode(s)
>>   File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode
>> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>>   File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode
>> raise ValueError("No JSON object could be decoded")
>> ValueError: No JSON object could be decoded
>> Traceback (most recent call last):
>>   File "./agent-control.py", line 449, in 
>> ac.free_session(ssid)
>> NameError: name 'ssid' is not defined
>> mv: cannot stat ‘artifacts_*’: No such file or director 
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CentOS CI test suites failing

[František Šumšal]

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
merge a patch[0] to handle it on the systemd side, and start slowly 
re-triggering
failed jobs for PRs.

[0] https://github.com/systemd/systemd-centos-ci/pull/120

On 5/28/19 8:39 PM, zach wrote:
> 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 call last):
>   File "./agent-control.py", line 371, in 
> node, ssid = ac.allocate_node(args.version, args.arch)
>   File "./agent-control.py", line 82, in allocate_node
> jroot = json.loads(res)
>   File "/usr/lib64/python2.7/json/__init__.py", line 338, in loads
> return _default_decoder.decode(s)
>   File "/usr/lib64/python2.7/json/decoder.py", line 366, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib64/python2.7/json/decoder.py", line 384, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
> Traceback (most recent call last):
>   File "./agent-control.py", line 449, in 
> ac.free_session(ssid)
> NameError: name 'ssid' is not defined
> mv: cannot stat ‘artifacts_*’: No such file or director 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[František Šumšal]

On 5/14/19 8:39 AM, Ulrich Windl wrote:
>>>> František Šumšal  schrieb am 13.05.2019 um 17:13 in
> Nachricht <064ac942-a4d7-b547-0705-22f3262f5...@sumsal.cz>:
>> On 5/13/19 8:20 AM, Ulrich Windl wrote:
>>
>> That's actually not true. The argument for `systemd-analyze verify` is a 
>> file name,
>> so you verify an arbitrary file for correctness:
> 
> So it seems it improved since v228. I filed an enhancement request for
> OpenSUSE to upgrade systemd yesterday, BTW...

It has always worked this way, iirc, i.e. it was meant to be used for
offline unit verification, so it should definitely work with systemd v228.

Reference:
https://github.com/systemd/systemd/commit/8b835fccdad78d89f9cc64f9b02059fb75ffbab1

> 
>>
>> $ cat > test.service << EOF
>>> [Unit]
>>> Description=test unit
>>>
>>> [Service]
>>> ExecStrt=/bin/true
>>> EOF
>> $ systemd-analyze verify test.service 
>> File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP 
>> firewall (IPAddressDeny=any), but the local system does not support 
>> BPF/cgroup based firewalling.
>> Proceeding WITHOUT firewalling in effect! (This warning is only shown for 
>> the first loaded unit using IP firewalling.)
>> /tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service'
>> test.service: Service lacks both ExecStart= and ExecStop= setting.
> Refusing.
>> Unit test.service has a bad unit file setting.
>> $ systemctl status test.service
>> Unit test.service could not be found.
>>
>>
>> -- 
>> GPG key ID: 0xFB738CE27B634E4B
> 
> 
> 


-- 
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

[František Šumšal]

On 5/13/19 8:20 AM, Ulrich Windl wrote:

>> "systemd‑analyze verify" exists. Since a long long time.
> 
> Not really: You can't verify a unit file while it's not "installed". Comare it
> to validating an XML file, for example.
> 

That's actually not true. The argument for `systemd-analyze verify` is a file 
name,
so you verify an arbitrary file for correctness:

$ cat > test.service << EOF
> [Unit]
> Description=test unit
> 
> [Service]
> ExecStrt=/bin/true
> EOF
$ systemd-analyze verify test.service 
File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP firewall 
(IPAddressDeny=any), but the local system does not support BPF/cgroup based 
firewalling.
Proceeding WITHOUT firewalling in effect! (This warning is only shown for the 
first loaded unit using IP firewalling.)
/tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service'
test.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Unit test.service has a bad unit file setting.
$ systemctl status test.service
Unit test.service could not be found.


-- 
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bugfix release(s)

[František Šumšal]

On 1/14/19 4:36 PM, Lennart Poettering wrote:
> On Mo, 14.01.19 10:59, Jan Synacek (jsyna...@redhat.com) wrote:
>
> I'd love to see some more CI hookup with Arch and Debian for example
> (right now there is zero) or even just a git preview package set or so 
> that interested people can test. Without either it's very likely that
> things break on those distros, because there's no way we'll catch
> things beforehand.
> 

After a really quick "research" I noticed that many distributions provide
Vagrant images[0][1]. In theory, it should be possible to simply use these 
images
along with a "proper" virtualization (vagrant-libvirt[2]) to do some more 
advanced
sanity/regression testing.

As for the infrastructure - the CentOS CI machine pool provides baremetal 
machines[3],
which would be, again in theory, great for such effort. Having a dedicated 
machine pool
of distro-specific nodes would be much better, but that's a long shot even if 
would be 
possible for some distro to have such infrastructure.


[0] https://www.archlinux.org/download/ (section Vagrant images)
[1] https://app.vagrantup.com/debian
[2] https://github.com/vagrant-libvirt/vagrant-libvirt
[3] https://wiki.centos.org/QaWiki/PubHardware


-- 
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel