In CentOS 6.7, if I start emacs from a terminal session, I always see a message, "(emacs:{PID}): Gdk-WARNING **: shmget failed: error 28 (No space left on device)"
The message is also logged to .xsession-errors, and that occurs regardless of how emacs is started. The same thing occurs with SELinux in permissive mode.
Emacs version is emacs-23.1-28.el6.x86_64 .
Output from strace shows: shmget(IPC_PRIVATE, 393216, IPC_CREAT|0600) = -1 ENOSPC (No space left on device)
/proc/mounts contains: tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
and "df /dev/shm" shows: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8194164 172 8193992 1% /dev/shm
I can't identify any behavior problems that I can relate to this, but it seems that something is wrong. Any clues as to what?
On 09/03/2015 03:04 AM, Robert Nichols wrote:
In CentOS 6.7, if I start emacs from a terminal session, I always see a message, "(emacs:{PID}): Gdk-WARNING **: shmget failed: error 28 (No space left on device)"
The message is also logged to .xsession-errors, and that occurs regardless of how emacs is started. The same thing occurs with SELinux in permissive mode.
Emacs version is emacs-23.1-28.el6.x86_64 .
Output from strace shows: shmget(IPC_PRIVATE, 393216, IPC_CREAT|0600) = -1 ENOSPC (No space left on device)
/proc/mounts contains: tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
and "df /dev/shm" shows: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8194164 172 8193992 1% /dev/shm
I can't identify any behavior problems that I can relate to this, but it seems that something is wrong. Any clues as to what?
just a shot in the dark, but what do you have in /proc/sys/kernel/shmmni ?
According to man shmget: ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
On 09/03/2015 04:00 AM, Nicolas Thierry-Mieg wrote:
On 09/03/2015 03:04 AM, Robert Nichols wrote:
In CentOS 6.7, if I start emacs from a terminal session, I always see a message, "(emacs:{PID}): Gdk-WARNING **: shmget failed: error 28 (No space left on device)"
The message is also logged to .xsession-errors, and that occurs regardless of how emacs is started. The same thing occurs with SELinux in permissive mode.
Emacs version is emacs-23.1-28.el6.x86_64 .
Output from strace shows: shmget(IPC_PRIVATE, 393216, IPC_CREAT|0600) = -1 ENOSPC (No space left on device)
/proc/mounts contains: tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
and "df /dev/shm" shows: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8194164 172 8193992 1% /dev/shm
I can't identify any behavior problems that I can relate to this, but it seems that something is wrong. Any clues as to what?
just a shot in the dark, but what do you have in /proc/sys/kernel/shmmni ?
According to man shmget: ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
"cat /proc/sys/kernel/shmmni" shows 4096.
And, I find that "wc -l /proc/sysvipc/shm" shows that they are indeed all in use. A badly coded java game appears to be the culprit. It's grabbing SHM IDs by the thousands.
Thanks for the pointer. Your shot in the dark was right on target.
Robert Nichols wrote:
On 09/03/2015 04:00 AM, Nicolas Thierry-Mieg wrote:
On 09/03/2015 03:04 AM, Robert Nichols wrote:
In CentOS 6.7, if I start emacs from a terminal session, I always see a message, "(emacs:{PID}): Gdk-WARNING **: shmget failed: error 28 (No space left on device)"
The message is also logged to .xsession-errors, and that occurs regardless of how emacs is started. The same thing occurs with SELinux in permissive mode.
Emacs version is emacs-23.1-28.el6.x86_64 .
Output from strace shows: shmget(IPC_PRIVATE, 393216, IPC_CREAT|0600) = -1 ENOSPC (No space left on device)
/proc/mounts contains: tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
and "df /dev/shm" shows: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8194164 172 8193992 1% /dev/shm
I can't identify any behavior problems that I can relate to this, but it seems that something is wrong. Any clues as to what?
just a shot in the dark, but what do you have in /proc/sys/kernel/shmmni ?
According to man shmget: ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
"cat /proc/sys/kernel/shmmni" shows 4096.
And, I find that "wc -l /proc/sysvipc/shm" shows that they are indeed all in use. A badly coded java game appears to be the culprit. It's grabbing SHM IDs by the thousands.
Thanks for the pointer. Your shot in the dark was right on target.
Simple solution: vi.
mark "someone had to say it"
On Thu, September 3, 2015 1:56 pm, m.roth@5-cent.us wrote:
Robert Nichols wrote:
On 09/03/2015 04:00 AM, Nicolas Thierry-Mieg wrote:
On 09/03/2015 03:04 AM, Robert Nichols wrote:
In CentOS 6.7, if I start emacs from a terminal session, I always see a message, "(emacs:{PID}): Gdk-WARNING **: shmget failed: error 28 (No space left on device)"
The message is also logged to .xsession-errors, and that occurs regardless of how emacs is started. The same thing occurs with SELinux in permissive mode.
Emacs version is emacs-23.1-28.el6.x86_64 .
Output from strace shows: shmget(IPC_PRIVATE, 393216, IPC_CREAT|0600) = -1 ENOSPC (No space left on device)
/proc/mounts contains: tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0
and "df /dev/shm" shows: Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 8194164 172 8193992 1% /dev/shm
I can't identify any behavior problems that I can relate to this, but it seems that something is wrong. Any clues as to what?
just a shot in the dark, but what do you have in /proc/sys/kernel/shmmni ?
According to man shmget: ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
"cat /proc/sys/kernel/shmmni" shows 4096.
And, I find that "wc -l /proc/sysvipc/shm" shows that they are indeed all in use. A badly coded java game appears to be the culprit. It's grabbing SHM IDs by the thousands.
Thanks for the pointer. Your shot in the dark was right on target.
Simple solution: vi.
Also: ed. Just to mention one more, though I prefer vi ;-)
Valeri
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 09/03/2015 01:56 PM, m.roth@5-cent.us wrote:
Robert Nichols wrote:
On 09/03/2015 04:00 AM, Nicolas Thierry-Mieg wrote:
just a shot in the dark, but what do you have in /proc/sys/kernel/shmmni ?
According to man shmget: ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the system to exceed the system-wide limit on shared memory (SHMALL).
"cat /proc/sys/kernel/shmmni" shows 4096.
And, I find that "wc -l /proc/sysvipc/shm" shows that they are indeed all in use. A badly coded java game appears to be the culprit. It's grabbing SHM IDs by the thousands.
Thanks for the pointer. Your shot in the dark was right on target.
Simple solution: vi.
emacs was just the messenger. There was a real problem with the game (which has nothing to do with emacs) grabbing all the SM IDs. Simple solution is to run the game under java-1.6.0-openjdk. It only misbehaves with java-1.7.0-openjdk.
-
m.roth＠5-cent.us -
Nicolas Thierry-Mieg -
Robert Nichols -
Valeri Galtsev