On 11/20/2017 08:46 PM, Felix Fietkau wrote: > On 2017-11-20 14:25, Zefir Kurtisi wrote: >> On 11/20/2017 01:27 PM, Felix Fietkau wrote: >>> On 2017-11-20 11:20, Zefir Kurtisi wrote: >>>> PROCD services can't overwrite those functions defined in the >>>> USE_PROCD body (like stop()), since the initfile is sourced >>>> before. >>>> >>>> This change moves the sourcing below and with that allows >>>> PROCD init scripts to overwrite them. >>>> >>>> Signed-off-by: Zefir Kurtisi <zefir.kurt...@neratec.com> >>> This seems broken to me. USE_PROCD is defined by the init script, so you >>> can't test for it before the script has been sourced. >>> >>> - Felix >>> >> This was my initial assumption, but in fact it works as expected (for PROCD >> and >> legacy services). Running 'INIT_TRACE=y /etc/init.d/log shows that USE_PROCD >> is >> set correctly during execution. >> >> Why it does I don't understand, since when >> * /etc/init.d/log starts with '#!/bin/sh /etc/rc.common' >> * in /etc/rc.common, the initscript is sourced again >> >> ... I expected this to be a circular dependency, but what it does is: >> 1. interpreting all the variables set in initscript (including USE_PROCD=1) >> 2. interpreting all the variables set in rc.common >> (starting with [ -n "$USE_PROCD" ]) >> 3. executing the functions >> >> Could not find enough information about how shebanging a shell-script is >> executed. >> >> Does somebody know and could please clarify? > I just did an experiment and your claimed step 1 does not happen in my > test. rc.common gets interpreted first, and USE_PROCD is unset where it > would be needed. > > - Felix > Thank you Felix for taking a look.
:-/ need to find out why it does differently on my side, but anyway realized that the approach tried might not be the best in town. What I need to achieve is a 'logread --follow --reconnect' functionality, i.e. currently if someone is running a 'logread -f' in a console and log service is restarted, the logread instance stops logging. I'll try to add that functionality to logread instead. Thanks, Zefir _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev