Bug 966042 - yast command-line usage emits "unable to close filehandle properly" perl warning from ag_tty at exit
yast command-line usage emits "unable to close filehandle properly" perl warn...
Status: RESOLVED FIXED
: 989279 1051295 1080037 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
x86-64 SUSE Other
: P5 - None : Minor with 1 vote (vote)
: ---
Assigned To: Nathan Cutler
Jiri Srain
https://trello.com/c/Bof3sBP6
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-10 13:23 UTC by Ben Kelly
Modified: 2023-03-08 12:30 UTC (History)
13 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Kelly 2016-02-10 13:23:26 UTC
Specifically, it says:

Warning: unable to close filehandle properly: Bad file descriptor, <STDIN> line
        21 during global destruction (#1)
    (S io) An error occurred when Perl implicitly closed a filehandle.  This
    usually indicates your file system ran out of disk space.

This happens with (as far as I can tell, I haven't tested exhaustively) all command-line yast invokations that involve a module. So, e.g., "yast users help" or "yast sysconfig help" will produce this message. "yast help" on its own, however, won't.

It does not appear to affect yast's exit code, or it's ability to do its job; if I run "yast sysconfig set LOADER_TYPE=none", it does the right thing and then produces that message while exiting.

Despite the hint that it may be space-related, this happens on multiple computers, all of them with plenty of space available on all filesystems. These systems are all running recent (~2 weeks) versions of Tumbleweed.
Comment 1 Martin Vidner 2016-02-10 14:03:58 UTC
Confirmed with TW from 2015-10-02.

BTW this seems to be unrelated to the ncurses UI which had similar FD-closing problems in the past. The same happens also with QT or with the null UI:

/usr/lib/YaST2/bin/y2base 'sysconfig' '-S' '(help)' UI
Comment 2 Sebastian Wagner 2016-07-10 15:23:59 UTC
Still not fixed in current Tumblemweed 20160707 and Yast2 3.1.195-1.1

I get different outputs for a normal user and root:

> yast timezone help
No permissions.

YaST Configuration Module timezone
-----------------------------------

Time zone configuration

Basic Syntax:
    yast2 timezone interactive
    yast2 timezone <command> [verbose] [options]
    yast2 timezone help
    yast2 timezone longhelp
    yast2 timezone xmlhelp
    yast2 timezone <command> help

Commands:
    list     List all available time zones
    set      Set new values for time zone configuration
    summary  Time zone configuration summary

Run 'yast2 timezone <command> help' for a list of available options.

print() on unopened filehandle STDERR at /usr/lib/perl5/5.24.0/diagnostics.pm line 651, <STDIN> line 19 during global destruction.
print() on unopened filehandle STDERR at /usr/lib/perl5/5.24.0/diagnostics.pm line 653, <STDIN> line 19 during global destruction.
Invalid snapshot ''.

> sudo yast timezone help
[sudo] password for root: 

YaST Configuration Module timezone
-----------------------------------

Time zone configuration

Basic Syntax:
    yast2 timezone interactive
    yast2 timezone <command> [verbose] [options]
    yast2 timezone help
    yast2 timezone longhelp
    yast2 timezone xmlhelp
    yast2 timezone <command> help

Commands:
    list     List all available time zones
    set      Set new values for time zone configuration
    summary  Time zone configuration summary

Run 'yast2 timezone <command> help' for a list of available options.

Warning: unable to close filehandle properly: Bad file descriptor, <STDIN> line
	19 during global destruction (#1)
    (S io) There were errors during the implicit close() done on a filehandle
    when its reference count reached zero while it was still open, e.g.:
    
        {
            open my $fh, '>', $file  or die "open: '$file': $!\n";
            print $fh $data or die "print: $!";
        } # implicit close here
    
    Because various errors may only be detected by close() (e.g. buffering could
    allow the print in this example to return true even when the disk is full),
    it is dangerous to ignore its result. So when it happens implicitly, perl will
    signal errors by warning.
    
    Prior to version 5.22.0, perl ignored such errors, so the common idiom shown
    above was liable to cause silent data loss.
Comment 3 Martin Vidner 2016-09-01 09:04:19 UTC
I have run

  strace -f /usr/lib/YaST2/bin/y2base 'sysconfig' '-S' '(help)' UI

and found that the error message is produced by ag_tty. The problem can also be reproduced with

  /usr/lib/YaST2/servers_non_y2/ag_tty < /dev/null
Comment 4 Martin Vidner 2016-09-01 11:28:14 UTC
Apparently it is a consequence of this bug in Term::ReadLine::Gnu

dhcp112:~ # perl -e "use Term::ReadLine; Term::ReadLine->new('name');"
Warning: unable to close filehandle properly: Bad file descriptor during global destruction.
dhcp112:~ # PERL_RL=Gnu perl -e "use Term::ReadLine; Term::ReadLine->new('name');"
Warning: unable to close filehandle properly: Bad file descriptor during global destruction.

which is filed (without response) as https://rt.cpan.org/Public/Bug/Display.html?id=110943

The alternate implementation does not have the problem:

dhcp112:~ # PERL_RL=Perl perl -e "use Term::ReadLine; Term::ReadLine->new('name');"

Exporting PERL_RL=Perl works around the problem.
Comment 5 Ancor Gonzalez Sosa 2016-10-06 16:00:23 UTC
*** Bug 989279 has been marked as a duplicate of this bug. ***
Comment 6 Ladislav Slezák 2017-08-04 12:09:05 UTC
*** Bug 1051295 has been marked as a duplicate of this bug. ***
Comment 7 Martin Vidner 2017-08-08 11:50:55 UTC
> Exporting PERL_RL=Perl works around the problem.

... but then it actually uses the Stub implementation, because perl-Term-ReadLine-Perl is not installed, and no line editing is available.
(As noted by lslezak in https://github.com/yast/yast-yast2/pull/607 )

Fortunately, the problem is gone if I upgrade to the latest version, perl-Term-ReadLine-Gnu-1.35
http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.35/

NOTE that we have 2 versions of Term-ReadLine-Gnu, where one dash is missing in the name:

1.20: https://build.opensuse.org/package/show/devel:languages:perl/perl-TermReadLine-Gnu (is in Factory/Leap/SLE)
1.24: https://build.opensuse.org/package/show/devel:languages:perl/perl-Term-ReadLine-Gnu (is only in d:l:perl)

IMHO the proper fix is to
1) update the latter package to the latest upstream version (I have simply exchanged the tarball, changed the version in the spec file and it worked)
2) have it obsolete the former package and also drop that one
Comment 8 Nathan Cutler 2017-08-09 20:17:17 UTC
I'm technically the maintainer of perl-Term-ReadLine-Gnu (the one in d:l:perl) and I agree with Martin's suggested plan of action, but don't know when I will get time to do this. If someone else would like to jump in here, I won't mind at all.
Comment 9 Knut Alejandro Anderssen González 2018-04-26 14:23:11 UTC
*** Bug 1091069 has been marked as a duplicate of this bug. ***
Comment 10 Knut Alejandro Anderssen González 2018-04-26 14:50:21 UTC
*** Bug 1080037 has been marked as a duplicate of this bug. ***
Comment 11 Nathan Cutler 2019-02-04 12:18:08 UTC
Update:

> 1) update the latter package to the latest upstream version

Done by https://build.opensuse.org/request/show/668117

> 2) have it obsolete the former package

Done by https://build.opensuse.org/request/show/668636 and https://build.opensuse.org/request/show/668903

> 3) and also drop that one

Not sure how to proceed with the drop. Both the devel project and Factory have both packages, but the builds of the wrongly-named one are excluded/disabled in Factory:

https://build.opensuse.org/package/show/devel:languages:perl/perl-TermReadLine-Gnu
https://build.opensuse.org/package/show/devel:languages:perl/perl-Term-ReadLine-Gnu
https://build.opensuse.org/package/show/openSUSE:Factory/perl-TermReadLine-Gnu
https://build.opensuse.org/package/show/openSUSE:Factory/perl-Term-ReadLine-Gnu

@Coolo - any suggestion? (Having the wrongly-named package present at all seems confusing and undesirable.)
Comment 12 Nathan Cutler 2019-02-04 13:34:14 UTC
Wrongly-named package dropped from both devel:languages:perl and openSUSE:Factory

Thanks, Coolo, for helping!
Comment 13 Martin Vidner 2022-07-12 15:47:55 UTC
*** Bug 1201046 has been marked as a duplicate of this bug. ***
Comment 14 Maintenance Automation 2023-03-08 12:30:19 UTC
SUSE-RU-2023:0664-1: An update that contains one feature and has one recommended fix can now be installed.

Category: recommended (important)
Bug References: 966042
Jira References: PED-2616
Sources used:
openSUSE Leap 15.4 (src): perl-Term-ReadLine-Gnu-1.42-150300.7.3.1
SAP Applications Module 15-SP3 (src): perl-Term-ReadLine-Gnu-1.42-150300.7.3.1
SAP Applications Module 15-SP4 (src): perl-Term-ReadLine-Gnu-1.42-150300.7.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.