[systemd-devel] Antw: [EXT] Dropping split-usr/unmerged-usr support
>>> Luca Boccassi schrieb am 05.04.2022 um 22:07 in Nachricht <05cf10d04274dcbff07fed88e98dca2eebb24b7d.ca...@gmail.com>: > 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/9afd5e7b975e8051c011ff9c07c95e80bd > 954469 Honestly to me the requirement that /usr be part of the root filesystem never had a reasonable argument. Instead I think systemd quit the concept of a simple scaled-down subset to bring up the system. Also with initrd/dracut the concept is even more odd, because the /usr found there is just some arbitrary subset of the real /usr (similar for other filesystems). So why couldn't that work with a really scaled-down /sbin? > > 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) Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept IMHO. It seems systemd is the new Microsoft ("We know what is good for you; just accept it!") ;-) Regards, Ulrich > > -- > Kind regards, > Luca Boccassi
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