snmpd causes autofs mount points to be mounted on service start/restart

Bug #1835818 reported by Ioanna Alifieraki on 2019-07-08
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
net-snmp (Debian)
New
Unknown
net-snmp (Ubuntu)
Medium
Ioanna Alifieraki
Xenial
Medium
Ioanna Alifieraki
Bionic
Medium
Ioanna Alifieraki
Cosmic
Medium
Ioanna Alifieraki
Disco
Medium
Ioanna Alifieraki
Eoan
Medium
Ioanna Alifieraki

Bug Description

[Impact]

Autofs direct map triggers are visible in /etc/mtab.
On boot, when snmpd starts, it iterates over the entries in /etc/mtab and performs statfs() on them.
This trigger automount to mount autofs mounts even if the user does not explicitly access them.

However this happens only if autofs service is started before snmpd.
If snmpd stars first /etc/mtab is not yet populated with autofs mounts and therefore
are not mounted.

When there a few autofs mount points the impact is insignificant.
However when there are thousands of them, this causes unnecessary overhead on operations
such as df.
This also delays the system shutdown time since everything needs to be unmounted.

[Test Case]

*** Test Case 1 - During boot:

The user that brought this issue to our attention would observe all autofs mounts
be mounted at boot, because in their environment autofs would start first.

In my environment snmpd starts first so to reproduce I had to add a small delay in
snmpd init script.

In /etc/init.d/snmp :
@@ -36,6 +36,8 @@ cd /

 case "$1" in
   start)
+ # Delay snmp start
+ sleep 2
     log_daemon_msg "Starting SNMP services:"
     # remove old symlink with previous version
     if [ -L /var/run/agentx ]; then

$cat /etc/auto.master
/- /etc/auto.nfs --timeout=30

$cat /etc/auto.nfs
/home/test1 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp <NFS server IP>:/srv/export/test1
/home/test2 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp <NFS server IP>:/srv/export/test2

Reboot vm, syslog entries :

# Autofs starts
Jul 11 11:04:16 xenial-vm3 autofs[1295]: * Starting automount...
Jul 11 11:04:16 xenial-vm3 automount[1357]: Starting automounter version 5.1.1, master map /etc/auto.master
Jul 11 11:04:16 xenial-vm3 automount[1357]: using kernel protocol version 5.02
# Mount triggers, now visible in mtab
Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test1 with timeout 300, freq 75 seconds
Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test2 with timeout 300, freq 75 seconds
Jul 11 11:04:16 xenial-vm3 autofs[1295]: ...done.
...
# SNMP starts
Jul 11 11:04:18 xenial-vm3 snmpd[1294]: * Starting SNMP services:
Jul 11 11:04:18 xenial-vm3 systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1394 (snmpd)
Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounting Arbitrary Executable File Formats File System...
Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounted Arbitrary Executable File Formats File System.
Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry /home/test1 <==========
Jul 11 11:04:18 xenial-vm3 kernel: [ 8.880685] FS-Cache: Loaded
Jul 11 11:04:18 xenial-vm3 kernel: [ 8.889318] FS-Cache: Netfs 'nfs' registered for caching
Jul 11 11:04:18 xenial-vm3 kernel: [ 8.902672] NFS: Registering the id_resolver key type
Jul 11 11:04:18 xenial-vm3 kernel: [ 8.902680] Key type id_resolver registered
Jul 11 11:04:18 xenial-vm3 kernel: [ 8.902682] Key type id_legacy registered
Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test1 <==========
Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry /home/test2 <==========
Jul 11 11:04:18 xenial-vm3 kernel: [ 9.163011] random: nonblocking pool is initialized
Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test2 <===========

*** Test Case 2 - Restart snmpd :

To reproduce this case, autofs mounts should not be mounted to begin with.
(restart autofs or let it expire)

#systemctl restart snmpd.service

Syslog entries :

Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopping LSB: SNMP agents...
Jul 11 11:15:40 xenial-vm3 snmpd[1668]: * Stopping SNMP services:
Jul 11 11:15:40 xenial-vm3 snmpd[1434]: Received TERM or STOP signal... shutting down...
Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopped LSB: SNMP agents.
Jul 11 11:15:40 xenial-vm3 systemd[1]: Starting LSB: SNMP agents...
Jul 11 11:15:42 xenial-vm3 snmpd[1677]: * Starting SNMP services:
Jul 11 11:15:42 xenial-vm3 automount[1357]: attempting to mount entry /home/test1 <===========
Jul 11 11:15:42 xenial-vm3 automount[1357]: mounted /home/test1 <===========
Jul 11 11:15:42 xenial-vm3 automount[1357]: attempting to mount entry /home/test2 <===========
Jul 11 11:15:42 xenial-vm3 automount[1357]: mounted /home/test2 <===========
Jul 11 11:15:42 xenial-vm3 snmpd[1684]: /etc/snmp/snmpd.conf: line 145: Warning: Unknown token: defaultMonitors.
Jul 11 11:15:42 xenial-vm3 snmpd[1684]: /etc/snmp/snmpd.conf: line 147: Warning: Unknown token: linkUpDownNotifications.
Jul 11 11:15:42 xenial-vm3 snmpd[1684]: Turning on AgentX master support.
Jul 11 11:15:42 xenial-vm3 systemd[1]: Started LSB: SNMP agents.
Jul 11 11:15:42 xenial-vm3 snmpd[1708]: NET-SNMP version 5.7.3

[Regression Potential]

The regression potential of these patch is low.
The patch essentially adds support for autofs mounts in order to detect them and treat them separately when calling stafs; autofs entries are skipped to prevent them from being mounting every time snmpd is restarted.
Therefore, any regression that may be caused by this patch will be autofs related.

[Other]

Upstream bug : https://sourceforge.net/p/net-snmp/bugs/2968/
Upstream patches :
https://sourceforge.net/p/net-snmp/patches/1350/
https://sourceforge.net/p/net-snmp/code/ci/a0df31c18c513a0d79f4d526b1af7fad48748e57/

Debian Bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935325

Andreas Hasenack (ahasenack) wrote :

Hi Ioanna,

please elaborate a bit more as soon as you can :)

description: updated
tags: added: sts
Changed in net-snmp (Ubuntu Xenial):
assignee: nobody → Ioanna Alifieraki (joalif)
Changed in net-snmp (Ubuntu Bionic):
assignee: nobody → Ioanna Alifieraki (joalif)
Changed in net-snmp (Ubuntu Cosmic):
assignee: nobody → Ioanna Alifieraki (joalif)
Changed in net-snmp (Ubuntu Disco):
assignee: nobody → Ioanna Alifieraki (joalif)
Changed in net-snmp (Ubuntu Eoan):
assignee: nobody → Ioanna Alifieraki (joalif)
Changed in net-snmp (Ubuntu Xenial):
status: New → In Progress
Changed in net-snmp (Ubuntu Bionic):
status: New → In Progress
Changed in net-snmp (Ubuntu Cosmic):
status: New → In Progress
Changed in net-snmp (Ubuntu Disco):
status: New → In Progress
Changed in net-snmp (Ubuntu Eoan):
status: New → In Progress
Changed in net-snmp (Ubuntu Xenial):
importance: Undecided → Medium
Changed in net-snmp (Ubuntu Bionic):
importance: Undecided → Medium
Changed in net-snmp (Ubuntu Disco):
importance: Undecided → Medium
Changed in net-snmp (Ubuntu Cosmic):
importance: Undecided → Medium
Changed in net-snmp (Ubuntu Eoan):
importance: Undecided → Medium
summary: - snmpd causes autofs mount points to be mounted on system start-up
+ snmpd causes autofs mount points to be mounted on service start/restart
Eric Desrochers (slashd) on 2019-07-31
Changed in net-snmp (Ubuntu Cosmic):
status: In Progress → Won't Fix
Ioanna Alifieraki (joalif) wrote :

Debdiff for Eoan.

Ioanna Alifieraki (joalif) wrote :

Debdiff for Disco.

Ioanna Alifieraki (joalif) wrote :

Debdiff for Bionic.

Ioanna Alifieraki (joalif) wrote :

Debdiff for Xenial.

The attachment "lp1835818_eoan.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Thomas Ward (teward) wrote :

After discussion with slashd from the STS Sponsors team, I am unsubscribing this from Sponsors as STS Sponsors will handle this, and it does not need to be handled by the standard sponsors team.

description: updated
description: updated
Dan Streetman (ddstreet) on 2019-08-21
tags: added: sts-sponsor sts-sponsor-ddstreet
Dan Streetman (ddstreet) wrote :

sponsored for e,d,b,x

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-5ubuntu3

---------------
net-snmp (5.7.3+dfsg-5ubuntu3) eoan; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmpd startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Ioanna Alifieraki <email address hidden> Wed, 21 Aug 2019 12:22:37 +0100

Changed in net-snmp (Ubuntu Eoan):
status: In Progress → Fix Released
Eric Desrochers (slashd) on 2019-08-29
tags: removed: sts-sponsor sts-sponsor-ddstreet
Łukasz Zemczak (sil2100) wrote :

I am not a user of net-snmp so it's hard for me to get a proper feeling for this, but I might be slightly worried that fixing this 'bug' would cause a behavior change (regression) for some users that actually now expect their autofs mount points to be mounted by snmpd. Especially that, seeing from the targeted series, it was like this since xenial and this is the first time it was actually mentioned.

I think I would first like to consult this with the ubuntu-server team regarding how invasive this change actually is. Maybe it's not such a big of a deal, but I always try to stop and check whenever a behavior change is being proposed for an SRU.

Łukasz Zemczak (sil2100) wrote :

@ahasenack @racb ^ what do you guys think?

Dan Streetman (ddstreet) wrote :

> fixing this 'bug' would cause a behavior change (regression) for some users that
> actually now expect their autofs mount points to be mounted by snmpd

I'm not an autofs expert, but my understanding is that autofs "automatically" mounts configured directories, on access. So, assuming that net-snmp was previously accessing a user's autofs mounts at bootup, causing them to be mounted, those directories would now not be mounted at boot time, but would still be mounted by autofs when the user actually accessed them, at any point during runtime.

So, the user-visible change would only be:

before: autofs mounts are mounted at boot time, adding some delay to boot
after: autofs mounts are mounted at runtime on directory access, adding some delay to initial access of an autofs directory

This should not introduce any error for users when accessing their autofs mounts (although, if there is some problem actually mounting an autofs mount, that error would be *moved* from boot-time to runtime initial access).

Additionally, autofs mounts have timeouts which un-mount them, so in the long run of any particular system, this is a no-op.

As the design of autofs is demand-based mounting, having them all mounted at boot time makes autofs somewhat pointless, AFAICT; the system admin should just make them normal mounts if that's what is desired.

Dan Streetman (ddstreet) wrote :

Also please note that previous behavior was not guaranteed to mount all autofs mounts, as Jo stated in the description:

"The user that brought this issue to our attention would observe all autofs mounts
be mounted at boot, because in their environment autofs would start first.

In my environment snmpd starts first so to reproduce I had to add a small delay in
snmpd init script."

So previous/current behavior is a race condition between autofs and snmpd starting; only if autofs starts before snmpd, will snmpd cause all autofs mounts to be mounted.

Łukasz Zemczak (sil2100) wrote :

Thanks Dan! What you say does make sense indeed. Thinking about it again, relying on autofs filesystems to be already mounted on boot is invalid behavior by principle, so it is not something we should care about. Let me re-review and accept the upload.

Changed in net-snmp (Ubuntu Disco):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-disco

Hello Ioanna, or anyone else affected,

Accepted net-snmp into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-5ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Łukasz Zemczak (sil2100) wrote :

Hello Ioanna, or anyone else affected,

Accepted net-snmp into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-1.8ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Łukasz Zemczak (sil2100) wrote :

Hello Ioanna, or anyone else affected,

Accepted net-snmp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-1ubuntu4.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Debian):
status: Unknown → New

All autopkgtests for the newly accepted net-snmp (5.7.3+dfsg-1.8ubuntu3.2) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

nut/2.7.4-5.1ubuntu2 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#net-snmp

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Chris Newcomer (cnewcomer) wrote :

Validation:
I can confirm the fix for these is working on xenial, bionic, and disco. I will include typescript outputs of each Ubuntu version.

Chris Newcomer (cnewcomer) wrote :
Chris Newcomer (cnewcomer) wrote :
Eric Desrochers (slashd) on 2019-09-03
tags: added: verification-done-bionic verification-done-disco verification-done-xenial
removed: verification-needed-bionic verification-needed-disco verification-needed-xenial
Bryce Harrington (bryce) wrote :

Comment #18 references an autopkgtest regression for nut, but looking at the link shows:

"Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
...
autopkgtest for nut/2.7.4-5.1ubuntu2: amd64: Pass, arm64: Pass, armhf: Always failed, i386: Pass, ppc64el: Pass, s390x: Pass
"

Going to guess that it's blocked rather than regressed, and since all the verification tasks are done, marking this verification-done, for further processing.

tags: added: verification-done
removed: verification-needed
Łukasz Zemczak (sil2100) wrote :

@bryce For the record: the nut/2.7.4-5.1ubuntu2 ppc64el test failed as per the SRU ADT regression report in comment #18, but it passed after a re-run triggered by Eric. So the report was correct, but when you checked the test has already been re-ran [1]. The 'Not touching package due to block request by freeze' comment is always present for packages in the stable series - this basically means that it will not migrate to -updates automatically, as that only happens for the devel series.

[1] http://autopkgtest.ubuntu.com/packages/n/nut/bionic/ppc64el

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-5ubuntu1.1

---------------
net-snmp (5.7.3+dfsg-5ubuntu1.1) disco; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmp startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Ioanna Alifieraki <email address hidden> Wed, 21 Aug 2019 11:46:06 +0000

Changed in net-snmp (Ubuntu Disco):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for net-snmp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-1.8ubuntu3.2

---------------
net-snmp (5.7.3+dfsg-1.8ubuntu3.2) bionic; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmpd startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Ioanna Alifieraki <email address hidden> Wed, 21 Aug 2019 12:55:14 +0100

Changed in net-snmp (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-1ubuntu4.3

---------------
net-snmp (5.7.3+dfsg-1ubuntu4.3) xenial; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmpd startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Ioanna Alifieraki <email address hidden> Wed, 21 Aug 2019 13:01:38 +0100

Changed in net-snmp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Ludwig Ruderstaller (lr-u) wrote :

since releasing this patch 1.3.6.1.2.1.25.2.3.1.5 is empty. This was working befor, and does still on ubuntu 16.04 hosts.

Eric Desrochers (slashd) wrote :

Please follow the regression bug: https://launchpad.net/bugs/1843036

The problem has been identified and fixes uploaded in X/B/D.
It is now waiting for SRU team approval.

Regards,
Eric

Hello Ioanna, or anyone else affected,

Accepted net-snmp into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-5ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Ubuntu Disco):
status: Fix Released → Fix Committed
tags: added: verification-needed verification-needed-disco
removed: verification-done verification-done-disco
Łukasz Zemczak (sil2100) wrote :

Hello Ioanna, or anyone else affected,

Accepted net-snmp into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-1.8ubuntu3.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Ubuntu Bionic):
status: Fix Released → Fix Committed
tags: added: verification-needed-bionic
removed: verification-done-bionic
Łukasz Zemczak (sil2100) wrote :

Hello Ioanna, or anyone else affected,

Accepted net-snmp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/net-snmp/5.7.3+dfsg-1ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in net-snmp (Ubuntu Xenial):
status: Fix Released → Fix Committed
tags: added: verification-needed-xenial
removed: verification-done-xenial
Eric Desrochers (slashd) wrote :

Chris who did the verification[0] before we notice the regression have kindly re-tested the new packages found in -proposed for D/B/X (the ones including the regression fix) and everything look good with regard to this particular bug.

[0] First verification:
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1835818/comments/19
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1835818/comments/20
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1835818/comments/21

"
 I just finished the testing to confirm it fixes both issues.
"

tags: added: verification-done-bionic verification-done-disco verification-done-xenial
removed: verification-needed-bionic verification-needed-disco verification-needed-xenial
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-5ubuntu1.2

---------------
net-snmp (5.7.3+dfsg-5ubuntu1.2) disco; urgency=medium

  * d/p/put-paranthesis-around-macros-which-are-expressions.patch:
    - put paranthesis around macros which are expressions.
    (LP: #1843036)

  * d/p/fix-check-hr-filesys-autofs.patch:
    - On Linux getmntent() is available but getfsstat() not.
      Hence remove #if HAVE_GETFSSTAT from around the HRFS_type
      check.

net-snmp (5.7.3+dfsg-5ubuntu1.1) disco; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmp startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Eric Desrochers <email address hidden> Fri, 06 Sep 2019 23:44:49 +0000

Changed in net-snmp (Ubuntu Disco):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-1.8ubuntu3.3

---------------
net-snmp (5.7.3+dfsg-1.8ubuntu3.3) bionic; urgency=medium

  * d/p/put-paranthesis-around-macros-which-are-expressions.patch:
    - put paranthesis around macros which are expressions.
    (LP: #1843036)

  * d/p/fix-check-hr-filesys-autofs.patch:
    - On Linux getmntent() is available but getfsstat() not.
      Hence remove #if HAVE_GETFSSTAT from around the HRFS_type
      check.

net-snmp (5.7.3+dfsg-1.8ubuntu3.2) bionic; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmpd startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Eric Desrochers <email address hidden> Fri, 06 Sep 2019 23:59:19 +0000

Changed in net-snmp (Ubuntu Bionic):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package net-snmp - 5.7.3+dfsg-1ubuntu4.4

---------------
net-snmp (5.7.3+dfsg-1ubuntu4.4) xenial; urgency=medium

  * d/p/put-paranthesis-around-macros-which-are-expressions.patch:
    - put paranthesis around macros which are expressions.
    (LP: #1843036)

  * d/p/fix-check-hr-filesys-autofs.patch:
    - On Linux getmntent() is available but getfsstat() not.
      Hence remove #if HAVE_GETFSSTAT from around the HRFS_type
      check.

net-snmp (5.7.3+dfsg-1ubuntu4.3) xenial; urgency=medium

  * Skip autofs entries when calling statfs to prevent autofs being mounted on
    snmpd startup (LP: #1835818):
    - d/p/autofs-skip-autofs-entries.patch
    - d/p/autofs-fix-a-recently-introduced-bug.patch

 -- Eric Desrochers <email address hidden> Sat, 07 Sep 2019 00:07:32 +0000

Changed in net-snmp (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.