7 ms·

I'm sure I could come up with some more. Please do. This was very instructive.

by pig 16y ago

thwarted 16y ago
Learn about ipcs and ipcrm. It seems few people actually use SysV IPC stuff these days, but software you use, like apache, uses it, and if you stop/kill apache wrong, it leaves semaphores around. There is both a per-user and per-system limit to how many can be created. Related to the above, learn what possible error results are from system calls. ENOSPC, which expands to "No space left on device", is a possible errno value from calling semget. This doesn't mean "/tmp is full". Read man pages. Use man -k. Don't ask to have Some Random Editor(tm) installed on every system. Learn vim or emacs. Know how to NFS mount from your OSX machine. Be familiar with setting up the autofs/automounter on OSX. Know when and how to use the -L, -R, -g, -A, and -t ssh options. Don't give things cute names, give them meaningful names. If it runs as a daemon, consider ending the name with a d. If it's a daemon, give it the ability to daemonize itself. It's fragile to play weird shell tricks to make something daemonize that can't do it. If it's a daemon, make a mode where it can run in the foreground for debugging purposes. Know how to use strace. Know how to use ltrace and ldd. Set SO_REUSEADDR on listening sockets. Use IM to ask throwaway questions. Don't start conversations with "can I ask you question?" Don't expect a response right away. Read emails from me, even if they look long. Ask about things you don't understand. If there isn't a package for something that you need, install it into your home directory first, test it, test your code with it, before you ask it to be packaged and installed. Don't skirt the firewall. Know how to change your hosts file as a debugging aid. Challenge us.
- FooBarWidget 16y ago
  > SysV IPC Which I find incredible stupid. The system should have support garbage collection of shm files from the beginning. It's almost impossible to write software that properly cleans up things like Unix domain sockets, FIFO files and shm files when killed by SIGKILL. The best solution that I've found so far is putting garbage collection code in the admin tools. When you run the admin tool for querying the status of the server, it'll check for stale resource files and delete them.
  - thwarted 16y ago
    Agreed, there should be some better way to see which of sysv ipc resources are actually in use currently. All of these are supposed to be persistent (you can reattach to a shared memory segment later on). Considering that they are persistent, they need to be cleaned up just like another much more common resource: files on the filesystem. There is no built in support for garbage collection of files either. I find the whole key and id thing to be a somewhat weird part of sysv ipc too, but it does allow you to consistently reattach to existing resources and avoid some collisions, but it just moves the identifier collision management from ints to key_ts, or with ftok(3), to file paths. See the NOTES section for ftok(3). However, I didn't design this stuff, I just manage and maintain it.

I'm sure I could come up with some more. Please do. This was very instructive.

by pig 16y ago

I'm sure I could come up with some more. Please do. This was very instructive.

Learn about ipcs and ipcrm. It seems few people actually use SysV IPC stuff these days, but software you use, like apache, uses it, and if you stop/kill apache wrong, it leaves semaphores around. There is both a per-user and per-system limit to how many can be created. Related to the above, learn what possible error results are from system calls. ENOSPC, which expands to "No space left on device", is a possible errno value from calling semget. This doesn't mean "/tmp is full". Read man pages. Use man -k. Don't ask to have Some Random Editor(tm) installed on every system. Learn vim or emacs. Know how to NFS mount from your OSX machine. Be familiar with setting up the autofs/automounter on OSX. Know when and how to use the -L, -R, -g, -A, and -t ssh options. Don't give things cute names, give them meaningful names. If it runs as a daemon, consider ending the name with a d. If it's a daemon, give it the ability to daemonize itself. It's fragile to play weird shell tricks to make something daemonize that can't do it. If it's a daemon, make a mode where it can run in the foreground for debugging purposes. Know how to use strace. Know how to use ltrace and ldd. Set SO_REUSEADDR on listening sockets. Use IM to ask throwaway questions. Don't start conversations with "can I ask you question?" Don't expect a response right away. Read emails from me, even if they look long. Ask about things you don't understand. If there isn't a package for something that you need, install it into your home directory first, test it, test your code with it, before you ask it to be packaged and installed. Don't skirt the firewall. Know how to change your hosts file as a debugging aid. Challenge us.

FooBarWidget 16y ago
> SysV IPC Which I find incredible stupid. The system should have support garbage collection of shm files from the beginning. It's almost impossible to write software that properly cleans up things like Unix domain sockets, FIFO files and shm files when killed by SIGKILL. The best solution that I've found so far is putting garbage collection code in the admin tools. When you run the admin tool for querying the status of the server, it'll check for stale resource files and delete them.
- thwarted 16y ago
  Agreed, there should be some better way to see which of sysv ipc resources are actually in use currently. All of these are supposed to be persistent (you can reattach to a shared memory segment later on). Considering that they are persistent, they need to be cleaned up just like another much more common resource: files on the filesystem. There is no built in support for garbage collection of files either. I find the whole key and id thing to be a somewhat weird part of sysv ipc too, but it does allow you to consistently reattach to existing resources and avoid some collisions, but it just moves the identifier collision management from ints to key_ts, or with ftok(3), to file paths. See the NOTES section for ftok(3). However, I didn't design this stuff, I just manage and maintain it.