RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1102358 - squid does not honors /etc/security/limits.conf
Summary: squid does not honors /etc/security/limits.conf
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: squid
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Luboš Uhliarik
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 1303054
TreeView+ depends on / blocked
 
Reported: 2014-05-28 20:07 UTC by Fernando Lozano
Modified: 2016-08-16 10:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Clone Of:
: 1303054 (view as bug list)
Environment:
Last Closed: 2016-08-16 10:32:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Fernando Lozano 2014-05-28 20:07:44 UTC
Description of problem:
We increase the nofiles limit for squid user in /etc/security/limits.conf but the squid process still get the defaut limits for all users

Version-Release number of selected component (if applicable):
3.3.x/3.4.x

How reproducible:
Allways 
Steps to Reproduce:

1. Edit /etc/security/limits.conf to increase the nofiles limit for squid user, for example:

squid		hard	nofile		32768
squid		soft	nofile		32768

2. Start squid using "service squid start" and them check the current limits applied to the squid process:

[root@proxycentos ~]# cat /proc/$(cat /var/run/squid.pid)/limits 
Limit                     Soft Limit           Hard Limit           Units     
...
Max open files            1024                 4096                 files     

Actual results:
Max open files (nofile) remains ad its default value (1024) 

Expected results:
Max open files (nofile) using the increased value (32768) 

Additional info:
squid needs increased nofiles serve a moderate to high http request ratio.

Actually I tried on CentOS 6.5, using unofficial packages from squid-cache.org. But from what I saw from official packages for RHEL6 this applies to them also as they use the same /etc/init.d/squid

Comment 1 Fernando Lozano 2014-05-28 20:14:41 UTC
My workaround is putting ulimit commands inside /etc/sysconfig/squid but I guess the init.d script should honor limits.conf like the ones for other packages do. I checked /usr/share/doc/initscripts-* but found no guidance on how the init.d script should be written to get and enforce limits.conf.

Comment 3 Michal Luscon 2014-06-03 12:40:08 UTC
By default squid runs under effective user root. If you want to change its limits, you have to modified limits of user root.

Comment 4 Fernando Lozano 2014-06-03 13:58:08 UTC
No, it runs under user and group squid.

Comment 5 Michal Luscon 2014-06-03 15:15:48 UTC
There are two squid processes by default first one with real and effective uid of root and the second one with real root and effective squid. 

I am not an pam expert, so correct me if I am wrong:

documentation - A PAM module called pam_limits sets resource limits when a user authenticates using the PAM stack.

Squid calls setuid in the case of process with effective uid squid, and therefore pam limits are not applied(no authentication = pam stack is not used). If you want to raise limits just for squid process, the preferred way is to use ulimit command in init script as you already did.

Comment 6 Fernando Lozano 2014-06-03 17:50:11 UTC
Maybe I'm wrong, but squid is not the only daemon that is started as root and changes user before accepting client requests. Other RHEL services respect pam_limits, by calling runuser or other means (initscripts function daemon?).

I'm used to configure ulimits by pam_limits for all other services, for example postgresql and openldap, so why squid has to be different?

My solution (inserting calls to ulimimt in /etc/sysconfig/squid) is a hack, those files are supposed to only set shell variables.

If there's no official / clean way to make a initscript respect pam_limits I'd change the initscript to get the config from limits.conf. After all, if we already have a place to put limits for all users, why don't use it for service users?

If we have different ways to configure the same thing, I consider this a bug. Not a critical one, but a bug anyway.

Comment 7 Pavel Šimerda (pavlix) 2014-06-03 18:58:55 UTC
Please don't set state to MODIFIED. It's set by developers when a change has been made in the source control. This bug should be either ASSIGNED or CLOSED. Also when you reopen, please add more detailed information to the bug report. Please use an example of another service that works as expected and propose a specific change so it can be evaluated by Red Hat. Also there's no guarantee your request will result in an actual change, reopening the bug report doesn't change that.

Comment 8 Michal Luscon 2014-06-12 10:56:20 UTC
Ok, now I see yor point. Unfortunately, this change may break some users configurations(e.g. http_port under 1024) and therefore is not suitable for package update.

There is also a couple of other things in init file which need to be considered:

ownership of /var/log/squid/squid.out
ownership of pid file 
generation of pid file and consecutive change in start timeout routine

I think this enhancement would be more suitable for possible future rebase or new package than for minor version update.

Comment 13 albert 2015-07-28 07:15:12 UTC
After upgrading to squid-3.1.23-9, max_filedescriptors as specified in squid.conf has no effect anymore. Logfile cache.log is flooded with warning messages 'Your cache is running out of filedescriptors'

Comment 17 Tomáš Hozza 2016-08-16 10:32:00 UTC
Red Hat Enterprise Linux version 6 is entering the Production 2 phase of its lifetime and this bug doesn't meet the criteria for it, i.e. only high severity issues will be fixed. Please see https://access.redhat.com/support/policy/updates/errata/ for further information.

This issue is tracked for squid34 (Bug #1303054) component in Red Hat Enterprise Linux version 6.


Note You need to log in before you can comment on or make changes to this bug.