** Also affects: maas (Ubuntu)
Importance: Undecided
Status: New
** Also affects: maas (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tested pacemaker 1.1.10+git20130802-1ubuntu2.4+sf160627v20180123.4 from
xtrusia PPA. RSS was observed to increase slowly over time (less than
20KB/hr), and the other memory metrics[0] I gathered did not increase at
all; whereas, prior to the patch, all memory metrics were increasing and
more
Ran 3.5 version for Trusty, Xenial, and Artful. No problems appear to
have been introduced by this version.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1734983
Title:
Request to backport
tested nagios-nrpe-server
2.15-1ubuntu3 on yakkety
2.15-1ubuntu1.1 on xenial
Both tests yielded same result as described in comment #18, i.e.
positive, as intended.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Tested 3.0.1-3ubuntu0.17.04.1 on zesty with positive result.
nrpe.cfg:dont_blame_nrpe=0 [ is set this way as part of install - no
editing done ]
In syslog:
May 4 21:36:18 cmonb nrpe[6381]: Error: Request contained command arguments,
but argument option is not enabled!
May 4 21:36:18 cmonb
Excerpts from mynrpe-server's /var/log/syslog when running check_nrpe
from mynagios-master (nrpe.cfg debug=1):
Before install of xenial recompiled package:
ubuntu@mynagios-master:~$ sudo -unagios /usr/lib/nagios/plugins/check_nrpe -H
192.168.1.12 -p 5664 -c check_procs -a rsyslogd 1 0
>From reading the Debian bug #756479 cited above, it appears there was
considerable impact to users whose Nagios monitors depended on this
feature when upgraded to 2.15. Some users of NRPE are customers of
Canonical's, one of whom I support as a Dedicated Support Engineer.
This customer would
curtin 0.1.0~bzr425-0ubuntu was installed out of xenial-updates and the
non-default MTU does indeed get into /e/n/i.
>From a deployed node's /e/n/i:
auto ens7f0
iface ens7f0 inet manual
bond-xmit_hash_policy encap3+4
bond-mode 802.3ad
bond-master bond2
mtu 9202
bond-lacp_rate
ddstreet's ppa included a hotfix for this which was installed on Cust
lab MAAS region controller. A machine was deployed which included a
subnet defined with MTU 9202 and two NICs in a bond. After deployment,
the bond showed MTU 9202 (used ifconfig), and the /e/n/interfaces file
was coded in a
