Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 10:05 PM, Andrei Borzenkov wrote: > strace -p $(pgrep systemd-journal) > > You will not see actual writes as file is memory mapped, but it > definitely does not do any fsync() every so often.

Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 10:05 PM, Andrei Borzenkov wrote: >> I have no idea if it's fsync or what. How can I tell? >> > > strace -p $(pgrep systemd-journal) > > You will not see actual writes as file is memory mapped, but it > definitely does not do any fsync() every so

Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 10:05 PM, Andrei Borzenkov wrote: > 18.04.2017 06:50, Chris Murphy пишет: >>> What exactly "changes" mean? Write() syscall? >> >> filefrag reported entries increase, it's using FIEMAP. >> > > So far it sounds like btrfs allocates new extent on every

Re: [systemd-devel] journal fragmentation on Btrfs

18.04.2017 06:50, Chris Murphy пишет: > On Mon, Apr 17, 2017 at 9:42 PM, Andrei Borzenkov wrote: >> 17.04.2017 22:49, Chris Murphy пишет: >>> On Mon, Apr 17, 2017 at 11:27 AM, Andrei Borzenkov >>> wrote: 17.04.2017 19:25, Chris Murphy пишет: >

[systemd-devel] feature request: implement macsec interface configuration in systemd-networkd

Are there any plans on implementing macsec interface configuration from systemd-networkd? Since its already added in kernel as a loadable module, fedora misses a patched iproute2 to support macsec and also lacks automatic interface configuration (i dunno if nm supports it?) preferably from

Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 9:42 PM, Andrei Borzenkov wrote: > 17.04.2017 22:49, Chris Murphy пишет: >> On Mon, Apr 17, 2017 at 11:27 AM, Andrei Borzenkov >> wrote: >>> 17.04.2017 19:25, Chris Murphy пишет: This explains one system's fragmented

Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 11:27 AM, Andrei Borzenkov wrote: > 17.04.2017 19:25, Chris Murphy пишет: >> This explains one system's fragmented journals; but the other system >> isn't snapshotting journals and I haven't figured out why they're so >> fragmented. No snapshots, and

Re: [systemd-devel] journal fragmentation on Btrfs

Here's an example rotated log (Btrfs, NVMe, no compression, default ssd mount option). As you can see it takes up more space on disk than it contains data, so there's a lot of slack space for some reason, despite /etc/systemd/journald.conf being unmodified and thus Compress=Yes. file:

Re: [systemd-devel] journal fragmentation on Btrfs

17.04.2017 19:25, Chris Murphy пишет: > This explains one system's fragmented journals; but the other system > isn't snapshotting journals and I haven't figured out why they're so > fragmented. No snapshots, and they are all +C at create time > (systemd-journald default on Btrfs). Is it possible

Re: [systemd-devel] journal fragmentation on Btrfs

On Mon, Apr 17, 2017 at 3:57 AM, Lennart Poettering wrote: >> I do manual snapshots before software updates, which means new writes >> to these files are subject to COW, but additional writes to the same >> extents are overwrites and are not COW because of chattr +C. I've

Re: [systemd-devel] journal fragmentation on Btrfs

Am Mon, 17 Apr 2017 16:01:48 +0200 schrieb Kai Krakow : > > We also ask btrfs to defrag the file as soon as we mark it as > > archived... > > This makes sense. And I've learned that journal on btrfs works much > better if you use many small files vs. a few big files. I've

Re: [systemd-devel] journal fragmentation on Btrfs

Am Mon, 17 Apr 2017 11:57:21 +0200 schrieb Lennart Poettering : > On Sun, 16.04.17 14:30, Chris Murphy (li...@colorremedies.com) wrote: > > > Hi, > > > > This is on a Fedora 26 workstation (systemd-233-3.fc26.x86_64) > > that's maybe a couple weeks old and was clean

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 20:20, Chris Murphy (li...@colorremedies.com) wrote: > 4. Systemd for not enforcing limited kill exemption to those running > from initramfs, i.e. ignore kill exemption if the program is running > other than initramfs. Well, we are not the police, and we do kill everything by

Re: [systemd-devel] Unable to mask /proc using currently available options (InaccessiblePaths...)

On Wed, 12.04.17 18:27, Timothée Ravier (sios...@gmail.com) wrote: > Hi, > > I would like to make the /proc directory inaccessible for some services. > Unfortunately, adding the InaccessiblePaths=/proc option to a service unit > will > not work. Hmm, what precisely do you intend to make

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

On Mon, 10.04.17 19:30, Chris Murphy (li...@colorremedies.com) wrote: > >> Remember, all of this is because there *is* software that does the wrong > >> thing, and it *is* possible for software to hang and be unkillable. It > >> would > >> be good for systemd to do the right thing even in the

Re: [systemd-devel] Why journald has NotifyAccess=all set in the unit file?

On Tue, 11.04.17 10:18, Michal Sekletar (msekl...@redhat.com) wrote: > Hi everyone, > > I was asked today about $subject. I quickly skimmed trough the > relevant parts of the code and current default looks like an > oversight. I think there are no processes other than journald involved > in

Re: [systemd-devel] what is sd_notify() really for ?

Am 17.04.2017 um 00:47 schrieb Enrico Weigelt, metux IT consult: On 17.04.2017 00:04, Lennart Poettering wrote: Please always check the man pages if you have questions regarding a specific systemd interface: https://www.freedesktop.org/software/systemd/man/sd_notify.html Done so, of

Re: [systemd-devel] systemd-nspawn network-interface

On Thu, 13.04.17 16:08, poma (pomidorabelis...@gmail.com) wrote: > Hello > > Regaining of the network-interface, as is stated in the manual, ain't > happening; > man 1 systemd-nspawn > ... > OPTIONS > ... > --network-interface= > Assign the specified network interface to the container. >

Re: [systemd-devel] Short way to show messages of executable and unit with `journalctl`

On Fri, 14.04.17 20:30, Paul Menzel (paulepan...@users.sourceforge.net) wrote: > Dear systemd folks, > > > Is there a shorter way than below to show all messages of an executable > and a unit? > > ``` > $ journalctl _COMM=sudo + _SYSTEMD_UNIT=NetworkManager.service > ``` > > I would be happy

Re: [systemd-devel] journal fragmentation on Btrfs

On Sun, 16.04.17 14:30, Chris Murphy (li...@colorremedies.com) wrote: > Hi, > > This is on a Fedora 26 workstation (systemd-233-3.fc26.x86_64) that's > maybe a couple weeks old and was clean installed. Drive is NVMe. > > > # filefrag * > system.journal: 9283 extents found > user-1000.journal:

Re: [systemd-devel] Early testing for service enablement

On Thu, 13.04.17 11:58, Martin Wilck (mwi...@suse.com) wrote: > On Thu, 2017-04-13 at 08:49 +, Mantas Mikulėnas wrote: > > IIRC, enable/disable/is-enabled are implemented entirely via direct > > filesystem access. Other than that, systemctl uses a private socket > > when running as root – it

Re: [systemd-devel] Early testing for service enablement

On Thu, 13.04.17 12:05, Martin Wilck (mwi...@suse.com) wrote: > On Thu, 2017-04-13 at 11:45 +0200, Lennart Poettering wrote: > > On Thu, 13.04.17 08:49, Mantas Mikulėnas (graw...@gmail.com) wrote: > > > > > IIRC, enable/disable/is-enabled are implemented entirely via direct > > > filesystem

Re: [systemd-devel] what is sd_notify() really for ?

On Mon, 17.04.17 00:47, Enrico Weigelt, metux IT consult (enrico.weig...@gr13.net) wrote: > On 17.04.2017 00:04, Lennart Poettering wrote: > > > Please always check the man pages if you have questions regarding a > > specific systemd interface: > > > >