Project

General

Profile

Bug #12316

hald_runner dies getting SIGPIPE

Added by Alexander Pyhalov 10 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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.

#1

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;

}
#2

Updated by Alexander Pyhalov 10 months ago

SIGPIPE in test case seems to be the intended behavior - it's consistent across Linux and OI

#3

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).

#4

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>

Also available in: Atom PDF