Service activation snippets vs mounting filesystems

Service activation snippets vs mounting filesystems

[Mark H Weaver]

Hello Guix,

I wanted to add a service to clean /tmp and /var/run at boot time, and
have run into several problems.

First, I see no way to add a service that will be run early at boot time
without modifying Guix itself.  In this case, it should run after
mounting filesystems but before anything else is started.  It would be
good to have a way to express such a constraint without modifying all of
the existing services.

For now, I was going to hack it into 'user-processes-service', since
'essential-services' arranges to add all filesystem services to the
requirements for 'user-processes-service', and most other services
depend on 'user-processes', so it seems well positioned for this cleanup
task.

However, I've now discovered a problem.  Several services have
activation scripts that create things in /var, and sometimes even in
/var/run, one of the directories I want to clean.  So, I must ensure
that my cleanup happens before these activations.

The problem is that these activation scripts are run before dmd is even
launched, in 'operating-system-boot-script'.  This implicitly assumes
that everything created in the activation scripts is located on the root
filesystem, since of course it happens before filesystems are mounted.

Or am I missing something?

Where is the right place to clean up /tmp and /var/run ?

     Mark

Re: Service activation snippets vs mounting filesystems

[Andreas Enge]

On Tue, Feb 24, 2015 at 10:31:12PM -0500, Mark H Weaver wrote:
> Where is the right place to clean up /tmp and /var/run ?

Would it be easier to do so when shutting the machine down?

Andreas

Re: Service activation snippets vs mounting filesystems

[Mark H Weaver]

Andreas Enge <andreas@enge.fr> writes:

> On Tue, Feb 24, 2015 at 10:31:12PM -0500, Mark H Weaver wrote:
>> Where is the right place to clean up /tmp and /var/run ?
>
> Would it be easier to do so when shutting the machine down?

My primary motivation for doing this is to ensure a clean startup if the
system crashes, power is lost, resume from suspend fails, etc, so
cleaning up during shutdown wouldn't help.  In practice, when my system
fails to shut down cleanly, many services fail to start, and I have to
manually clean up stale files in /var/run and /tmp, and then either
enable and start several dmd services, or reboot.

Anyway, even without adding this cleanup code, there's already a
problem: the service activations are performed when only the root
filesystem is mounted, thus implicitly assuming that all of the
files/directories created during those activations are on the root
partition.

     Mark

Re: Service activation snippets vs mounting filesystems

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> For now, I was going to hack it into 'user-processes-service', since
> 'essential-services' arranges to add all filesystem services to the
> requirements for 'user-processes-service', and most other services
> depend on 'user-processes', so it seems well positioned for this cleanup
> task.

Yes, sounds good.

> However, I've now discovered a problem.  Several services have
> activation scripts that create things in /var, and sometimes even in
> /var/run, one of the directories I want to clean.  So, I must ensure
> that my cleanup happens before these activations.
>
> The problem is that these activation scripts are run before dmd is even
> launched, in 'operating-system-boot-script'.  This implicitly assumes
> that everything created in the activation scripts is located on the root
> filesystem, since of course it happens before filesystems are mounted.

Right.

> Or am I missing something?
>
> Where is the right place to clean up /tmp and /var/run ?

Cleaning up /tmp poses no problem I guess, so really the only problem is
/var/run.  So a first step would be a patch for /tmp cleanup.  :-)

The activation script needs to run early because it creates user
accounts and such.  It also needs to be separate and standalone so that
‘guix system reconfigure’ can run it.

Now, the ‘activate’ snippet of services could be moved out of the
activation script to the ‘start’ method of the dmd service, in dmd.conf.
That way, they would run after the “real” activation code.

WDYT?

Ludo’.