This is not a problem of rcnetwork. Before network is stopped we stop syslog. Then the debig messages go to console.

cthiel: maybe we should stop syslog later?

I guess we will need to split this bugs into two parts, because

 a) we need to discuss what kind of debug output NM schould produce (by default)

and 

 b) we should try to find a solution for syslog.

Let me add some words on syslog first: On boot we have a syslog_early and syslog (which get's started after rcnetwork). I understand that syslog needs to get stoped before we shut down the network, but IMO we could try introduce a syslog_late (or something like that) that does exactly the oposite of the things we do on boot. Does this sound good to you, Werner? Marius?

On the logging part, let's create another bug and continue the discussion there.

'earlysyslog start' starts local logging
'syslog start' switches to remote logging if configured
'syslog stop' should switch back to local logging (if called at runlevel change)
'earlyslog stop' should stop logging completely

Marius, can we do that with syslog-ng?

BTW: Why don't we start earlysyslog much earlier, e.g. after boot.localfs

Please no daemons within boot.d/ because this level is only
used at cold boot for the system check.

Beside this, logging over network requires an active network.
Therefore NM/rcnetwork should not depend on syslog.  This was
the reason for the split of syslog into earlysyslog and syslog.
Without using network for logging the first script should
start the syslog(-ng) and with forwarding the logs over network
the later script should be used.

NM/rcnetwork does not depend on syslog, so there is no bug on my side currently. NM will probably reduce verbosity anyway.

My qustions were:
1) Can we proceed using syslog locally after network stop like we do before starting network? Can we gat this somehow?

2) Very early syslog:
OK, i see can understand that you don't want to start deamons in boot.d. But since  we do a lot of asynchronous stuff via udev in boot.d it would be nice if we could log all actions to make debugging earlier.

So if you see a chance to get one of these features realized then i will happily file a feature request. Just tell me.
Otherwise, close this bug, if you say there is no chance.

Both 1) and 2) would require a caching daemon/service storing the
syslog messages locally as long as the disk is writable and if
the real syslog daemon is started forwarding all messages to
the new process owing /dev/log.  Don't know if this is possible
with a socket.

Please open a feature request but be aware that for 1) you may
not find an appropiate solution.  And for 2) we've to solve the
problem of having only one local socket and two daemons.