... > >> ################## >> ### slurm-llnl ### >> ################## >> >> mysql-8.0 (8.0.18-0ubuntu3 to 8.0.18-0ubuntu4) in proposed for 4 days >> Regressions >> slurm-llnl/19.05.3.2-2: s390x (log, history) >> >> freeipmi (1.6.3-1.1ubuntu2 to 1.6.4-3ubuntu1) in proposed for 0 days >> Regressions >> slurm-llnl/19.05.3.2-2: s390x (log, history) >> >> * slurm-llnl >> - The gtk+ runs pass, but not the ones with freeipmi or mysql >> >> * Possible fix: Maybe trigger a run with the new versions of both >> mysql-8.0 and freeipmi together? >> > > I've had some people that wanted slurm to be ok - not on s390x but anyway. > Since I also have easy s390x access I'll take a look into these. >
Freeipmi was already fixed by a "blunt" retry and it was affected by exactly the same issue - so it seems to be a flaky test after all. On the failing cases package install was fine, but later some node didn't come up. I was recreating that in s390x containers but at first it worked. Then I found the generally suspicious: 69 # slurmdbd needs a little time to initialize its db 70 sleep 5 That always seems like a door to errors, what needs 5 seconds might on a day with heavy I/O on shared storage be 10 and 2 on another. I was lowering the sleep to see if this really would trigger the same symptoms, but it didn't always do so. Actually, this is a warning but the later output confirms it was working fine: 4 true test slurmtest 1 COMPLETED 0:0 I have proposed a fix to Debian based on that insight => https://salsa.debian.org/hpc-team/slurm-wlm/merge_requests/4 Lets see how that turns out.
-- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
