Andreas Gerstmayr

> Why are PCP processes logging to disk in separate files? Why isn't it using syslog logging to land in journald? We've an open ticket for that: https://github.com/performancecopilot/pcp/issues/1040 but it...

Redis by default is snapshotting its entire database periodically on disk. When you restart Redis, it will load the contents of `dump.rdb` into memory (see https://redis.io/topics/persistence for more info). There's...

> This is why I asked about PCP logging to files. If it logged to journald either vis syslog or stdout/stderr from systemd process creation, then the disk would not...

Afaics there is no change to `redis.conf` required here, the log (spam) is produced by PCP. > shall I close this one out and we can continue discussions in the...

Unfortunately no, I wasn't investigating further yet.

Another (probably better) solution would be to offload the synchronous, blocking discovery code (calling into libpcp) into a worker thread. The Redis client functions will need to be called from...

> pmproxy is multi-threaded due to the discovery code (the libuv code automatically creates threads for it under the covers, it's not something we explicitly do) - no other reason...

I was curious how Debian is packaging the libbpf-tools, and they're including "bpftool" as a package name in the build dependencies: https://salsa.debian.org/debian/bpfcc/-/blob/c38a724df294a1b86a2c6cff315d0e351f7ea3c6/debian/control#L34

> With regard to libbpf0 and libelf1, libbpf0 depends directly on libelf1. Good to know, I've dropped the explicit dependency on libelf now. > libbpf deps has been listed in...

Debian has a standalone `bpftool` package now: https://packages.debian.org/bullseye/bpftool (afaics this package didn't exist when creating this PR, as the `bpftool` program was included in the `linux-tools` package previously). However Ubuntu...