SNMP Upgrade ... Possible Bug? [USN-685-1]

Bug #305002 reported by Luke J Militello
2
Affects Status Importance Assigned to Milestone
net-snmp (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: snmpd

[USN-685-1] -- Gutsy (7.10) -- 5.3.1-6ubuntu2.2_sparc.deb

On Gutsy (7.10), it appears the upgrade takes and snmpd and snmptrapd startup fine, however the post install get stuck and goes zombie...

root 18719 4061 0 18:39 ? 00:00:00 \_ sshd: lmilitello [priv]
1000 18738 18719 0 18:39 ? 00:00:00 | \_ sshd: lmilitello@pts/0
1000 18739 18738 0 18:39 pts/0 00:00:00 | \_ -bash
root 21983 18739 35 19:14 pts/0 00:00:04 | \_ apt-get upgrade
root 21987 21983 2 19:14 pts/1 00:00:00 | \_ /usr/bin/dpkg --status-fd 29 --configure snmpd
root 21988 21987 19 19:14 pts/1 00:00:00 | \_ /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/snmpd.postinst configure 5.3.1-6ubuntu2.1
root 22000 21988 0 19:14 pts/1 00:00:00 | \_ [snmpd.postinst] <defunct> t>

I have yet to try this on my Hardy (8.04) and Intrepid (8.10) boxes.

Revision history for this message
Luke J Militello (kilahurtz) wrote :

I've completely removed the package and then reinstalled it and got the same result. I can confirm the package actually installs, starts up, and functions properly. My kernel version is: 2.6.22-16-sparc64-smp

Revision history for this message
Luke J Militello (kilahurtz) wrote :

This may either be an issue specific to my system with 'update-rc.d' and/or 'invoke-rc.d' or to Gutsy in general. I am unable to test further but I have crafted a workaround...

After the process goes defunct, Ctrl-C to kill it. Then edit '/var/lib/dpkg/info/snmpd.postinst' (after backing up your original of course) and make the following changes...

[XXXXXXXX]# diff snmpd.postinst.bak snmpd.postinst
19,26c19,26
< if [ -x "/etc/init.d/snmpd" ]; then
< update-rc.d snmpd multiuser >/dev/null
< if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
< invoke-rc.d snmpd start || exit $?
< else
< /etc/init.d/snmpd start || exit $?
< fi
< fi
---
> #if [ -x "/etc/init.d/snmpd" ]; then
> # update-rc.d snmpd multiuser >/dev/null
> # if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
> # invoke-rc.d snmpd start || exit $?
> # else
> # /etc/init.d/snmpd start || exit $?
> # fi
> #fi

Now, stop snmpd (if it is running)...

[XXXXXXXX]# sudo /etc/init.d/snmpd stop

Run your updates...

[XXXXXXXX]# sudo apt-get update
[XXXXXXXX]# sudo apt-get upgrade

All should go as planned and snmpd should now complete (as far as apt is concerned). Now just start snmpd manually...

[XXXXXXXX]# sudo /etc/init.d/snmpd start

This is the only time you have to do this as snmpd will start at boot time no problems. The issue here was the script making the choice on how to start it. The command 'invoke-rc.d' was returning 'exit 103' instead of 'exit 1', so this workaround opts not to use it.

As I said before, this could be a problem specific to my system or to Gutsy in general as I cannot replicate this problem in Hardy or Intrepid.

Revision history for this message
Luke J Militello (kilahurtz) wrote :

I am marking this bug as completed since Gutsy (7.10) goes EoL in 5 months. This server will be getting replaced with a new which will have Hardy (8.04) LTS.

Changed in net-snmp:
status: New → Fix Committed
Revision history for this message
Chuck Short (zulcss) wrote :

Gutsy is EoL. Sorry.

Regards
chuck

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

Other bug subscribers

Remote bug watches

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