Problems aftre today's yum upgrade

[scott]

Hmm, well the dcc package is called dcc, so rpm -q dcc on that, and razor is called razor-agents. Just to be safe run rpm -qa |grep -i razor. Dag had an older razor package called perl-Razor-Agents I think. I definitely had issues with that when I was testing early on. Also check the version of spamassassin (rpm -q spamassassin). I did all my testing with SA 3.0, if you're running an older version its possible that dcc might conflict with it, or perhaps the spamassassin settings are causing problems (/etc/sysconfig/spamassassin if you're using 3.0). The way razor and dcc work, is that they are called from spamd if they are detected, the whole process is automatic. Overall the architecture works like this:
external mail server connects to xinetd (port 25)
xinetd hands connections to rblsmtpd (if configured)
rblsmtpd hands connections to qmail-smtpd
qmail-smtpd hands connections to qmail-scanner (via qmail-queue wrapper, this is why drweb wont work with it, they use the same trick)
qmail-scanner calls clamav, and then spamd
spamd calls razor, dcc, pyzor, does rbl checks, etc
spamd hands mail back to qmail-scanner
qmail-scanner hands mail to the real qmail-queue (qmail-queue.orig)
qmail-queue sends mail to local delivery
local delivery is controlled via the users .qmail file
.qmail file dictates where to deliver the users mail, generally Maildir/

If however you are using psa-spamassassin, .qmail will call spamassassin (again), which will also call razor/pyzor/dcc/rblchecks, and then hand that message back to the .qmail file for delivery to the final destination (Maildir/).

[phatPhrog]

All of that is well and good, but since you installed/upgraded our server last I trusted everything to be in order. Don't misunderstand me. Not being rude or anything.

You installed spamassasin, not psa-spamassasin along with qmail-scanner and your other dependent programs.

All we did was run yum upgrade on 06-01 and now the dccproc is showing up as a defunct process on and off during the day.

When running rpm -q dccproc the message returned says dccproc isn't even installed.

We're unsure how to proceed since we don't wish to make changes that may impact the work you did.

Please let us know whether you need to look at your setups or whether we are on our own.

Thanks for the update.

Les

[scott]

There is no dccproc package, its called dcc. Its also possible that dcc is filtering out your IP block, which they have done on rare occations.

[Stucco]

****** My Posts in this thread do not have to do with a defunct dcc process. Sorry for hijacking it.******

And wow there are a lot of updates! I see notes about uninstalling q-s and spamassassin and clamav, and reinstalling clamd. Is that the solution to this?

Code: Select all

>>yum update
Gathering header information file(s) from server(s)
Server: Atomic Rocket Turtle - 2 - Atomic PSA-Compatible RPMS
Server: Atomic Rocket Turtle - 2 - Atomic Desktop
Server: Atomic Rocket Turtle - 2 - Base OS RPMS mirror
Server: Atomic Rocket Turtle - 2 - SW-Soft PSA 7.1 RPMS
Server: Atomic Rocket Turtle - 2 - SW-Soft PSA 7.5 RPMS
Server: Atomic Rocket Turtle - 2 - OS Update RPMS mirror
Finding updated packages
Downloading needed headers
Resolving dependencies
.conflict between qmail-scanner and drweb
conflict between qmail-scanner and drweb-qmail

I never saw this conflict until today, and I ran the all updates 15-20 days ago or so.

Do I uninstall q-s, clamav, and spamassassin in that order? Then install clamd?

Thanks in advance to whomever loans me their brain,

Stucco

[scott]

I added that Conflict in there on this last revision. In theory its possible to run the two alongside each other, but as I don't have access to a functional dr. web (or the time really ) I just opted for the safety-first approach.

[Stucco]

Thanks! I'm sure those kind of things help very much for people like me.

Could you, or someone else, confirm these steps as the right way to fix this?

Do I uninstall q-s, clamav, and spamassassin in that order? Then install clamd?

[scott]

you want:
yum remove drweb drweb-qmail

[Stucco]

Thanks a million

[Stucco]

Should cs-gs be a dependency of psa 7.5.3, cause I tried to update but it failed because it couldn't find file module_cs_gs_configs.MYI. I'm guessing a yum update cs-gs will fix this.

[Stucco]

So here's what I did

yum remove qmail-scanner spamassassin clamav
yum remove drweb drweb-qmail
yum update psa-migration-manager - failed
yum update cs-gs
yum update

So I couldn't get to my plesk login since the failed one, so I rebooted and psa is running but this is all I get

Code: Select all

Please wait.
Loading ...
 
ERROR 	
Table 'psa.ControlVisibility' doesn't exist
0: /usr/local/psa/admin/plib/visibility.php:148 psaerror(string "Table 'psa.ControlVisibility' doesn't exist")
1: /usr/local/psa/admin/plib/visibility.php:291 getvisibilitycustomizations(string "/login_up.php3")
2: /usr/local/psa/admin/plib/visibility.php:300 getvisibility(string "login", boolean true, NULL "")
3: /usr/local/psa/admin/plib/elements.php3:180 iscontrolvisible(string "login", boolean true)
4: /usr/local/psa/admin/plib/elements.php3:106 fetch_hideable_button(string "commonButton", string "login", string "", string "", boolean false, string "", string "return login_oC(document.forms[0], document.forms[1])", boolean true, integer "3", boolean false, boolean false)
5: /usr/local/psa/admin/htdocs/login_up.php3:769 comm_button(string "login", string "", string "return login_oC(document.forms[0], document.forms[1])", boolean true, integer "3")

Not really sure where to proceed from here since I don't think I can uninstall and reinstall psa...how do you fix a boched update on psa itself?

[Stucco]

I found someone with a similar problem at the forums at sw-soft.com. Their solution is posted there at this link.

http://forum.sw-soft.com/showthread.php ... adid=24038

It did get rid of my problem, but no telling how many more I will have in the future from this boched update.

My main problem is that my plesk says it's version 7.5.2, but the update is not listed for 7.5.3 in yum. I guess the rpm database is messed up...I hope this doesn't affect anything else...

Stucco

[phatPhrog]

Not sure if this will help, or has anything to do with it, but .....the latest kernel upgrade for FC1/Plesk 7.04 from Linux 2.4.22-1.2199.4.legacy.nptl to Linux 2.4.22-1.2199.5.legacy.nptl (upgraded on June 7) has resulted in no further dccproc sessions being defunct.

There have been no other changes made since originally posting this question.

Is this just a coincidence I should be thankful for?

[phatPhrog]

No never mind.

Famous last words. The defunct is back.

Will check out the link listed above to see if that works.

[jamesyeeoc]

The link posted above has nothing to do with the original problem of dcc going defunct/zombie, it has to do with the 'visibility' problem posted by Stucco. I noticed that no clear solution was ever posted to this old thread.

I am running a Plesk 7.5.3, RH9 (fresh installs) standalone dedicated server, with the following versions:

kernel 2.4.20-43.9
clamd-0.86.2-1.rf.rh90.art
clamav-0.86.2-1.rf.rh90.art
clamav-db-0.86.2-1.rf.rh90.art
dcc-1.3.5-1.rh90.art
razor-agents-2.67-3.rh90.art
spamassassin-3.0.3-1.rh90.art

Do NOT have installed:
psa-spamassassin
DrWeb

All updates done using ART repositories only.

Am still getting defunct/zombie dcc processes, cannot figure out why. Also not sure if all 3 of the clam packages should be there, they were installed during the initial qmail-scanner installation.

Scott - can you tell me if there are version mismatches in the above list? Since this was a fresh server install, all those versions were installed during the initial qmail-scanner install.

Could mod_security 1.8.7 have any contributing affect? I just installed that the other day with ALL available rulesets, not just the default few.

[scott]

I cant see that mod_security would have any effect on that. The main parts of the OS that could do it would be the kernel, glibc, or the dcc binary itself. The fact that the binary loads (and works, presumably you're getting DCC messages in your spam reports?) rules out dcc directly. Perhaps a tertiary library is involved, or even just a bug in DCC itself (my primary suspect). The other thing it could be is the CPU the box is using, perhaps an AMD CPU running a i686 optimized glibc, or even a network connection being open too long on the DCC server side.