Peter Eisentraut's questions

The OOM killer on Linux wreaks havoc with various applications every so often, and it appears that not much is really done on the kernel development side to improve this. Would it not be better, as a best practice when setting up a new server, to reverse the default on the memory overcommitting, that is, turn it off (vm.overcommit_memory=2) unless you know you want it on for your particular use? And what would those use cases be where you know you want the overcommitting on?

As a bonus, since the behavior in case of vm.overcommit_memory=2 depends on vm.overcommit_ratio and swap space, what would be a good rule of thumb for sizing the latter two so that this whole setup keeps working reasonably?

How can one set it up so that su to the same user that is currently logged in, that is

foo$ su -c 'something' foo

does not require a password? This wouldn't add or remove any security, as it should be a noop.

The reason for wanting this is that I would like to have a class of users "below" root that can administer some specific services on the machine that run under that user, e.g., news or mysql (inspect their data, change the configuration, restart, etc.). Those users would get sudo rights to that account, and that usually works well, except that the init scripts in some cases call

su -c 'start_daemon ...' daemonuser

and that brings down this scheme. Of course, I can change the init scripts or add additional sudo permissions, but I would like to avoid these sort of exceptions, because they are a mess to maintain in the long run.

The configuration for su is in PAM, so the right magic possibly lies there.