> On 25 Oct 2018, at 20:33, Shankar Unni <shankar.u...@gmail.com> wrote:
> On Oct 24, 2018, at 2:49 PM, Simon Kelley <si...@thekelleys.org.uk> wrote:
>> […]
>> The next option in my sights is NO_FORK. This produces a
>> mostly-functional binary that never forks any new processes. It was
>> added long ago to support uclinux, the MMU-less version of Linux. As far
>> as I can tell, MMU-less linux is a dead project, and I'm minded to
>> remove NO_FORK. Opinions? Is this option vital to something I'm not
>> aware of?
> From what i can see, this will kill off the ‘k’ option that’s used by many 
> process-management environments.  E.g. openwrt’s process management (the 
> procd daemon) depends on the originally-launched process to stick around (it 
> doesn’t know or care about the PID file), and does really ugly things if the 
> PID changes after launch.  It also doesn’t seem to have an option to pass in 
> an explicit PID file to read and poll.  (I just verified by removing the -k 
> option, and it keeps spawning more and more dnsmasqs..)
> If you do want to do this, it’ll probably need a few months of warning and 
> preparation for various distros..

A quick glance at the code suggests you’ve misunderstood.  The compile time 
option ’NO_FORK’ is designed for systems that don’t have a fork system 
call….which is unusual to say the least.  A fair amount of code is *added* if 
NO_FORK is NOT defined… or to put in clearer English, the code to support 
‘fork’ is added in unless NO_FORK is defined.

The run-time option OPT_NO_FORK aka ‘-k’ is to prevent dnsmasq forking and as 
you say is used by some process management daemons to determine if a process 
under its control has died or not.  My reading of the code suggests that 
removing ’NO_FORK’ build option does NOT remove ‘-k’ OPT_NO_FORK run-time 

I think Openwrt is safe.   There will be a loud scream from me if it isn’t :-)


Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

Dnsmasq-discuss mailing list

Reply via email to