[bug#70542] [PATCH 0/4] Improve Shepherd service support for networked file systems

[Richard Sent]

Hi Jonathan!

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> Hello Richard,
>
> thanks for improving the CIFS mounting problem!
>
> I'm using a CIFS share on one of my servers. There I stumbled upon a
> problem, that the share is disappearing (e.g. CIFS server unavailable
> for a short time) and gets not automatically remounted.
>
> Do you know if this particular problem gets resolved with your patch?
>

I've never experienced that issue myself so I can't say for sure.
However, I don't believe my patch would resolve that issue.

file-system-shepherd-service in (gnu services base) is in charge of
mounting the file system. That service does not attempt to monitor the
file system's status after running. There's no daemon. If the file
system is mounted successfully, Shepherd will think there's no problem.

My understanding is that Shepherd will not respawn a service that
starts, then exits sucessfully. From Shepherd's manual:

> start’.  If the starting attempt failed, it must return ‘#f’
> or throw an exception; otherwise, the return value is stored
> as the “running value” of the service.

This could be solved by, for example, adding a remount? flag and/or
remount-delay field to file-systems and changing
file-system-shepherd-service to conditionally use a fork-style
constructor many other services use. Within that process, a loop checks
if there is a file system mounted at the target location.

There might be a better way to structure this. I'd be a little worried
about adding many new file-system record fields that aren't always used.
Consider when needed-for-boot is #t, file-system-shepherd-service isn't
used at all. Those new flags silently do nothing. I think that's fine
when it's just one (requirements), but it's probably worth some thought
if we add more later.

Either way it's probably another patch problem.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.