On Fri, 12.07.13 20:42, Karol Lewandowski ([email protected]) wrote:
> > On Fri, Jul 12, 2013 at 3:31 PM, Lennart Poettering > > <[email protected]> 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
