1

I am connected to remote machine Linux RH6 directly via ssh (key imported on server), when I execute a shell script with arguments for restarting the java service, I have a strange issue with ulimit:

  • when I manually run ./script.sh stop;./catalina.sh start I see that the number of open files is not OK (1024) as defined in system file limits.conf;
  • when a weekly job is executed which I have set up from cron, I have the correct value from limits.conf (16,384);
  • when I do /bin/su - user and then restart, I have the correct value
    also.

I need a solution to modify the script to somehow source my system value and have real login shell in the bash script and to have the correct number of open files when I need to restart the service manually.

Hard limit for current shell:

ulimit -Ha
open files                      (-n) 4096

Global:

cat /etc/security/limits.conf
oracle hard nofile 16384

Problem: when cron job is executed number of opened files is 16384 good!, when i run script from current shell ./script.sh stop; ./script.sh start i have 4096. Question is how to get 16384 when i run script manually ?

Ps editing of bashrc and bash_profile with ulimit -n <number> does not help.

Improve this question
8
  • Try /bin/su -c - user /path/to/script.sh, or add ulimit -n 16384 to your script.
    – MattBianco
    May 4, 2015 at 14:17
  • @MattBianco that will work but i need clean solution
    – klerk
    May 4, 2015 at 14:28
  • What is script.sh? What is catalina.sh? Where do you see the open files? What is the crontab your are using? How is Matt's solution "not clean"? What would a "clean" solution require? Please edit your question and clarify
    – terdon ♦
    May 4, 2015 at 14:31
  • I see open files from java app, script.sh is killing the java pid when argument stop is there and starting java pid when argument start is there
    – klerk
    May 4, 2015 at 14:43
  • or you could try adding the ulimit -n 16384 to your .bash_profile or .bashrc to try and resolve the issue with your environment.
    – MattBianco
    May 4, 2015 at 15:10

2 Answers 2

Reset to default
1

Only root can raise the current hard limit. Presumably the default limit for that user as set in /etc/security/limits.conf is 16384, but there is something in an initialization file that sets the limit to 4096.

If you can, change this initialization file to set only the soft limit. The soft limit can be changed in either direction at any time by any user, the only constraint is that it cannot be higher than the hard limit. That is, replace ulimit -a 4096 by ulimit -Sa 4096.

What you're doing is dodgy anyway. You should probably not be running a shell as the user that runs the service, you should be doing maintenance from your account, using sudo to run commands with different privileges as necessary. So to start the service, you should not be using ./script.sh stop;./catalina.sh start but

sudo -u user ./script.sh stop; sudo -u user ./catalina.sh start

This will not run initialization files that might set the limit down.

In principle, it's possible that your system configuration sets different limits depending on how you log in, by setting different rules via PAM (/etc/pam.conf or /etc/pam.d/*). However this would be a strange, unusual configuration.

Improve this answer
0

Rather than manually running ./script.sh stop;./catalina.sh start and separately having a cronjob that does the same, use an /etc/init.d/catalina script that can configure all your limits, env vars, etc; then to start/stop, just run sudo /etc/init.d/catalina start (or stop, restart, etc); or, more simply (if available) sudo service catalina start (etc). It's somewhat error prone to start/stop processes from different env's, as you've found; putting everything into an init script will help to get processes started/stopped consistently and cleanly (and properly logged).

Edit: and, if you're not using sudo and not using init scripts, then just write this same script (as if you were creating an init script), keep it in your $HOME/bin (or wherever), and inside this script set up the env (limits, env vars, etc) as desired; call this from cron, the shell, remote ssh, puppet, etc. Later, if you want to configure this as a service, as is typically the case, this work will have already been done.

Improve this answer
4
  • i understand all this, but i can't do sudo with this account that's the reason why i am asking this question, bottom line, if possible i need solution to source properly system values (ulimit) when i do it manually like cron does. Only solution is maybe wrapper script for now but it is rough and i dont want that if not needed.
    – klerk
    May 7, 2015 at 11:27
  • Can you add a non-root sudo entry? The idea is sudo itself provides a pristine environment, so take advantage of that. I think Giles' approach is the right one.
    – Otheus
    May 7, 2015 at 12:55
  • i can add sudo before script it will work, but i want to somehow avoid that if possible ?
    – klerk
    May 7, 2015 at 13:24
  • I was assuming that these processes would be run as a different user (e.g,. tomcat started as another "web" user, and a startup script doing "sudo -u {tomcat}" or such). If you're not running things as different users (and not using sudo), then just do everything else the same: as you say, "Only solution is maybe a wrapper script..." ; yes, that would be the same as the init.d script, which sets up the environment as you need it, the same for cron, your shell, init.d, etc; relying on (or hoping that) bashrc, profile, cron, etc will be consistent is (from experience) impractical.
    – michael
    May 8, 2015 at 1:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .