Re: SMP: process-specific options

On Mon, 22 Feb 2010 20:38:54 -0700, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/21/2010 01:52 AM, Amos Jeffries wrote:
>>>> Other things from my prior thoughts about this design is that it
>>>> implies
>>>> squid-N.pid, and cache-N.log (for now) files with N being the process
>>>> number/name.
>>>
>>> I am not sure it implies that, actually (even for now), but it
certainly
>>> would be an option.
>>
>> Under the current architecture the child is the one in .pid and the
exit
>> code determines whether master re-spawns or closes. I was previously
>> working from that angle.
>
> Understood.
>
>> If we invert the current design and have master being the one .pid
>> entry...
>>
>> ... you would be altering the .pid to hold the master PID, which
somehow
>> receives the PID for each child back from the child and shuts off the
>> children when it gets a shutdown signal.
>
> The parent process is not in a very good position to do much because it
> block-waits for the kids. It can still handle signals, I guess. Perhaps
> we can change that, but I am not sure we should.
>
> A dedicated kid process that handles signals (shutdown, debug,
> reconfigure, etc.) and possibly other coordination tasks may work
> better. That process can communicate to others what they should do,
> either by resending the signal to all of them or using some more
> sophisticated IPC methods.
>

I think roberts spawner process makes a good step in this direction and is
re-usable with many types of binary started. Keeping the fork+exec+watch
style, while allowing the master to continue with better things while it
waits for the socket FDs to be handed back to it by the spawner.

Whether the signals themselves are shuffled into another child process for
signal handling is sort of a side issue. I'm thinking that needs to be
decided on a per-signal basis, after the IPC design is finalized.

>
>> cache.log depends on how you plan to re-plumb the linkage between
master
>> and worker. The current silent process monitoring method is iffy in the
>> middle.
>> What were you planning for monitoring? socket read/write events?
>
> I was not planning on changing waitpid() code in the master process if
> that is what you are asking about.
>
>> If you have each instance completely independent with its own
>> current-style monitor talking to a master instance its easy to plumb
>> cache.log through the link socket, but _that_ means that PID are harder
>> to manage as the worker child is not connected to the sockets directly.
>
> For logs, can we just use O_APPEND and have each process write to the
> logs as we do now?

Hmm, maybe. Worth a try anyway. That case will 100% needs a process ID to
be logged on each debugs() line for tracking though. access.log should be
fine.

>
>> If the file was open(2)ed with O_APPEND, the file offset is
>> first set to the end of the file before writing. The adjustment of
the
>> file offset and the write operation are performed as an atomic step.
>
> Log rotation will probably need special care to avoid rotating the same
> log many times. It is relatively easy to designate one process to do the
> rotation (e.g., squid1), but that alone is not enough to synchronize
> everything. Ideally, I would prefer to avoid locking. Any clever tricks
> applicable here?

Other than that designated instance to do the rotate, no I can't think of
anything. If the signal handler process you mentioned might be best to do
the renaming. The detach-reopen will need to remain with anything doing the
file writes.

Maybe officially offload to external log rotation software? They seem to
be widely available by default. The ones I've seen all provide some modular
config where we can drop-in a rotate config file and it's done. Some distro
packages do this already.

Amos
Received on Tue Feb 23 2010 - 04:00:52 MST