ct_sync [FAILED] - Mandriva
This is a discussion on ct_sync [FAILED] - Mandriva ; What is `ct_sync`. Do I need it? Why would I need it? Why does
"everything" seem to be running along Just Fine without it?
I have a suspicion that it may be smp-centric.
Several days ago, the boot-up process of ...
-
-
Re: ct_sync [FAILED]
On Wed, 02 Jan 2008 22:52:10 +0000, Allodoxaphobia wrote:
> What is `ct_sync`. Do I need it? Why would I need it? Why does
> "everything" seem to be running along Just Fine without it? I have a
> suspicion that it may be smp-centric.
>
> Several days ago, the boot-up process of this PC has been showing:
> Starting ct_sync [FAILED]
>
8<
I know this is no solution or help, but following some updates (not sure
what), I have been having the same FAILED message during boot up. This
has happened on 3 different machines, each with no apparent ill effects.
-
Re: ct_sync [FAILED]
On Wed, 02 Jan 2008 17:52:10 -0500, Allodoxaphobia wrote:
> What is `ct_sync`. Do I need it? Why would I need it? Why does
> "everything" seem to be running along Just Fine without it?
I don't have it installed, but "urpmf ct_sync" shows ...
invictus-firewall:/etc/rc.d/init.d/ct_sync
invictus-firewall:/etc/sysconfig/ct_sync
Check the settings in sysconfig, and any documentation/settings you can
find for invictus.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
-
Re: ct_sync [FAILED]
Allodoxaphobia wrote:
> What is `ct_sync`. Do I need it? Why would I need it? Why does
> "everything" seem to be running along Just Fine without it?
> I have a suspicion that it may be smp-centric.
>
Looks like the "cConnection tracking state replication for Netfilter" is
only necessary for dual-NIC (bonding or redundant) systems.
I remember some related settings available from mcc "advanced settings -
network redundance" in the network section.
--
vista policy violation: Microsoft optical mouse found penguin patterns
on mousepad. Partition scan in progress to remove offending
incompatible products. Reactivate MS software.
Linux 2.6.22.12-1mdvcustom [LinuxCounter#295241,ICQ#4918962]
-
Re: ct_sync [FAILED]
On Wed, 02 Jan 2008 17:01:09 -0600, Jo Shloe wrote:
> On Wed, 02 Jan 2008 22:52:10 +0000, Allodoxaphobia wrote:
>
>> What is `ct_sync`. Do I need it? Why would I need it? Why does
>> "everything" seem to be running along Just Fine without it? I have a
>> suspicion that it may be smp-centric.
>>
>> Several days ago, the boot-up process of this PC has been showing:
>> Starting ct_sync [FAILED]
>
> 8<
>
> I know this is no solution or help, but following some updates (not sure
> what), I have been having the same FAILED message during boot up. This
> has happened on 3 different machines, each with no apparent ill effects.
Yep. I believe it happened here after a recent `urpmi --auto-select`.
And, too, there seems to be no ill effects.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts:
-
Re: ct_sync [FAILED]
On Thu, 03 Jan 2008 16:24:02 +0100, Walter Mautner wrote:
> Allodoxaphobia wrote:
>
>> What is `ct_sync`. Do I need it? Why would I need it? Why does
>> "everything" seem to be running along Just Fine without it?
>> I have a suspicion that it may be smp-centric.
>>
> Looks like the "cConnection tracking state replication for Netfilter" is
> only necessary for dual-NIC (bonding or redundant) systems.
There are physically' 2 NIC's in this box. One slow, MB-mounted NIC.
And, one fast, card-mounted NIC (RTL8169).
But, I went through the effort to disable the MB-mounted NIC in the
BIOS:
:
|$ dmesg | grep -i eth
|r8169 Gigabit Ethernet driver 2.2LK loaded
|eth0: Identified chip type is 'RTL8169s/8110s'.
|eth0: RTL8169 at 0xf8840c00, 00:06:4f:22:be:29, IRQ 19
|r8169: eth0: link up
|$
:
Maybe the low-level routines in the boot process are just too clever by
half. :-)
> I remember some related settings available from mcc "advanced settings -
> network redundance" in the network section.
OK. I'll dig into that.
Thanks & HNY
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts:
-
Re: ct_sync [FAILED]
On 3 Jan 2008 17:12:26 GMT, Allodoxaphobia wrote:
> On Thu, 03 Jan 2008 16:24:02 +0100, Walter Mautner wrote:
>> Allodoxaphobia wrote:
>>
>>> What is `ct_sync`. Do I need it? Why would I need it? Why does
>>> "everything" seem to be running along Just Fine without it?
>>> I have a suspicion that it may be smp-centric.
>>>
>> Looks like the "cConnection tracking state replication for Netfilter" is
>> only necessary for dual-NIC (bonding or redundant) systems.
>>
>> I remember some related settings available from mcc "advanced settings -
>> network redundance" in the network section.
>
> OK. I'll dig into that.
No joy. I found "Advanced setup for network interfaces and firewall"
down inside "Security" in MLCC. But, I did not see anything there that
a.) was checked, nor b.) that would seem to apply to my problem.
I could go in and simply rip out ct_sync in /etc/rc.d/...
(OBTW, ct_sync, itself is _not_ to be found on this machine.)
Or, I could install the new drakx-net and drakx-net-text that Software
Management just informed me are available in the package updates....
Maybe 'they' are fixing this very problem which arose after an earlier
urpmi --auto-select I did last week. That's about when I saw the
problem crop up....
I'll report back.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts:
-
Re: ct_sync [FAILED] [[SOLVED]]
On 4 Jan 2008 03:46:17 GMT, Allodoxaphobia wrote:
> On 3 Jan 2008 17:12:26 GMT, Allodoxaphobia wrote:
>> On Thu, 03 Jan 2008 16:24:02 +0100, Walter Mautner wrote:
>>> Allodoxaphobia wrote:
>>>
>>>> What is `ct_sync`. Do I need it? Why would I need it? Why does
>>>> "everything" seem to be running along Just Fine without it?
>>>>
>>> Looks like the "cConnection tracking state replication for Netfilter" is
>>> only necessary for dual-NIC (bonding or redundant) systems.
>
> I could go in and simply rip out ct_sync in /etc/rc.d/...
> (OBTW, ct_sync, itself is _not_ to be found on this machine.)
>
> I'll report back.
OK. I'm back.
$ chkconfig --del ct_sync did the trick.
Why ct_sync was ever in the list is beyond me. My suspicion: it was
stuck to the bottom of a shoe of some RPM that was installed last week.
Also:
$ chkconfig --del oki4daemon
.... which I also think was stuck to the bottom a shoe of some RPM that
was installed last week. I know it was not there after the MDV 2008
install, and, indeed, all the printers around here are HP LJ's.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
*** Killfiling google posts: