all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Richard Sent <richard@freakingpenguin.com>
To: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Cc: 70542@debbugs.gnu.org
Subject: [bug#70542] [PATCH 0/4] Improve Shepherd service support for networked file systems
Date: Thu, 25 Apr 2024 09:43:47 -0400	[thread overview]
Message-ID: <87le51y2uk.fsf@freakingpenguin.com> (raw)
In-Reply-To: <9e8e0f42-e403-d919-3b18-be010757097c@web.de> (Jonathan Brielmaier's message of "Thu, 25 Apr 2024 08:51:56 +0200")

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.




      reply	other threads:[~2024-04-25 13:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-23 20:44 [bug#70542] [PATCH 0/4] Improve Shepherd service support for networked file systems Richard Sent
2024-04-23 20:47 ` [bug#70542] [PATCH 1/4] file-systems: Add requirements field to file-systems Richard Sent
2024-04-24 17:31   ` Liliana Marie Prikler
2024-04-23 20:47 ` [bug#70542] [PATCH 2/4] services: base: Use requirements to delay some file-systems Richard Sent
2024-04-24 17:30   ` Liliana Marie Prikler
2024-04-23 20:47 ` [bug#70542] [PATCH 3/4] file-systems: Add support for mounting CIFS file systems Richard Sent
2024-04-24 17:29   ` Liliana Marie Prikler
2024-04-24 18:22     ` Richard Sent
2024-04-24 18:47       ` Liliana Marie Prikler
2024-04-24 19:19         ` Richard Sent
2024-04-23 20:47 ` [bug#70542] [PATCH 4/4] system: Do not check for CIFS file system availability Richard Sent
2024-04-24 17:26   ` Liliana Marie Prikler
2024-04-23 20:51 ` [bug#70542] Missing reference in cover letter Richard Sent
2024-04-25  4:56 ` [bug#70542] [PATCH v2 1/3] services: base: Add optional delayed mount of file-systems Richard Sent
2024-04-25  4:56   ` [bug#70542] [PATCH v2 2/3] file-systems: Add host-to-ip nested function Richard Sent
2024-04-25  4:56   ` [bug#70542] [PATCH v2 3/3] file-systems: Add support for mounting CIFS file systems Richard Sent
2024-04-25  6:51 ` [bug#70542] [PATCH 0/4] Improve Shepherd service support for networked " Jonathan Brielmaier via Guix-patches via
2024-04-25 13:43   ` Richard Sent [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87le51y2uk.fsf@freakingpenguin.com \
    --to=richard@freakingpenguin.com \
    --cc=70542@debbugs.gnu.org \
    --cc=jonathan.brielmaier@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.