=== genii is now known as genii-core
=== Kilroy9 is now known as Kilroy
[04:34] <tomreyn> octav1a: for a yet more complete answer: 20.04 lts server would also install updates as snaps, for packages that were installed as snaps (or have been converted to snaps, but i don't think this will happen during an LTS release). there are ways to delay those, but - as far as i know - none to prevent it.
[04:35] <tomreyn> (the linux kernel or nvidia drivers are not packaged as snaps as this time)
[04:36] <octav1a> I don't think I'm using any non-default snaps
=== hornbill047 is now known as hornbill
[06:22] <cpaelzer> good morning
=== gschanuel215 is now known as gschanuel21
=== ErmJurCerrDurr is now known as MJCD
=== mirespace_ is now known as mirespace
[09:42] <mirespace> ahasenack: :)!
=== vlm_ is now known as vlm
=== thegodsq- is now known as thegodsquirrel
[11:10] <mirespace> ahasenack: rsync focal package regression on dgit(arm64) , in skew-clone test  local file not found ... digging into it
[11:11] <mirespace> ahasenack: rsync bionic, regression on lxc(ppc64el) and s3ql(armhf) ... checking it also
[11:21] <mirespace> ahasenack: timeout for lxc (bionic, ppc64el)
[11:32] <mirespace> ahasenack: fileNotFound on t4_fuse test (standart) for s3ql(armhf, bionic)
[12:04] <athos> good morning!
[12:04] <mirespace> hi athos
[12:04] <ahasenack> morning
[12:04] <mirespace> hi Andreas
[12:05] <ahasenack> hi mirespace 
[12:06] <athos> \o
=== shabbz is now known as peninsularshabbz
=== lotuspsychje_ is now known as lotuspsychje
[14:36] <ahasenack> sergiodj: looking at squid now
[14:38] <ahasenack> I'm unsire if bileto is actually working wrt dep8 tests. Last I tried a few weeks ago, the test run never left the "queued" state
[14:39] <ahasenack> unsure*
[15:04] <sergiodj> ahasenack: thanks
[16:15] <sergiodj> mirespace: ahasenack: I will try retriggering dgit again; the error doesn't seem related to mirespace's patch, and I know that dgit's dep8 is pretty extensive and sometimes a bit flaky
[16:15] <ahasenack> ok, that will be the 2nd retry
[16:15] <ahasenack> remember this is also an opportunity to fix flaky tests ;)
[16:16] <ahasenack> or else the next uploader will go through this ordeal again
[16:16] <ahasenack> of course, it depends on what is going on, we can't fix the world
[16:20] <sergiodj> this is for an SRU, so I'm not expecting us to fix flaky tests in this case
[16:22] <sergiodj> also, based on what I've seen from dgit's tests, investigating and fixing its dep8 tests might not be very trivial
[16:44] <mirespace> sergiodj: ahasenack: the lxc is now different from the one I see this morning on the log "ERROR: Failed to download http://images.linuxcontainers.org//images/ubuntu/xenial/ppc64el/default/20220207_07:42//rootfs.tar.xz"
[16:44] <mirespace> exercise test failing
[16:45] <mirespace> see* saw
[16:52] <ahasenack> now it's showing the failure to download? The latest run?
[16:58] <mirespace> yes
[16:59] <mirespace> it passed from time out to failed to download 
[18:54] <ahasenack> Odd_Bloke: what did you mean the other day with "artifactory doesn't support zstd compression"? Isn't it "just" storage? Does it need to open the debs?
[19:44] <ahasenack> mirespace: thanks, I retried those tests
[19:44] <ahasenack> let's see tomorrow
[20:49] <sergiodj> mirespace: ahasenack: the second retrigger of dgit (with rsync as the trigger) has passed
[20:50] <ahasenack> phew
[20:54] <mirespace> \o/
[21:06] <axsuul> Hello, I am running 30+ docker containers, orchestrated using nomad, vault, consul -- lots of processes. Sometimes during the day I will get high load for an hour or so (1m, 5m, 15m >25 @ 16 threads) but it's been hard to diagnose which processes are causing the high load. Using top, htop, etc and referencing the % CPU usage has not been helpful because they are real-time values and are very fleeting. Any suggestions on how I can help diagnose
[21:06] <axsuul>  which processes are contributing to the high load?
[21:16] <sergiodj> axsuul: I think perf could be helpful in this case
[21:18] <sergiodj> you can do some nice things with e.g. "perf top"
[21:29] <axsuul> Thanks will give that a try!
[21:33] <axsuul> sergiodj: "perf top" seems pretty low level in that it's saying which calls are taking up the most CPU. Is there anything more high level, something like this process is contributing xx amount of load
[21:34] <sarnold> did perf top not point at the largest contributors?
[21:34] <axsuul> Here's what I'm seeing, it's hard to decipher what these are https://0x0.st/oXxL.txt
[21:35] <sergiodj> axsuul: perf top will let you know that.  if you want something finer grained (over a longer period of time), you can also use "perf record" to monitor the activity on CPUs, and then "perf report" to analyse the data (beware that "perf record" will require non-trivial disk space to save its data file)
[21:35] <sarnold> heh, it's saying the measurement itself is contributing the most to cpu load
[21:36] <sdeziel> axsuul: a simple top with the list sorted by CPU time consumed would let you see which processes are burning cycles (assuming they are long lived)
[21:37] <axsuul> sdeziel: is that the same thing as sorting by %CPU?
=== Poster` is now known as Poster
[21:38] <sdeziel> axsuul: you'd need to press "shift-t" to sort by time consumed so not the same I think
[21:40] <axsuul> sdeziel: thanks, however it's hard to debug with the CPU time if many of my processes have already been running for a month or so right? It would be useful to reset the CPU time so I can see what's contributing in the short-term
[21:54] <sdeziel> axsuul: you could compare the top X TIME consumer now and in a few hours
[22:02] <axsuul> Thanks, I suppose I could graph it in grafana
=== genii is now known as genii-core