[systemd-devel] Antw: [EXT] [systemd‑devel] Q: Activating persistent Journal in SLES15
>>> "Ulrich Windl" schrieb am 11.08.2022 um 09:29 in Nachricht <62f4afee02a10004c...@gwsmtp.uni-regensburg.de>: > Hi! > > I had activated the persistent journal in SLES15 SP2 using these commands: > # mkdir /var/log/journal > # systemctl restart systemd‑journald.service > > A directory had been created automatically: > systemd‑journald[4273]: System journal > (/var/log/journal/e766c8d06f144b1588487221640f55b5) is 8.0M, max 4.0G, 3.9G > free. > > However when I tried the same with SLES15 SP4, id did not work: > systemd‑journald[12614]: Runtime Journal > (/run/log/journal/1b5c6954ed9447fabb805f9da0419e15) is 8.0M, max 635.7M, > 627.7M free. > > Meanwhile the first host is at SP3, but when I list the directories I see a > difference: > h16:~ # ll ‑d /var/log/journal/ > drwxr‑sr‑x 1 root systemd‑journal 64 Nov 30 2020 /var/log/journal/ > > v02:~ # ll ‑d /var/log/journal/ > drwxr‑xr‑x 1 root root 0 Aug 11 09:16 /var/log/journal/ > > I cannot remember havign changed the group or permission of > /var/log/journal/ after creating it. > My guess is that some package update did that change automatically, but now > the procedure to set it up is different. > > Can anybody confirm? > > Both systems use: > [Journal] > #Storage=auto > > The SP3 host uses systemd‑246.16‑150300.7.48.1.x86_64, while the SP4 host uses > systemd‑249.11‑150400.8.5.1.x86_64. > > Regards, > Ulrich Hi! It seems I found the solution, but I still wonder: Is it a bug? After reading the manual, I tried: v02:~ # journalctl --flush Then I saw: Aug 11 09:41:24 v02 systemd-journald[12614]: Time spent on flushing to /var/log/journal/1b5c6954ed9447fabb805f9da0419e15 is 29.811ms for 2696 entries. Aug 11 09:41:24 v02 systemd-journald[12614]: System Journal (/var/log/journal/1b5c6954ed9447fabb805f9da0419e15) is 8.0M, max 4.0G, 3.9G free. Why didn't the service restart work? The permissions are unchanged, BTW: v02:~ # ll -d /var/log/journal/ drwxr-xr-x 1 root root 64 Aug 11 09:41 /var/log/journal/ Regards, Ulrich
[systemd-devel] Antw: Re: Antw: [EXT] Re: [systemd‑devel] systemd‑nspawn container not starting on RHEL9.0
>>> Neal Gompa schrieb am 11.08.2022 um 09:22 in
Nachricht
:
> On Thu, Aug 11, 2022 at 3:15 AM Ulrich Windl
> wrote:
>>
>> >>> Lennart Poettering schrieb am 10.08.2022 um
22:09
>> in
>> Nachricht :
>> > On Mi, 10.08.22 10:13, Thomas Archambault (t...@tparchambault.com)
wrote:
>> >
>> >> Thank you again Lennart, and thx Kevin.
>> >>
>> >> That makes total sense, and accounts for the application's high level
>> >> start‑up delay which appears to be what we are stuck with if we are
over
>> >> xfs. Unfortunately, it's difficult to dictate to the client to change
>> their
>> >> fs type, consequently we can't develop / ship a tool with that baseline
>> >> latency on our primary target platform (RHEL xx.)
>> >>
>> >> So the next obvious question would be, is XFS reflink support on the
>> >> systemd‑nspawn roadmap or actually, (and even better) has support been
>> >> incorporated already in the latest and greatest src and I'm just behind
>> the
>> >> curve working with the older version of nspawn as shipped in RHEL90?
>> >>
>> >> I'm asking because according to the RHEL 9 docs
>> >
>>
>
(https://access.redhat.com/documentation/en‑us/red_hat_enterprise_linux/9/htm
> l‑
>>
>> >
>>
>
single/managing_file_systems/index#the‑xfs‑file‑system_assembly_overview‑of‑a
> vaila
>> > ble‑file‑systems)
>> >> it's the current default fs and is configured for "Reflink‑based file
>> >> copies."
>> >
>> > We issue copy_file_range() syscall, which should do reflinks on xfs,
>> > if it supports that. Question is if your kernel supports that too. I
>> > have no experience with xfs though, no idea how xfs hooked up reflink
>> > initially. And we never tested that really. I don't think outside RHEL
>> > many people use xfs.
>>
>> Not true: For SUSE /home is typically using XFS, and we use it with SLES
for
>> (huge) database filesystems.
>>
>
> In openSUSE, this hasn't been the default behavior for a while. SLES
> will catch up here eventually.
Accidentially I created some filesystems using "yast2 disk" in SLES15 SP4
(latest updates) today:
There the default for any "data" filesystems is (still) XFS (while OS uses
BtrFS).
Agreed, if you don't have a separate filesystem for /home, it'll be a BtrFS
subvolume ("fill one, you fill all", I don't like the subvolume concept, or I
didn't understand the benefits)
Regards,
Ulrich
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
[systemd-devel] Q: Activating persistent Journal in SLES15
Hi! I had activated the persistent journal in SLES15 SP2 using these commands: # mkdir /var/log/journal # systemctl restart systemd-journald.service A directory had been created automatically: systemd-journald[4273]: System journal (/var/log/journal/e766c8d06f144b1588487221640f55b5) is 8.0M, max 4.0G, 3.9G free. However when I tried the same with SLES15 SP4, id did not work: systemd-journald[12614]: Runtime Journal (/run/log/journal/1b5c6954ed9447fabb805f9da0419e15) is 8.0M, max 635.7M, 627.7M free. Meanwhile the first host is at SP3, but when I list the directories I see a difference: h16:~ # ll -d /var/log/journal/ drwxr-sr-x 1 root systemd-journal 64 Nov 30 2020 /var/log/journal/ v02:~ # ll -d /var/log/journal/ drwxr-xr-x 1 root root 0 Aug 11 09:16 /var/log/journal/ I cannot remember havign changed the group or permission of /var/log/journal/ after creating it. My guess is that some package update did that change automatically, but now the procedure to set it up is different. Can anybody confirm? Both systems use: [Journal] #Storage=auto The SP3 host uses systemd-246.16-150300.7.48.1.x86_64, while the SP4 host uses systemd-249.11-150400.8.5.1.x86_64. Regards, Ulrich
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemd‑nspawn container not starting on RHEL9.0
On Thu, Aug 11, 2022 at 3:15 AM Ulrich Windl wrote: > > >>> Lennart Poettering schrieb am 10.08.2022 um 22:09 > in > Nachricht : > > On Mi, 10.08.22 10:13, Thomas Archambault (t...@tparchambault.com) wrote: > > > >> Thank you again Lennart, and thx Kevin. > >> > >> That makes total sense, and accounts for the application's high level > >> start‑up delay which appears to be what we are stuck with if we are over > >> xfs. Unfortunately, it's difficult to dictate to the client to change > their > >> fs type, consequently we can't develop / ship a tool with that baseline > >> latency on our primary target platform (RHEL xx.) > >> > >> So the next obvious question would be, is XFS reflink support on the > >> systemd‑nspawn roadmap or actually, (and even better) has support been > >> incorporated already in the latest and greatest src and I'm just behind > the > >> curve working with the older version of nspawn as shipped in RHEL90? > >> > >> I'm asking because according to the RHEL 9 docs > > > (https://access.redhat.com/documentation/en‑us/red_hat_enterprise_linux/9/html‑ > > > > single/managing_file_systems/index#the‑xfs‑file‑system_assembly_overview‑of‑availa > > ble‑file‑systems) > >> it's the current default fs and is configured for "Reflink‑based file > >> copies." > > > > We issue copy_file_range() syscall, which should do reflinks on xfs, > > if it supports that. Question is if your kernel supports that too. I > > have no experience with xfs though, no idea how xfs hooked up reflink > > initially. And we never tested that really. I don't think outside RHEL > > many people use xfs. > > Not true: For SUSE /home is typically using XFS, and we use it with SLES for > (huge) database filesystems. > In openSUSE, this hasn't been the default behavior for a while. SLES will catch up here eventually. -- 真実はいつも一つ！/ Always, there's only one truth!
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemd‑nspawn container not starting on RHEL9.0
>>> Lennart Poettering schrieb am 10.08.2022 um 22:09 in Nachricht : > On Mi, 10.08.22 10:13, Thomas Archambault (t...@tparchambault.com) wrote: > >> Thank you again Lennart, and thx Kevin. >> >> That makes total sense, and accounts for the application's high level >> start‑up delay which appears to be what we are stuck with if we are over >> xfs. Unfortunately, it's difficult to dictate to the client to change their >> fs type, consequently we can't develop / ship a tool with that baseline >> latency on our primary target platform (RHEL xx.) >> >> So the next obvious question would be, is XFS reflink support on the >> systemd‑nspawn roadmap or actually, (and even better) has support been >> incorporated already in the latest and greatest src and I'm just behind the >> curve working with the older version of nspawn as shipped in RHEL90? >> >> I'm asking because according to the RHEL 9 docs > (https://access.redhat.com/documentation/en‑us/red_hat_enterprise_linux/9/html‑ > single/managing_file_systems/index#the‑xfs‑file‑system_assembly_overview‑of‑availa > ble‑file‑systems) >> it's the current default fs and is configured for "Reflink‑based file >> copies." > > We issue copy_file_range() syscall, which should do reflinks on xfs, > if it supports that. Question is if your kernel supports that too. I > have no experience with xfs though, no idea how xfs hooked up reflink > initially. And we never tested that really. I don't think outside RHEL > many people use xfs. Not true: For SUSE /home is typically using XFS, and we use it with SLES for (huge) database filesystems. > > If you provide a more complete strace output, you should see the > copy_file_range() stuff there. > > Lennart > > ‑‑ > Lennart Poettering, Berlin
