[systemd-devel] [RFC PATCH] condition: add ConditionFileContains=

[Lennart Poettering]

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

-- 
Lennart Poettering - Red Hat, Inc.