Re: [systemd-devel] Dropping split-usr/unmerged-usr support
On 4/5/2022 1:07 PM, Luca Boccassi wrote: As part of our spring cleaning effort, we are considering when to drop support for split/unmerged-usr filesystem layouts. For others like me who don't know this term. (I'd seen and appreciate the concept but didn't know what people called it.) https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
Am Di., 5. Apr. 2022 um 22:07 Uhr schrieb Luca Boccassi : > > Hi, > > As part of our spring cleaning effort, we are considering when to drop > support for split/unmerged-usr filesystem layouts. > > A build-time warning was added last year: > > https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd954469 > > We are now adding a runtime taint as well. > > Which distributions are left running with systemd on a split/unmerged- > usr system? cough, I guess you know at least one :-)
[systemd-devel] Dropping split-usr/unmerged-usr support
Hi, As part of our spring cleaning effort, we are considering when to drop support for split/unmerged-usr filesystem layouts. A build-time warning was added last year: https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd954469 We are now adding a runtime taint as well. Which distributions are left running with systemd on a split/unmerged- usr system? (reminder: we refer to a system that boots without a populated /usr as split-usr, and a system where bin, sbin and lib* are not symlinks to their counterparts under /usr as unmerged-usr) -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] [EXT] Re: Q: journalctl -b -g logrotate
On Tue, Apr 5, 2022 at 3:22 PM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Mantas Mikulenas schrieb am 05.04.2022 um 11:08 in > Nachricht > : > > On Tue, Apr 5, 2022 at 9:36 AM Ulrich Windl < > > ulrich.wi...@rz.uni-regensburg.de> wrote: > > > >> Hi! > >> > >> I have two questions for "journalctl -b -g logrotate": > >> > >> 1) I'm unsure what the exact rules for matching a "-g expression" are: > >> Some kernel messages are matched, others not. > >> > > > > All entries with a MESSAGE= are matched (after doing until/since/boot-id > > checks). They might still be hidden for other reasons though, e.g. > messages > > containing weird escape characters (or accidental binary data) will be > > hidden unless you use -a. > > And how do I find out whether a kernel message has a MESSAGE=? > Messages from kernel (kmsg) or from syslog always do, it's only userspace messages from sd_journal_send() that might not have one. (Though if it shows up in journalctl, then obviously it has a message.) Try different `-o` modes though to see what fields each log entry actually has. > > As soon as I add _MESSAGE= I get no output any more (even with MESSAGE=.*). > It's MESSAGE, not _MESSAGE, and there's no regex support for this kind of match. Journalctl can't search for "all entries that contain this key" unfortunately. (Would be useful though.) -- Mantas Mikulėnas
[systemd-devel] Antw: [EXT] Re: Q: journalctl -b -g logrotate
>>> Mantas Mikulenas schrieb am 05.04.2022 um 11:08 in Nachricht : > On Tue, Apr 5, 2022 at 9:36 AM Ulrich Windl < > ulrich.wi...@rz.uni-regensburg.de> wrote: > >> Hi! >> >> I have two questions for "journalctl -b -g logrotate": >> >> 1) I'm unsure what the exact rules for matching a "-g expression" are: >> Some kernel messages are matched, others not. >> > > All entries with a MESSAGE= are matched (after doing until/since/boot-id > checks). They might still be hidden for other reasons though, e.g. messages > containing weird escape characters (or accidental binary data) will be > hidden unless you use -a. And how do I find out whether a kernel message has a MESSAGE=? As soon as I add _MESSAGE= I get no output any more (even with MESSAGE=.*). > > >> 2) When the -b restricts messages to the current boot, why is output shown >> like this?: >> # journalctl -b -g logrotate >> -- Logs begin at Wed 2020-11-25 11:27:53 CET, end at Tue 2022-04-05 >> 08:01:02 CEST. -- >> >> I mean the boot was definitely in 2022, so I think the message is not >> really helpful. Why not show the date and time when the search starts (i.e. >> boot time)? >> > > There's no such message in the current systemd version. See > https://github.com/systemd/systemd/pull/21775. > > >> >> The next thing is "-k": If I supply it, kernel messages are _not_ found: >> # journalctl -S 2022-04-02 -k | grep "OCFS2:" |head >> # journalctl -S 2022-04-02 | grep "OCFS2:" |head >> Apr 02 02:00:06 h18 kernel: OCFS2: ERROR (device dm-17): >> ocfs2_validate_gd_self: Group descriptor #209970 has bad signature EXBLK01 >> Apr 02 02:00:06 h18 kernel: OCFS2: File system is now read-only. >> Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): >> ocfs2_validate_gd_self: Group descriptor #209817 has bad signature EXBLK01 >> Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): >> ocfs2_validate_gd_self: Group descriptor #209946 has bad signature EXBLK01 >> >> So can I find kernel messages from previous boots? >> > > `journalctl -k` is meant to imitate dmesg (except with correct timestamps), > so it shows the current boot only. You can use _TRANSPORT=kernel to filter > for kernel messages if you don't want that. > > $ journalctl _TRANSPORT=kernel -g BogoMIPS Yup, that works! > > -- > Mantas Mikulėnas
Re: [systemd-devel] nss-systemd
On Di, 05.04.22 11:24, Gildas Bayard (gildas.bay...@hds.utc.fr) wrote: > Indeed my systemd is version 245.4-4ubuntu3.15... > > How could I know that the minimal required version was 249 (so I don't > bother you again!)? Two options: 1. Check https://github.com/systemd/systemd/blob/main/NEWS 2. Check git logs Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] nss-systemd
Indeed my systemd is version 245.4-4ubuntu3.15...
How could I know that the minimal required version was 249 (so I don't
bother you again!)?
Le 05/04/2022 à 11:21, Lennart Poettering a écrit :
On Di, 05.04.22 10:30, Gildas Bayard (gildas.bay...@hds.utc.fr) wrote:
Hello,
I'd like to dynamically provide group data when group data is queried by the
system (as in "getent group").
Since nsswitch can use systemd, I've looked at nss-systemd.
As a first step I tried to define a Static Drop-In JSON User Record (because
user definition is documented with more details than group definition).
So I added a toto.user in /etc/userdb/ with this
{
"userName" : "toto",
"uid" :
}
and a .user file pointing to toto.user
But when I run "getent passwd", there's no toto user.
I tried to see a bit what's going on with strace and I see that getent opens
libnss_systemd.so.2 and looks for files in /run/systemd/userdb.
But it's not even trying to read in the directories |etc/userdb/|,
|/run/userdb/|, |/run/host/userdb/| and |/usr/lib/userdb/|
||
Any suggestion?
Maybe your systemd version is simply too old? You need v249 at the
least for the above.
Lennart
--
Lennart Poettering, Berlin
--
*Gildas Bayard*
Ingénieur de Recherche
Responsable Sécurité des Systèmes d'Informations
Coordonnateur pour la Protection du Potentiel Scientifique et Technique
/Télétravail le mercredi/
Laboratoire HEUDIASYC - UMR CNRS 7253 - GI028
UTC Centre de Recherches de Royallieu
BP 20529 - 60205 Compiègne Cedex
Tél. 03 44 23 46 71
Re: [systemd-devel] nss-systemd
On Di, 05.04.22 10:30, Gildas Bayard (gildas.bay...@hds.utc.fr) wrote:
> Hello,
>
> I'd like to dynamically provide group data when group data is queried by the
> system (as in "getent group").
>
> Since nsswitch can use systemd, I've looked at nss-systemd.
>
> As a first step I tried to define a Static Drop-In JSON User Record (because
> user definition is documented with more details than group definition).
>
> So I added a toto.user in /etc/userdb/ with this
>
> {
> "userName" : "toto",
> "uid" :
> }
> and a .user file pointing to toto.user
>
> But when I run "getent passwd", there's no toto user.
>
> I tried to see a bit what's going on with strace and I see that getent opens
> libnss_systemd.so.2 and looks for files in /run/systemd/userdb.
>
> But it's not even trying to read in the directories |etc/userdb/|,
> |/run/userdb/|, |/run/host/userdb/| and |/usr/lib/userdb/|
>
> ||
>
> Any suggestion?
Maybe your systemd version is simply too old? You need v249 at the
least for the above.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] Q: journalctl -b -g logrotate
On Tue, Apr 5, 2022 at 9:36 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > Hi! > > I have two questions for "journalctl -b -g logrotate": > > 1) I'm unsure what the exact rules for matching a "-g expression" are: > Some kernel messages are matched, others not. > All entries with a MESSAGE= are matched (after doing until/since/boot-id checks). They might still be hidden for other reasons though, e.g. messages containing weird escape characters (or accidental binary data) will be hidden unless you use -a. > 2) When the -b restricts messages to the current boot, why is output shown > like this?: > # journalctl -b -g logrotate > -- Logs begin at Wed 2020-11-25 11:27:53 CET, end at Tue 2022-04-05 > 08:01:02 CEST. -- > > I mean the boot was definitely in 2022, so I think the message is not > really helpful. Why not show the date and time when the search starts (i.e. > boot time)? > There's no such message in the current systemd version. See https://github.com/systemd/systemd/pull/21775. > > The next thing is "-k": If I supply it, kernel messages are _not_ found: > # journalctl -S 2022-04-02 -k | grep "OCFS2:" |head > # journalctl -S 2022-04-02 | grep "OCFS2:" |head > Apr 02 02:00:06 h18 kernel: OCFS2: ERROR (device dm-17): > ocfs2_validate_gd_self: Group descriptor #209970 has bad signature EXBLK01 > Apr 02 02:00:06 h18 kernel: OCFS2: File system is now read-only. > Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): > ocfs2_validate_gd_self: Group descriptor #209817 has bad signature EXBLK01 > Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): > ocfs2_validate_gd_self: Group descriptor #209946 has bad signature EXBLK01 > > So can I find kernel messages from previous boots? > `journalctl -k` is meant to imitate dmesg (except with correct timestamps), so it shows the current boot only. You can use _TRANSPORT=kernel to filter for kernel messages if you don't want that. $ journalctl _TRANSPORT=kernel -g BogoMIPS -- Mantas Mikulėnas
[systemd-devel] nss-systemd
Hello,
I'd like to dynamically provide group data when group data is queried by
the system (as in "getent group").
Since nsswitch can use systemd, I've looked at nss-systemd.
As a first step I tried to define a Static Drop-In JSON User Record
(because user definition is documented with more details than group
definition).
So I added a toto.user in /etc/userdb/ with this
{
"userName" : "toto",
"uid" :
}
and a .user file pointing to toto.user
But when I run "getent passwd", there's no toto user.
I tried to see a bit what's going on with strace and I see that getent
opens libnss_systemd.so.2 and looks for files in /run/systemd/userdb.
But it's not even trying to read in the directories |etc/userdb/|,
|/run/userdb/|, |/run/host/userdb/| and |/usr/lib/userdb/|
||
Any suggestion?
Sincerely
--
*Gildas Bayard*
Ingénieur de Recherche
Responsable Sécurité des Systèmes d'Informations
Coordonnateur pour la Protection du Potentiel Scientifique et Technique
/Télétravail le mercredi/
Laboratoire HEUDIASYC - UMR CNRS 7253 - GI028
UTC Centre de Recherches de Royallieu
BP 20529 - 60205 Compiègne Cedex
Tél. 03 44 23 46 71
[systemd-devel] Q: journalctl -b -g logrotate
Hi! I have two questions for "journalctl -b -g logrotate": 1) I'm unsure what the exact rules for matching a "-g expression" are: Some kernel messages are matched, others not. 2) When the -b restricts messages to the current boot, why is output shown like this?: # journalctl -b -g logrotate -- Logs begin at Wed 2020-11-25 11:27:53 CET, end at Tue 2022-04-05 08:01:02 CEST. -- I mean the boot was definitely in 2022, so I think the message is not really helpful. Why not show the date and time when the search starts (i.e. boot time)? The next thing is "-k": If I supply it, kernel messages are _not_ found: # journalctl -S 2022-04-02 -k | grep "OCFS2:" |head # journalctl -S 2022-04-02 | grep "OCFS2:" |head Apr 02 02:00:06 h18 kernel: OCFS2: ERROR (device dm-17): ocfs2_validate_gd_self: Group descriptor #209970 has bad signature EXBLK01 Apr 02 02:00:06 h18 kernel: OCFS2: File system is now read-only. Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): ocfs2_validate_gd_self: Group descriptor #209817 has bad signature EXBLK01 Apr 02 02:00:07 h18 kernel: OCFS2: ERROR (device dm-17): ocfs2_validate_gd_self: Group descriptor #209946 has bad signature EXBLK01 So can I find kernel messages from previous boots? (systemd-246.16-150300.7.39.1.x86_64 of SLES15 SP3) Regards, Ulrich
