[Lcdproc] Signalling in server/main.c

Markus Dolze bsdfan at nurfuerspam.de
Sun Mar 22 22:04:51 UTC 2009


Joris Robijn wrote:
> On 1 Feb 2009 at 10:52, Markus Dolze wrote:
> 
>> -------- Original-Nachricht --------
>>> Datum: Sat, 31 Jan 2009 16:06:46 +0100
>>> Von: "Joris Robijn" <joris at robijn.net>
>>> An: lcdproc at lists.omnipotent.net
>>> CC: bsdfan at nurfuerspam.de
>>> Betreff: Re: [Lcdproc] Signalling in server/main.c
>>>> The whole thing is only necessary because fork() happens before the
>>>> drivers are initialized. It was after the initialization before 0.5.0.
>>>>
>>>> Does anybody of the former developers remember why fork() was moved
>>> before
>>>> the initialization?
>>> The server looses the priviledges on the parallel port after the fork.
>>> That's why the drop_privs is done after the fork and after the driver
>>> init.
>>>
>> Hi Joris,
>>
>> that's a good point. But I am not concerned about drop_privs, but about
>> the fork().
>>
>> Currently we do (simplyfied):
>>
>> CHAIN(e, parent_pid = daemonize());
>> install_signal_handlers()
>> CHAIN(e, sock_init(bind_addr, bind_port));
>> // ... Other inits
>> CHAIN(e, server_screen_init());
>> CHAIN_END()
>> wave_to_parent(parent_pid);
>> drop_privs(user);
>>
>>
>> What about:
>>
>> CHAIN(e, sock_init(bind_addr, bind_port));
>> // ... Other inits
>> CHAIN(e, server_screen_init());
>> CHAIN(e, parent_pid = daemonize());
>> install_signal_handlers()
>> CHAIN_END()
>> drop_privs(user);
>>
>> This way we may avoid the signalling at all.
>>
>> Regards,
>> Markus
> 
 > Hi Markus,
 >
 > What I mean is that the gained access to the port is lost at the fork.
 > And after the drop_privs you are no longer root so you cannot get access
 > anymore. That's why the order is like this. All related to the good ol'
 > parallel devices.
 >
 > But I wouldn't rule out the possibility that there's a better way to
 > accomplish the same.
 >
 > Joris
 >
 >
 >

Today I found another thing that got broken by the current order: If the 
driver uses /stay_in_foreground/ variable.

Currently we do:

	if (!foreground_mode) {
		CHAIN(e, parent_pid = daemonize());
	}
	...
	CHAIN(e, init_drivers());
	...
	if (!foreground_mode) {
		/* Tell to parent that startup went OK. */
		wave_to_parent(parent_pid);
	}

If a driver has /stay_in_foreground=1/ set or sets it during init, the 
value of foreground_mode is changed by the call to /init_drivers()/. The 
result is the server does not get signalled and waits in the foreground.

This issue could not be resolved, because upon /init_drivers()/ the 
server has already forked. If it waits like now it can be killed by 
Ctrl-C, but the child controlling the displays keeps running.


I will write a change for this and will sent it for discussion. But any 
idea is welcome right now.

Regards
Markus



More information about the LCDproc mailing list