[systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
lennart at poettering.net
Fri Jul 12 12:19:58 PDT 2013
On Fri, 12.07.13 20:42, Karol Lewandowski (k.lewandowsk at samsung.com) wrote:
> > On Fri, Jul 12, 2013 at 3:31 PM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> >>>> ConditionFileContains=/sys/module/sn/parameters/enabled:1
> >> To make this clear: I am not keen on adding this. I can see the
> >> usefulness, and the thing is still simple enough so that it would be OK
> >> to add this, but if you guys don't actually need that I'd prefer to keep
> >> our codebase smaller...
> We can workaround this one way or another - be it shell script,
> udev rule or, in some cases, generator. Patch that started this
> discussion is yet another option.
> I have looked into /etc/init.d on my Debian system and found
> following examples of 'grepping' files used to decide if given
> service should be started or not:
> - kernel option specified - /proc/cmdline
We have ConditionKernelCommandLine= for this case, and it is a bit more powerful.
> - filesystem available - /proc/filesystems
This sounds like something one could also do with ConditionPathExists=
checking for some module in /sys/module/ or so.
> - file contains non commented out lines - /etc/exports
It's probably a better idea to simply not ship that file by
default. That's how we handle the rc.boot case.
> - cpu features available - /proc/cpuinfo
We have CPU feature based kernel module auto-loading these days, which
makes pretty much all of these cases where this was necessary
redundant. If the modules are auto-loaded where needed it is afterrwards
sufficient to check for /sys/module/ for the functionality...
> - software raid (md) status - /proc/mdstat
Not sure what this is really doing...
> - ...
> Every such case could be handled by generic "built-in grep"
> instead of dozen of flags like ConditionCPUFeature=,
> ConditionMDStatus=, ...
I am pretty sure we cover most of these cases with some other way too.
I mean, I am generally willing to add this, but if there's no strict
need for it, I'd avoid it.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel