[oi-dev] OI no longer automounts USB sticks

[Gary Mills]

On Sun, Jun 27, 2021 at 01:00:46AM -0700, Joshua M. Clulow wrote:
> 
> OK, so I have looked into this a little bit.  It seems like there is a
> bug in the HAL code we ship, or in the glib that OI is now using, or
> somewhere inbetween.

You've gone much farther than I have.  With some help from you, I've
determined, with a current OI BE, that:

Something failed to notify hald of new USB devices.  Hald failed to
notify the process spawner: hald-runner.  The mount was never done.
In general, we agree.

> With DTrace, I am able to see (in the "hald --daemon=yes" process at
> the top of the HAL process tree) that it receives the appropriate
> sysevents from the kernel when a USB disk is plugged in or removed.

It's good to know that that bit of IPC works as intended.

[...]
> Where things appear to fall down is once we get into the glib area.
> The strings that are written into one end of the pipe by the sysevent
> consumer, as described above, are meant to then be read through a glib
> GIOChannel object in sysevent_iochannel_data():
> 
>     https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272
> 
> Though we do enter sysevent_iochannel_data() on schedule for each
> sysevent, it seems like the call to g_io_channel_read_line() always
> returns a value of 3 on my system -- which seems like an EOF?  Because
> the value is not G_IO_STATUS_NORMAL, we don't even try to call
> sscanf() to parse the lines we wrote above.  This means we never call
> into sysevent_dev_add() and thus we never pass the hotplug event on to
> the rest of HAL.

That sounds like the "temporarily unavailable" or the "interrupted
system call" errors for the read() system call in glib.

> I have run out of steam on this for now, but I hope this is enough for
> someone to keep digging.  In particular, it seems like it is worth
> investigating whether glib has been updated in OI at some point
> between when this was last working and now.  Perhaps there is a build
> issue or a bug there.  It doesn't seem like there has been a lot of
> change in the HAL daemon itself (which is in the gate, as linked
> above).

The hal package is rebuilt for OI.  There have been many changes, with
different revision numbers.  For example, in the BE from 2020-11-27
where mounts work, the package is service/hal at 0.5.11-2020.0.1.20171 .
In the BE from 2021-05-14 where mounts do not work, the package is
service/hal at 0.5.11-2020.0.1.20514 .  I assume the revision numbers
do not indicate actual changes.


-- 
-Gary Mills-		-refurb-		-Winnipeg, Manitoba, Canada-