applet.py crashed with IOError in module>()

Thanks for your report. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try to reproduce with latest version of system-config-printer?

Thank you,

Iulian

I can confirm. Extra information, including the automatic info added by apport, in this bug which I have marked as duplicate:
https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/194516

alexrudd, bug #194516 is marked as private automatically by apport which prevents other people from viewing it (Not allowed here: Sorry, you don't have permission to access this page). If it doesn't contain sensitive information please mark it as public or otherwise subscribe the Ubuntu Printing Team (ubuntu-printing).

Confirmed with 0.7.81+svn1976-0ubuntu2

today with hardy and I haven't gnome with all feature running

2008-04-10

I've seen this failure a few times on new updates of Hardy for the past week(?) or
so.

If it helps at all, the local printer and other hosts are generally powered off when
I boot this system.

The failure seems to happen more or less spontaneously, shortly after I login
to gnome.

Here's the data from /var/crash/_usr_share_system-config-printer_applet.py.1000.crash

Absolutely the same problem here.

I'm seeing this on Intrepid as well, with the same backtrace

What did you exactly do to reproduce this crash?

Tim, can you have a look into this?

Seems clear to me what the problem is: it's trying to write to stdout but there's no file descriptor for it. Seems like an environment bug to me.

In my case, it was during login. At the time, I was having trouble with gnome-session crashing (bug 257250), so it's possible that its stdout disappeared while it was running. At any rate, it probably shouldn't crash if it can't write to stdout.

I have not seen a recurrence of this fault (unlike the 972 other gnome-related faults I've hit
in Intrepid), but here are a few notes:

- the other two Ubuntu boxes are running Hardy, of some flavor.

- the printer is on a USB connect on one of the other boxes. It MAY have
  been connected locally to the failing box via parallel port for the above failure.

- Like the comment above, my printers are generally kept powered off until
  needed.

When I look through the /usr/share/system-config-printer/applet.py file PROGRAM_NAME is only used for error messages going to stderr. Perhaps applet.py has no possibility to send anything to stderr.

Tim, can you change the error output that it goes to syslog (like in hal-cups-utils) or that the availability of stderr is checked and then decided whether error messages should go to stderr or syslog?

Anyone has an idea on how we should fix this problem? Can it perhaps also be a problem of th XDG stuff or the GNOME desktop?

No, stderr output should be sent to .xsession-errors as with other applications in the session.

On Tue, Aug 12, 2008 at 10:10:32PM -0000, Tim Waugh wrote:
> No, stderr output should be sent to .xsession-errors as with other
> applications in the session.

In our default session in Ubuntu, stdout and stderr are a pipe to gdm, which
buffers the data over to .xsession-errors. In this case, gdm had likely
closed the pipe as the session was over, but this applet was still running
and tried to write to it.

Definitely a case of an error condition which could be handled more
gracefully, rather than a functional bug.

--
 - mdz

I'm sorry I don't have more info but I just experienced this in Intrepid after a reboot. I just logged in and the program crashed.

> I'm sorry I don't have more info but I just experienced this in Intrepid after a reboot. I just logged in and the program
> crashed.

Same to me. Logged in and suddenly it crashed.

It affects Jaunty too (applet.py crashed during login).

happened on login in jaunty

Likewise on jaunty - entered a report and tagged it as dupe. (has logs etc)

just a bit after the login in jaunty

"a bit after the login" because the crash is not happened during login? happen during the last session?
When anyone using Jaunty not a bad idea to reset gnome settings. (delete the files under /home/username/.gconf /home/username/.gnome2 ...)

I just hit this bug with jaunty feb 23rd bits.

I had just installed the lm_sensors thing on ubuntu, and I had also installed the GNOME applet in sensors-applet package. After the reboot, then this bug happened. I've never had a printer attached or installed or anything on this machine.

crashed once after doing setup of git-compiz.

works like a charm after i rebooted.

Crashed while downloading (not yet installing) Enlightenment 17. No big deal! I questioned whether or not to even report this!

At this point I just consider it an Alpha thing!

happened on login for me.

Happened for me in Jaunty

 2.6.28-8-generic #26-Ubuntu SMP Wed Feb 25 04:28:54 UTC 2009 i686 GNU/Linux

This bug was fixed in the package system-config-printer - 1.1.3+git20090218-0ubuntu5

---------------
system-config-printer (1.1.3+git20090218-0ubuntu5) jaunty; urgency=low

  * debian/patches/01_delay_autostart.patch: Redirect stdout of the system
    tray applet to /dev/null, as otherwise it comes to crashes (LP: #153610).

  * debian/patches/30_new-printer-unboundlocalerror.patch: Upstream fix
    for crash when adding new printer (LP: #333727).

 -- Till Kamppeter <email address hidden> Mon, 9 Mar 2009 10:10:47 +0100

still happened on me after login

still happens on Jaunty.

Package: system-config-printer-gnome 1.1.3+git20090218-0ubuntu7

Moved status to new, as this is still occurring for me and other Jaunty testers.

This bug was fixed in the package system-config-printer - 1.1.3+git20090218-0ubuntu8

---------------
system-config-printer (1.1.3+git20090218-0ubuntu8) jaunty; urgency=low

  * debian/patches/01_delay_autostart.patch: Redirect also stderr of the system
    tray applet to /dev/null, as a second approach to fix LP: #153610.

  * debian/patches/40_ppds-py-improved-printer-identification.patch: Upstream
    patch to improve identification of printers, especially for the situation
    of incomplete device IDs reported for network printers. Also made the list
    of printer models more readable for PPDs of HPLIP 3.9.2 and of Turboprint.

  * debian/patches/43_do-not-show-firewall-dialog.patch: Do not pop up the
    dialog to remember to deactivate the firewall when activating printer
    sharing. The dialog is Red Hat/Fedora-specific (LP: #274179).

 -- Till Kamppeter <email address hidden> Tue, 17 Mar 2009 09:52:47 +0100