Description of problem: If systemd starts dspam before postgresql is up and ready, dpsam has two problems: a) It doesn't work as it doesn't seem to try to reattach to the database b) dspam eats up file descriptors until there are non-available. I do not understand systemd so I am not sure how to fix a. Although a could be fixed in dspam. b is definitely a bug in dspam. I imagine this affects dspam with mysql as well. Since I am not sure there is a way to make this work with both dspam-mysql and dpsam-postgresql in systemd, I would recommend that both a and b be fixed in dspam. After all, a is just standard error correction. To avoid problems with performance, reconnecting to the database should probably be deferred until the connection is needed. If this is being done, then the problem is probably similar to bug #748931 and the lack of network/dns resolution. B is definitely a bug in dspam. Version-Release number of selected component (if applicable): Any in Fedora 16
> a) It doesn't work as it doesn't seem to try to reattach to the database > Right. DSPAM does not re-attach to the database. IMHO re-attach means "again attaching to the database". But when PostgreSQL is not there then DSPAM can not re-attach. The only thing DSPAM could do is try to re-initialize . > b) dspam eats up file descriptors until there are non-available. > I am not an systemd user. However... I can not reproduce this on my end. Regardless what I try. DSPAM is started as daemon (trying to attach in an endless loop to PostgreSQL), PostgreSQL is down, trying to use DSPAM (client connecting to daemon) just gives me an error "Unable to attach DSPAM context". That's all what is happening over here. File descriptors stay stable and the open file list stays stable too. Nothing changes significantly, regardless how long I wait. 1) Are you sure that DSPAM is eating all those file descriptors and not systemd? 2) How can I as a non systemd user simulate that error on my end? I can easily add a connection timeout to PQconnect. Right now there is none (aka: wait indefinitely). This will however not solve the problem if you start DSPAM without having the backend ready. All this timeout will do is to let the DSPAM daemon exit after reaching the timeout during the connection.
I am sorry. This must have been a combination of bugs. I have been seeing phantom bugs come and go with F16 glibc and kernel changes. This one seems to have been fixed in the last few days. DSPAM is properly reinitializing and connecting ot the database. I see no leeks myself. I suppose this one is a NOTABUG or PHANTOM or some such. Thank you.
Hello Trever, no problem. Better reporting once one potential issue earlier that waiting to long and having a gazillion of users affected by the problem. Thank you for helping making DSPAM and Fedora a better product.