Re: [exim] Vary weird problem - unable to set uid=12

Marc Perkel wrote:
> This is a very weird problem. Everything will be running fine for
> several weeks and all of a sudden I get this:
>
> 2009-03-29 06:48:57 1LnvJq-0000sZ-Eu unable to set gid=12 or uid=12
> (euid=0): post-delivery tidying
> 2009-03-29 06:48:57 1LnvD5-0001Jx-7o unable to set gid=12 or uid=12
> (euid=0): filter_quicktap router (recipient is andrea@???)
>
> And at the same time I get this:
>
> 2009-03-29 04:36:05 daemon: accept process fork failed: Resource
> temporarily unavailable
>
> I have some unusual circumstances. I'm using OpenVZ virtualization, and
> I'm using the ACL run command a lot in ACLs.
>
> The system has to run for several weeks for it to happen by lately it
> does seem to happen regularly after several week. Restarting the virtual
> server does not fix the problem. However rebooting the server does fix
> the problem, for a few weeks at least.
>
> I know this is probably an OpenVZ question and I am going to ask it over
> there. But I'm just trying to understand the problem better before I go
> to OpenVZ and ask them. for those who are familiar with OpenVZ
> virtualization my VM is wide open, no restariction bean counter show
> plenty of resources and no failcounts.
>
> UID 12 is user mail. What would cause Exim, running as root, to stop
> being able to switch to user mail? I'm wondering if the process fork
> problem might be a result of trying to switch UID as well?
>
> I know it's a weird question. Just trying to understand it a little
> better. Thanks in advance.
>

Perhaps a clue ....

I don't use UID:GID mail or mailnull at all. I DO leave them in place,
as system upgrades otherwise kvetch if they have been removed.

Early-on I'd encounter balked ability for Exim to write to logs that had
suddenly switched from ownership by <my_Exim_UID>:<my_Exim_GID> to
mail:mailnull

The culprit was a cron job coded to utilize sendmail with those UID:GID

I suspect that you have a similar 'artifact', moreover, one that is
actually *running* at the odd times that Exim bumps into it.

Moving Exim's UID:GID to ones not *ever* used otherwise will at least
make that clear, after which a 'grep -R' can find the miscreant(s) so
you can fix them also.

HTH,

Bill Hacker