On Fri, 12 Jun 2020, at 09:38, intrigeri wrote: > > Some stracing uncovered that it was trying to read the following > > directories: > > > > /opt/puppetlabs/facter/facts.d > > /etc/facter/facts.d > > /etc/puppetlabs/facter/facts.d > > > > through trial and Aborted errors I've created those and now it works again. > > I confirm this workaround fixes the problem for me as well. > Thanks for figuring it out and sharing this workaround :) > Ha, no worries, glad you discovered this so quickly then!
For others who run into this, let's reduce the above into a oneliner: mkdir -p /opt/puppetlabs/facter/facts.d /etc/facter/facts.d /etc/puppetlabs/facter/facts.d I just realised that indeed my other testing box had this problem and again it was resolved by creating these directories. Logs show that puppet on this box disappeared on the 7th. (I separately have a cronjob that restarts puppet daily due to memory leaks (maybe long gone, the cronjob is years old), helping early discovery of this issue) dpkg.log doesn't show any ruby or puppet packages being touched then but I do see some libboost libraries, I believe at least some of these are (indirect) puppet dependencies? `//
