I have some doubts/questions about the specific choice of Prowl.

For the record im not stuck with this as a solution its just something i have used before

I have noticed you can tirgger this bug by using a locale not present on the server

I had a quick look at this and was unable to recreate it, i did come across the following though and wonder if the work around there may work

congratulations, ill close this ticket now

sounds good

uniqueid fact is also missing

Its also worth pointing out that ulogd supports native json output[1] but only to a separate log file not syslog. Prometheus is was simpler to keep things raw and in (r)syslog which may be the case here as well. In relation to writing our own grok rules i suspect the mtail patterns will be a good starting point[2]

I have created a series of changes starting with 503332 which adds ssacli to the raids array fact if a "Smart Storage PQI 12G SAS/PCIe 3" devices is detected. This is based on the pci-id [1].

below is a diff between facter2 and facter3. most things are the same but there are a few things which are different, of course there are many more new structured facts.

@elukey he is remaining as a volunteer so i agree this probably doesn't need an action. however im not familiar enough with HDFS/PPI stuff to know if there is a difference between the WMF and NDA groups. so thought i would raise this ticket to check. If you are confident then please close the ticket and i will know for next time :)

awight is remaining as a vluntear and has signed the NDA. I have created a subtask and tagged analytics to chgeck the dir for PPI stuff as per the off boarding doc[1]

hi adam,

@CDanis thanks i will try a patch with some of the other maps however the problem is that the std::unsorted_map is available but it has a bug in the library[1] so the bug may trigger with them as well. Further i didn't think that the performance difference would be that noticeable in facter and as its only facter on jessie the risk is even smaller

A bit more to the picture, managed to get facter to build by updating all refrence of std::unordered_map to std::map. however im now getting the following test faliures

In addition, Jenkins doesn't seem to like having more than Change-id and Bug in the footer:

we will also need to configure http proxy for the security updates

both rapidjson and catch build find using libc++ however even using theses packages we get the above error

Looks like we may need to rebuild everything with stdc++[1] already tried leatherman and get a simlar errors pointing to relating to boost, hopefully we dont need to rebuild boost

have created https://phabricator.wikimedia.org/T220003

Clang-4.0 is provided by security jessie/updates and have managed to get pbuilder working by adding the following

thanks to moritz all dependencies have been built but now getting the following error while building facter

Ok I hit another road block. leatherman depends on debhelper 11. I manully updated debian/compat and debian/control to try and build with debhelper 10 .
The first build lead to the following error

1. notes building facter3 for debian:

Is this still an issue, the openssl package is provided via jessi-wikimedia/main

once the jessie-backport repos has been remove i suggest running the following on cumin

patch is merged, let me know if there is anything elses from my side

This has been deployed to all nodes which mount HDFS.

Thanks for the response

Some comments for consideration

FYI this got fixed in pdns-recursor version 4.1.0 (its actully in 4.1.0-alpha1) via https://github.com/PowerDNS/pdns/pull/5223

didn't notice it wasn't merged :)

Was this resolved with moritz's patch. if not i came across a similar issue and created the following patch https://gerrit.wikimedia.org/r/c/operations/puppet/+/494210

I had a variant of this during clinic

@hashar i have taken another look at the patch i created yesterday and i now think it is incorrect. As far as i can tell profile::ci::package_builder which is the only class that attempts to install jenkins-debian-glue is never run on any server. profile::ci::package_builder is included in role::ci::slave::labs however

i have built this and added it to {jessie,stretch}-wikimedia in component/ci. It appears that the CI servers did not have components/ci configured so i have also created a change to add the repo to those servers. As far as i can tell this only needs to go to contint2001.wikimedia.org and contint1001.wikimedia.org, which both run Jessie. Have i missed some nodes which may also need this repo?

@kchapman can you approve this request

when monitoring the tmp dir i see many short lived tmp files and a few long long lived files. running lsof shows that the short lived files get created by hhvm (at least on mw1347). My assumption is that the long lived ones where also created by hhvm and is theses files i.e. the ones created on Mar 2 in the output below which are causing the problem, however i'm unsure where the race condition is. tmpreaper is configured to only remove files with a ctime > 7days with a 256 second splay. My best guess is that something in media wiki (or something else although i check all the other cron jobs and couldn't see anything) is also reaping theses files after 7 days. if its doing so without the 256 second splay it would account for the somewhat spasmodic nature of our alerts

i suspect this is related to T130593: investigate slapd memory leak.

Here are URLs for listinfo, admin. As mentioned the list password has already been sent to the initial list administrator's email address, we recommend they communicate the password with the secondary list administrator.

Hi Erica, As i think you have noticed the list has been created and you should have revived the admin password. I'm just holding of resolving the ticket as this is the first time i have created a list and just wanted someone else (likely @herron ) to validate my work and ensure i have not made a mistake

This should be in place now, let me know if there are any issues

sorry updated wrong ticket

This should be in place now, let me know if there are any issues

the last option excludes mount points which would work for this case. As far as i can see you can only remove directories from the output which wouldn't stop the warning from triggering

@Reedy thanks was going from https://office.wikimedia.org/wiki/Contact_list, i need authorization from bmansurov manager. Looking at https://wikimediafoundation.org/role/staff-contractors/ im guessing that would be @leila

@RStallman-legalteam did you receive a response? I don't see them in the spread sheet

@DarTar can you please authorize this request

paladox confirmed via IRC this can be closed

This list has now been removed

This is reproducible but not reliably, some file operation taking part on fuse e.g. ls -la /mnt/hdfs/tmp seem to cause lsof to fail. its is almost certainly to do with hdfs fuse stability issues. I think we could remove this noise with any of the following options