[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-27 Thread Bernhard Voelker
Update of bug #64442 (group findutils): Open/Closed:Open => Closed Fixed Release:None => 4.10.0 ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-19 Thread James Youngman
Update of bug #64442 (group findutils): Status:None => Fixed ___ Follow-up Comment #13: Fixed in git. Patch attached. (file #56067)

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-19 Thread James Youngman
Additional Item Attachment, bug #64442 (group findutils): File name: 0002-doc-Mention-the-changes-to-xargs-P.patch Size: 3KiB AGPL NOTICE These attachments are served by Savane. You can

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-19 Thread James Youngman
Documentation update for the above change. On Sun, May 19, 2024 at 11:18 AM James Youngman wrote: > This patch addresses the POSIX compliance aspect explained by Geoff > Clare. A test is included. > > > From 9fed05088f5bfe5d7d7b5e92ae301517e84760f8 Mon Sep 17 00:00:00 2001 From: James

Re: [bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-19 Thread James Youngman
This patch addresses the POSIX compliance aspect explained by Geoff Clare. A test is included. From b560e3f911c1eb0095a2c07a461bc28f7335fbd1 Mon Sep 17 00:00:00 2001 From: James Youngman Date: Sun, 19 May 2024 11:05:38 +0100 Subject: [PATCH] [xargs] POSIX requires SIGUSR1/2 to be fatal if not

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-19 Thread James Youngman
Follow-up Comment #12, bug #64442 (group findutils): I attach patch which deals with the POSIX compliance aspect explained by Geoff. (file #56065) ___ Additional Item Attachment: File name:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2024-05-18 Thread James Youngman
Update of bug #64442 (group findutils): Assigned to:None => jay ___ Reply to this item at: ___

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #11, bug #64442 (project findutils): It is probably more reasonable to test with USR2 as pkill will signal any xargs running on the system. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #10, bug #64442 (project findutils): An automated test for this issue can be done with sleep 0.2 && pkill -USR1 xargs & { sleep 0.5 && echo success; } | xargs ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #9, bug #64442 (project findutils): I decided to strace xargs on my phone and curiously read() is interrupted there as well but does not cause any problems. (file #54945) ___ Additional Item Attachment: File name:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #8, bug #64442 (project findutils): I retract my previous statement the patch works, I just accidentaly ran system xargs instead of the locally built one. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #7, bug #64442 (project findutils): After testing further I found that SA_RESTART only fixes the case of waiting on read. I managed to trigger _xargs: error closing file_ by running this c=1; while true; do printf '%s\n' "$c"; c=$((c+1)); done | xargs and sending USR1 to

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #6, bug #64442 (project findutils): Setting _sa_flags_ to SA_RESTART fixes this. (file #54944) ___ Additional Item Attachment: File name: sa_flags.diff Size:0 KB

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #5, bug #64442 (project findutils): >From sigaction(3p) ... The _sa_flags_ field can be used to modify the behavior of the specified signal. ... SA_RESTART This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to *[EINTR]*.

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #4, bug #64442 (project findutils): Here is a diff between a normal xargs execution and one interrupted with SIGUSR1. Normal execution is just running xargs and entering ^D. --- strace-normal.txt 2023-07-19 14:31:18.639157032 +0300 +++ strace-usr1.txt 2023-07-19

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread raf
Follow-up Comment #3, bug #64442 (project findutils): I had a quick look at the code, and the signal handler for SIGUSR1/SIGUSR2 is always setup without regard to whether or not the -P option was used. I couldn't see why those signals would terminate xargs (but it did when I tested it on macos

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread Geoff Clare
Follow-up Comment #2, bug #64442 (project findutils): When fixing this, please also consider changing xargs to make it conform to POSIX as regards signal handling. POSIX does not allow xargs to handle SIGUSR1 and SIGUSR2 differently from other signals. I.e. if they are inherited as ignored they

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-18 Thread anonymous
Follow-up Comment #1, bug #64442 (project findutils): I got same behaviour after building from findutils-4.9.0.tar.xz and master branch commit 81bcf2b9b39a107a5417867edeb7d65c731a1720 ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-18 Thread anonymous
URL: Summary: xargs closes stdin on receiving SIGUSR1 or SIGUSR2 Group: findutils Submitter: None Submitted: Tue 18 Jul 2023 02:52:32 PM UTC Category: xargs