Bug #12316
hald_runner dies getting SIGPIPE
100%
Description
Perform the following actions:
1) Mount USB stick in Mate
2) umount it in CLI
If you are lucky (or unlucky) enough, hald runner dies. SMF doesn't notice this. If you run hald with --daemon=no --verbose=yes, you can see either
23:57:49.342 [I] osspec.c:213: mnttab event Run started hal-storage-cleanup-mountpoint (0) (1) ! full path is '/usr/lib/hal/hal-storage-cleanup-mountpoint', program_dir is '/usr/lib/hal' 2560: XYA attempting to get lock on /media/.hal-mtab-lock 2560: XYA got lock on /media/.hal-mtab-lock in hal-storage-cleanup-mountpoint for mount point '/media/Ubuntu 18.04.2 LTS amd64' hal_mtab = '/dev/dsk/c0t0d0p0 101 0 hsfs nosuid /media/Ubuntu 18.04.2 LTS amd64 ' line = '/dev/dsk/c0t0d0p0 101 0 hsfs nosuid /media/Ubuntu 18.04.2 LTS amd64' devfile = '/dev/dsk/c0t0d0p0' uid = '101' session id = '0' fs = 'hsfs' options = 'nosuid' mount_point = '/media/Ubuntu 18.04.2 LTS amd64' Found entry for mount point '/media/Ubuntu 18.04.2 LTS amd64' in /media/.hal-mtab2560: XYA released lock on /media/.hal-mtab-lock *** [DIE] hald_runner.c:runner_died():168 : Runner died
when you are unlucky or
23:56:24.220 [I] osspec.c:213: mnttab event Run started hal-storage-cleanup-mountpoint (0) (1) ! full path is '/usr/lib/hal/hal-storage-cleanup-mountpoint', program_dir is '/usr/lib/hal' 2494: XYA attempting to get lock on /media/.hal-mtab-lock 2494: XYA got lock on /media/.hal-mtab-lock in hal-storage-cleanup-mountpoint for mount point '/media/Ubuntu 18.04.2 LTS amd64' hal_mtab = '/dev/dsk/c0t0d0p0 101 0 hsfs nosuid /media/Ubuntu 18.04.2 LTS amd64 ' line = '/dev/dsk/c0t0d0p0 101 0 hsfs nosuid /media/Ubuntu 18.04.2 LTS amd64' devfile = '/dev/dsk/c0t0d0p0' uid = '101' session id = '0' fs = 'hsfs' options = 'nosuid' mount_point = '/media/Ubuntu 18.04.2 LTS amd64' Found entry for mount point '/media/Ubuntu 18.04.2 LTS amd64' in /media/.hal-mtab2494: XYA released lock on /media/.hal-mtab-lock pid 2494: rc=0 signaled=0: /usr/lib/hal/hal-storage-cleanup-mountpoint 23:56:24.276 [I] devinfo_storage.c:1436: Cleaned up mount point '/media/Ubuntu 18.04.2 LTS amd64'
if you are lucky.
truss shows the following pattern:
hald-runner spawns /usr/lib/hal/hal-storage-cleanup-mountpoint and writes '\n' to its stdin. If it's unlucky and hal-storage-cleanup-mountpoint has already finished its work, it gets SIGPIPE.
Updated by Alexander Pyhalov 10 months ago
The simple test case which reproduces hal behavior (with both glib 2.62.4 and glib 2.58.3). sleep() is necessary to make things more reproducible.
#include <glib.h>
#include <unistd.h>
#include <stdio.h>
int main() {
GError *error = NULL;
char *env[0];
char *argv[2];
gint *stdin_p;
gint stdin_v;
gint pid;
stdin_p= &stdin_v;
argv[0] = "/usr/bin/true";
argv[1] = NULL;
if (g_spawn_async_with_pipes("/", argv, NULL,
G_SPAWN_DO_NOT_REAP_CHILD,
NULL, NULL, &pid,
stdin_p, NULL, NULL, &error)) {
sleep(10);
// if (write(stdin_v, "", 0) != 0) // Fixed behavior
if (write(stdin_v, "\n", 1) != 1)
printf("Warning: Error while writing r->input (%s) to stdin_v.\n","\n");
close(stdin_v);
}
return 0;
}
Updated by Alexander Pyhalov 10 months ago
SIGPIPE in test case seems to be the intended behavior - it's consistent across Linux and OI
Updated by Alexander Pyhalov 10 months ago
Suggested fix: http://buildzone.oi-build.r61.net/webrev-12316/
I've tested this by running USB disk mounts/unmounts and looking at hal behavior.
After fix I see:
child (/usr/lib/hal/hal-storage-cleanup-mountpoint):
...
1864: rmdir("/media/Ubuntu 18.04.2 LTS amd64") = 0
1864: rename("/media/.hal-mtab~", "/media/.hal-mtab") = 0
1864: fcntl(3, F_SETLK, 0x08040DDC) = 0
1864: close(3) = 0
1864: getpid() = 1864 [1706]
1864: write(1, " F o u n d e n t r y ".., 130) = 130
1864: _exit(0)
parent (hald-runner):
... 1706/1: write(7, 0x084E6F50, 0) = 0 1706/1: close(7) = 0 1706/1: waitid(P_PID, 1864, 0x08039260, WEXITED|WTRAPPED|WNOHANG) = 0 1706/1: pollsys(0x084E3EA8, 2, 0x08039578, 0x00000000) = 0 1706/1: write(1, " p i d 1 8 6 4 : r c".., 71) = 71 1706/1: fstat(8, 0x080393F8) = 0 1706/1: fcntl(8, F_GETFL) = 2 1706/1: read(8, 0x084F0DD8, 1024) = 0 1706/1: close(8) = 0
Before fix this write to pipe - 1706/1: write(7,) could fail (and failed in half of cases), after fix it doesn't (being a 0-bytes write).
Updated by Electric Monk 9 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit b877e47f88a401dbef6fff48940d38855c01fcbc
commit b877e47f88a401dbef6fff48940d38855c01fcbc
Author: Alexander Pyhalov <apyhalov@gmail.com>
Date: 2020-02-21T19:01:41.000Z
12316 hald_runner dies getting SIGPIPE
Reviewed by: Toomas Soome <tsoome@me.com>
Approved by: Dan McDonald <danmcd@joyent.com>