tmpfiles: initctl command or native cleanup-age time

[aanderse]

i took a quick look and it doesn't seem like i can explicitly call tmpfiles functionality - no separate binary or invocation like initctl tmpfiles --clean/--create or whatever

i also didn't see any documentation for how often/when cleanup and creation functionality runs automatically...

maybe i missed documentation? and would it be possible to explicitly run tmpfiles, either as a separate executable or an initctl sub command?

thank you for your time and consideration 🙇‍♂

[troglobit]

You didn't miss anything. The Finit implementation of tmpfiles does not have any separate invocation to clean at runtime other than at system bootstrap, which is handled by the bootmisc plugin.

The tmpfiles support was mainly added to replace homegrown similar functionality to create package specific files, directories, etc. (also during bootstrap) with a more generic system.

[aanderse]

right, the tmpfiles spec has proven to be immensely useful... so would you be ok with exposing the functionality as something we can explicitly call? i think a long running system would benefit from adding to a cron job so old files get cleaned up, etc...

[troglobit]

Well sure, but the current implementation has no code for cleaning, the x/X flags are ignored, so it's a bit of work to get it in place, debugged, tested, and released. I have no need for this myself atm, but if someone steps up to submit a patch I'm willing to consider it. If it's a cleanup command to initctl or native support in Finit for cleanup-age, doesn't matter, but I think the latter would be better for embedded systems that don't necessarily have crond.

[aanderse]

ahh my mistake! i thought there was cleanup functionality. yes, i agree this doesn't make much sense. thanks for clarifying.

[troglobit]

Reopening, because there might be other people who'd like to contribute.

[aanderse]

@troglobit i'm at a point where i need to run tmpfiles to create some folders at more than just boot time

you may have noticed software starting to ship tmpfiles definitions

so i am interested in adding a tmpfiles binary to libexec/ which can be called when needed to create new files/folders, etc...

i would be happy to do the work... but after looking at this and modifying a few files to follow suit for tmpfiles then hitting some issues with the compiler... i'm starting to think there might be some things i should know before i proceed

any advice for me? how would you like to see this done?

thank you 🙇‍♂

[troglobit]

@troglobit i'm at a point where i need to run tmpfiles to create some folders at more than just boot time

you may have noticed software starting to ship tmpfiles definitions

Huh, I have not. Interesting!

so i am interested in adding a tmpfiles binary to libexec/ which can be called when needed to create new files/folders, etc...

Yeah a tmpfilesd or similar would be neat for this. Then we could relocate all the current code to that, and call it with an --init flag or something at bootstrap, before we start it as a proper service.

i would be happy to do the work... but after looking at this and modifying a few files to follow suit for tmpfiles then hitting some issues with the compiler... i'm starting to think there might be some things i should know before i proceed

I'm pretty sure you won't need to worry about stuff like that.

any advice for me? how would you like to see this done?

Without having read up any on how systemd-tmpfiles does this, it seems all the new daemon has to do is to watch for new files in whatever directory software installs their tmpfiles definitions in, and then "just" call the existing code with each such file as they appear.

Most of the daemons I maintain end up using an event loop, Finit itself makes use of libuEv, which may come in handy waiting for new files, or periodic timer wakeup at cleanup-age expirations.

I'd start there, create a stand-alone daemon first and build from there.

[aanderse]

i would be happy to do the work... but after looking at this and modifying a few files to follow suit for tmpfiles then hitting some issues with the compiler... i'm starting to think there might be some things i should know before i proceed

I'm pretty sure you won't need to worry about stuff like that.

my c skills are rusty and were never that amazing so please bear with me...

for simplicity let's say i'm trying to add a new program called foobar to the /libexec folder of finit - i would assume i should modify src/Makefile.am as follows:

diff --git a/src/Makefile.am b/src/Makefile.am
index ff3aca05..0756abad 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -8,7 +8,7 @@ AM_LDFLAGS         = -export-dynamic
 endif

 sbin_PROGRAMS        = finit initctl
-pkglibexec_PROGRAMS  = getty logit runparts
+pkglibexec_PROGRAMS  = getty logit runparts foobar
 if SULOGIN
 pkglibexec_PROGRAMS += sulogin
 endif
@@ -48,6 +48,11 @@ logit_CFLAGS         = -W -Wall -Wextra -Wno-unused-parameter -std=gnu99
 logit_CFLAGS        += $(lite_CFLAGS)
 logit_LDADD          = $(lite_LIBS)

+foobar_SOURCES       = foobar.c helpers.c helpers.h util.c util.h log.h log.c
+foobar_CFLAGS        = -W -Wall -Wextra -std=gnu99
+foobar_CFLAGS       += $(lite_CFLAGS)
+foobar_LDADD         = $(lite_LIBS)
+
 finit_SOURCES      = api.c     cgroup.c        cgroup.h        \
                     client.c   client.h                        \
                     cond.c     cond-w.c        cond.h          \

if i build this i get the following error:

helpers.c:550:33: error: implicit declaration of function 'logit';

if i want to write a separate tmpfiles executable to replace the builtin functionality that comes with finit i will need to link against helpers.c and util.c because they have functionality that the current tmpfiles.c requires - the deeper i go into trying to compile the more issues i have... i'm missing something obvious in the intention of your message - can you please point it out to me?

thanks!

[troglobit]

Looks good so far, but peek a bit further down:

finit_CPPFLAGS     = $(AM_CPPFLAGS) -D__FINIT__
                                    ^^^^^^^^^^^

It's for the benefit of log.h which is used by everyone, but programs that link with log.c need to define __FINIT__ to unlock the logit() helper function.