This was a list of things that get your systems guy to love you. If you want your systems team to love you, make their job easier. If your systems guy creates the init script for you or just increases limits when you say, great: your systems guy already loves you and you need to do nothing.
[init script] Doesn't seem very sensible to me. Why should the programmer write this, and not the packager or sysadmin? As I programmer I already have to deal with 2949832 platforms, isn't it the packager's/sysadmin's job to make sure it integrates into your specific system provided that the programmer writes general usage instructions?
I assume that anyone who has a systems guy/team is working towards deploying to an internally controlled production environment. Production environments for the kind of software the audience of hacker news creates usually do not include 2.95 million different target systems. If they do, then your systems team is doing it wrong.
The programmer should write this because the programmer knows how their software should be started and stopped.
My software used to honor $TMPDIR until a sysadmin complained to me that it shouldn't, and should honor some other my-app-specific env var/config option instead. And he's a competent sysadmin.
The way to figure out where to write temporary files is whichever one of the following succeeds first 1) a configuration specific location that is writable, 2) the value of TMPDIR that is writable 3) /tmp. The point of this tip was to not just assume /tmp is the best place to put temporary files, and don't read some other environment variable when TMPDIR is the defacto place to specify the temporary directory via the environment. Obviously, you should favor what your local systems guy says, since you're trying to win his love, not mine. But if he's anything like me, he can appreciate this list.
My experience is that the limits are very, very often not there for a reason and the administrator didn't even know about the limits until my software hits those limits.
This is a function of different distributions, of any operating system, having different defaults. A good systems guy will be aware of defaults and be able to almost immediately know that a limit is being reached after a few questions about the problem.
One good example is the file descriptor limit. If too many clients connect to my server then the fd limit will be hit, but instead of raising the limit it would seem a considerable number of people to go my support forum to ask what's going on. I'm considering increasing the limit automatically on the next version just to get rid of the support emails.
You should be using getrlimit to determine how many file descriptors can be used and then issuing a meaningful error message ("out of file descriptors, try increasing per-process file descriptor limits, see ulimit" or something of the sort) if that limit is reached. Even better, use getrlimit to get the softlimit and the hardlimit and use setrlimit to expand to the hardlimit. If you reach that, then also issue a meaningful error message. This would save a lot of support time because your software's error messages indicate what to do, and any competent systems person will know how to increase that (or will know how to find out).
Another example is the stack size. A major user accidentally set his system stack size to 80 MB. My software creates a bunch of threads but after a while it runs out of virtual memory address because of the huge stack size. We found out about the 80 MB stack size after a while and we had to explain to them why that was a mistake. They fixed it afterwards but we wanted to avoid support questions like this again so from that point on we hardcoded our thread stack sizes to 64 KB.
This is the perfect example of what happens when one just randomly increases limits. "Mmh.. if 16k is good, then 80meg will be even better!" Someone who sets an 80meg stack size obviously doesn't know what they are doing and is just blinding increasing limits in an attempt to get rid of some problem they don't understand. This is an attempt at a bandaid solution, not a real solution.
[init script] Doesn't seem very sensible to me. Why should the programmer write this, and not the packager or sysadmin? As I programmer I already have to deal with 2949832 platforms, isn't it the packager's/sysadmin's job to make sure it integrates into your specific system provided that the programmer writes general usage instructions?
I assume that anyone who has a systems guy/team is working towards deploying to an internally controlled production environment. Production environments for the kind of software the audience of hacker news creates usually do not include 2.95 million different target systems. If they do, then your systems team is doing it wrong.
The programmer should write this because the programmer knows how their software should be started and stopped.
My software used to honor $TMPDIR until a sysadmin complained to me that it shouldn't, and should honor some other my-app-specific env var/config option instead. And he's a competent sysadmin.
The way to figure out where to write temporary files is whichever one of the following succeeds first 1) a configuration specific location that is writable, 2) the value of TMPDIR that is writable 3) /tmp. The point of this tip was to not just assume /tmp is the best place to put temporary files, and don't read some other environment variable when TMPDIR is the defacto place to specify the temporary directory via the environment. Obviously, you should favor what your local systems guy says, since you're trying to win his love, not mine. But if he's anything like me, he can appreciate this list.
My experience is that the limits are very, very often not there for a reason and the administrator didn't even know about the limits until my software hits those limits.
This is a function of different distributions, of any operating system, having different defaults. A good systems guy will be aware of defaults and be able to almost immediately know that a limit is being reached after a few questions about the problem.
One good example is the file descriptor limit. If too many clients connect to my server then the fd limit will be hit, but instead of raising the limit it would seem a considerable number of people to go my support forum to ask what's going on. I'm considering increasing the limit automatically on the next version just to get rid of the support emails.
You should be using getrlimit to determine how many file descriptors can be used and then issuing a meaningful error message ("out of file descriptors, try increasing per-process file descriptor limits, see ulimit" or something of the sort) if that limit is reached. Even better, use getrlimit to get the softlimit and the hardlimit and use setrlimit to expand to the hardlimit. If you reach that, then also issue a meaningful error message. This would save a lot of support time because your software's error messages indicate what to do, and any competent systems person will know how to increase that (or will know how to find out).
Another example is the stack size. A major user accidentally set his system stack size to 80 MB. My software creates a bunch of threads but after a while it runs out of virtual memory address because of the huge stack size. We found out about the 80 MB stack size after a while and we had to explain to them why that was a mistake. They fixed it afterwards but we wanted to avoid support questions like this again so from that point on we hardcoded our thread stack sizes to 64 KB.
This is the perfect example of what happens when one just randomly increases limits. "Mmh.. if 16k is good, then 80meg will be even better!" Someone who sets an 80meg stack size obviously doesn't know what they are doing and is just blinding increasing limits in an attempt to get rid of some problem they don't understand. This is an attempt at a bandaid solution, not a real solution.