-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been trying to change the 'ulimit -l' setting, max locked
memory, for non root users. Google has not been of great help, as it
seems all the answers I find concern PAM settings.

If I create the line:
breed M65535
in /etc/limits with 600 perms

then if I (breed) log in in a console, then ulimit -l shows 65535
and all is well.

If I startx then xterms/Eterms etc also have correct ulimit -l
values.

Unfortunately, if I go to runlevel 4, and enter X via kdm, then all
my xterm/Eterm windows show ulimit -l values of 32. If I then 'su -
breed' then the value of 65535 is available.

Does anyone have any suggestion on how to change the default ulimit
- -l value in X if started by kdm?

I hope I'm missing something obvious...

This is on Slackware 11, freshly installed on a new Core2 laptop. I've
been trying to get all the non-standard apps I use set up, and
gringotts segfaults if it can't allocate enough locked memory.

Under kdm's X I have to su - breed, then start gringotts because the
menu entry won't work. Whatever environment the menu-spawned
gringotts has is too small (32K).

Under startx's X, the menu item works, ulimit values respect the
/etc/limits file.

Hopefully, this made sense...

Thanks for any suggestions,
Brad



-----BEGIN PGP SIGNATURE-----

iD8DBQFFi+9gkDp4KjYna1ARAiUFAJ9iTFN40U5kqhZ0+BSzt5 OWl/B/pQCgrFWr
LZvJ7kNTtJSlBAyvd2D7904=
=RCph
-----END PGP SIGNATURE-----

Bradley Reed <reedb@compuserve.com> wrote:
> If I create the line:
> breed M65535
> in /etc/limits with 600 perms

I am really not familiar with /etc/limits as I haven't seen any such file
on any Slackware up to 10.2 and I have no Slackware 11 machine to look at
right now. However, from your description of the problem I think I know
what the problem is.

> then if I (breed) log in in a console, then ulimit -l shows 65535 and
> all is well.

By logging in to a console you have a login shell which has run your login
scripts.

> If I startx then xterms/Eterms etc also have correct ulimit -l values.

Any terminals in X will inherit environment variables from the process
that started the terminal. If the terminal runs a login shell that shell
might get some variables overwritten by your login scripts.

> Unfortunately, if I go to runlevel 4, and enter X via kdm, then all my
> xterm/Eterm windows show ulimit -l values of 32.

When loggin in via kdm you have not logged in by a login shell and your
login scripts like ~/.profile or ~/.login has not been run. Unless your
terminla windows are setup to be login shells they won't run your login
scripts either.

> If I then 'su - breed' then the value of 65535 is available.

By giving the argument "-" to su you make the shell a login shell which
will run your login scripts. See
http://www.die.net/doc/linux/man/man1/su.1.html

> Does anyone have any suggestion on how to change the default ulimit - -l
> value in X if started by kdm?

If we correctly have identified the problem I think that the easiest
solution is to make sure that your terminal windows behave as login
shells. The easiest way to accomplish this is probably to add the
following line to ~/.Xresources

*loginShell: True

At least on the Slackware systems I have seen /etc/X11/xdm/Xsession makes
sure that xrdb reads .Xresources when logging in with kdm.

regards Henrik

--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 22 Dec 2006 22:13:51 +0100, Henrik Carlqvist wrote:
n Fri, 22 Dec 2006 22:13:51 +0100, Henrik Carlqvist wrote:
> Bradley Reed <reedb@compuserve.com> wrote:
>> If I create the line:
>> breed M65535
>> in /etc/limits with 600 perms
>
> I am really not familiar with /etc/limits as I haven't seen any
> such file
> on any Slackware up to 10.2 and I have no Slackware 11 machine to
> look at
> right now. However, from your description of the problem I think I
> know
> what the problem is.

Thanks for your reply. You seem to understand part of the problem,
but you didn't suggest a way I could achieve what I was asking.
>
>> then if I (breed) log in in a console, then ulimit -l shows 65535
>> and
>> all is well.
>
> By logging in to a console you have a login shell which has run
> your login
> scripts.
>

Agreed.

>> If I startx then xterms/Eterms etc also have correct ulimit -l
>> values.
>
> Any terminals in X will inherit environment variables from the
> process
> that started the terminal. If the terminal runs a login shell that
> shell
> might get some variables overwritten by your login scripts.
>

Ok. I logged in at console, /etc/limits was honored, X inherits
correct ulimit values. This is good.

>> Unfortunately, if I go to runlevel 4, and enter X via kdm, then
>> all my
>> xterm/Eterm windows show ulimit -l values of 32.
>
> When loggin in via kdm you have not logged in by a login shell and
> your
> login scripts like ~/.profile or ~/.login has not been run. Unless
> your
> terminla windows are setup to be login shells they won't run your
> login
> scripts either.

This may or may not be relevant. ulimit settings are not something a
non-root user may increase. My ~/.bash_profile or ~/.login cannot
set ulimit to my desired value, only root can do that. When logging
in via kdm /etc/limits is NOT honored. My environment in my WM does
not have the values set in /etc/limits, but rather some smaller
default value. This I wish to change.


>> If I then 'su - breed' then the value of 65535 is available.
>
> By giving the argument "-" to su you make the shell a login shell
> which
> will run your login scripts. See
> http://www.die.net/doc/linux/man/man1/su.1.html
>

Yes, I understand the difference between su and su - .

>> Does anyone have any suggestion on how to change the default
>> ulimit - -l
>> value in X if started by kdm?
>

This is my main question.

> If we correctly have identified the problem I think that the
> easiest
> solution is to make sure that your terminal windows behave as
> login
> shells. The easiest way to accomplish this is probably to add the
> following line to ~/.Xresources
>
> *loginShell: True

This may make terminal windows in X start up with the right values,
but the overall environment, or at least the one my WM is running
in, is still wrong. I can't start programs from the start menus and
have them have the right ulimit settings.

> At least on the Slackware systems I have seen
> /etc/X11/xdm/Xsession makes
> sure that xrdb reads .Xresources when logging in with kdm.
>

If only I knew where the default ulimit settings were being set.

grep -R for ulimit|ULIMIT has the only mention (in /etc/login.defs)
commented out. kdmrc doesn't seem to have any promising clues
either.

man 5 passwd has some hints about setting ulimits, but none are
currently set. Maybe the default ulimits are set when the kernel is
built?

I created a limits.sh in /etc/profile.d/ setting ulimit -l 65535,
this too doesn't affect the environment in a kdm spawned WM.

I may just have to stop using kdm...just use startx, as it works.

Thanks,
Brad


-----BEGIN PGP SIGNATURE-----

iD8DBQFFjJpjkDp4KjYna1ARAupPAJoDp4xhUb3mj5KWa4K8oO on51IlNwCdFDbx
LnfisdJhSv21CNMQOPDgP6U=
=mlFb
-----END PGP SIGNATURE-----

"Bradley Reed" typed:
> If only I knew where the default ulimit settings were being set.
>
> grep -R for ulimit|ULIMIT has the only mention (in /etc/login.defs)
> commented out. kdmrc doesn't seem to have any promising clues
> either.

I would think the default ulimit setting is configured from within
/etc/login.defs. For example, there are two separate settings related to
ulimit in /etc/login.defs:

#
# Enable setting of ulimit, umask, and niceness from passwd gecos field.
#
QUOTAS_ENAB yes

# Login configuration initializations:
#
# UMASK Default "umask" value.
# ULIMIT Default "ulimit" value.
#
# The ERASECHAR and KILLCHAR are used only on System V machines.
# The ULIMIT is used only if the system supports it.
# (now it works with setrlimit too; ulimit is in 512-byte units)
#
# Prefix these values with "0" to get octal, "0x" to get hexadecimal.
#
UMASK 022
#ULIMIT 2097152

Do note the BUGS section of login.defs(5), although I doubt if that
applies to your situation:

Much of the functionality that used to be provided by the shadow
password suite is now handled by PAM. Thus, /etc/login.defs is no
longer used by programs such as login(1), passwd(1) and su(1). Please
refer to the corresponding PAM configuration files instead.

--
Ayaz Ahmed Khan

It is impossible to defend perfectly against the attack of those who
want to die.

Bradley Reed <reedb@compuserve.com> wrote:
>If only I knew where the default ulimit settings were being set.

read /sbin/initscript.sample, put your ulimit commands in there and change
it to /sbin/initscript

Bradley Reed <reedb@compuserve.com> wrote:
>If only I knew where the default ulimit settings were being set.

read /sbin/initscript.sample, put your ulimit commands in there and rename
it to /sbin/initscript

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 23 Dec 2006 09:53:04 +0000 (UTC), Petri Kaukasoina wrote:
> Bradley Reed <reedb@compuserve.com> wrote:
>>If only I knew where the default ulimit settings were being set.
>
> read /sbin/initscript.sample, put your ulimit commands in there and rename
> it to /sbin/initscript
>

This looks VERY promising....THANKS!

Brad



-----BEGIN PGP SIGNATURE-----

iD8DBQFFjQ8lkDp4KjYna1ARAsMaAKCe6pC4fKLJ6SBjEK+qfm re8tr9ZgCdEu3f
7JDUzrz1HDth5IhjzFdeN88=
=Da5N
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 23 Dec 2006 10:43:23 +0500, Ayaz Ahmed Khan wrote:
> "Bradley Reed" typed:
>> If only I knew where the default ulimit settings were being set.
>>
>> grep -R for ulimit|ULIMIT has the only mention (in /etc/login.defs)
>> commented out. kdmrc doesn't seem to have any promising clues
>> either.
>
> I would think the default ulimit setting is configured from within
> /etc/login.defs. For example, there are two separate settings related to
> ulimit in /etc/login.defs:
>

Yes, but they are commented out...
> #
> # UMASK Default "umask" value.
> # ULIMIT Default "ulimit" value.
> #
> # Prefix these values with "0" to get octal, "0x" to get hexadecimal.
> #
> UMASK 022
> #ULIMIT 2097152
>
> Much of the functionality that used to be provided by the shadow
> password suite is now handled by PAM. Thus, /etc/login.defs is no
> longer used by programs such as login(1), passwd(1) and su(1). Please
> refer to the corresponding PAM configuration files instead.
>
Yes, but this is Slackware, not Ubuntu, Mandriva, Suse, or what have
you. Slackware doesn't use PAM.

Brad


-----BEGIN PGP SIGNATURE-----

iD8DBQFFjQ/ekDp4KjYna1ARAkLTAJ0aR3c8s0Ai5x0a4DTeiWABxjDtEACfe 5mw
N8WVahsAm7HBx/dI7llZ9/o=
=9K3q
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 22 Dec 2006 08:44:48 -0600, Bradley Reed wrote:
>
> I have been trying to change the 'ulimit -l' setting, max locked
> memory, for non root users. Google has not been of great help, as it
> seems all the answers I find concern PAM settings.
>
Petri Kaukasolna's suggestion worked great.

I copied /sbin/initscript.sample to /sbin/initscript and put the
desired ulimit command in it. Now the X environment started by kdm
has the right ulimt values, and programs started from my WM's start
menus also have the right default environments.

Thanks,
Brad



-----BEGIN PGP SIGNATURE-----

iD8DBQFFjSeMkDp4KjYna1ARAuMDAJ9y3ckno5t+Vl8CGR9mkt 8+0yKydQCeJZaY
mIbLy70i7VDP+lwMGmCm2P8=
=n9N2
-----END PGP SIGNATURE-----