
otrs (1.0) was working fine for a several weeks until i had to reboot the machine. after the reboot the whole system is porked. every component dies while attempting to get the shared memory segment for Log.pm [line 60]: /home/otrs/Kernel/System/Log.pm line 60. $Self->{Key} = shmget($Self->{IPCKey}, $Self->{IPCSize}, 0777 | 0001000) || die $!; where does this shared memory segment get created??? ~j

Hi Jules, On Sat, Apr 05, 2003 at 07:11:06AM -0800, jules wrote:
otrs (1.0) was working fine for a several weeks until i had to reboot the machine. after the reboot the whole system is porked. every component dies while attempting to get the shared memory segment for Log.pm [line 60]:
/home/otrs/Kernel/System/Log.pm line 60.
$Self->{Key} = shmget($Self->{IPCKey}, $Self->{IPCSize}, 0777 | 0001000) || die $!;
where does this shared memory segment get created???
Try to remove the shared memory segment: shell> ipcs | grep 4096 0x02a622c6 327685 wwwrun 777 4096 0 shell> ipcrm -m 327685 And start otrs again. It looks like somebody else is blocking this shared memory segment.
~j
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Perfection is our goal, excellence will be tolerated. -- J. Yahl

"Martin Edenhofer"

Hi Jules, On Mon, Apr 07, 2003 at 12:52:30PM -0700, jules wrote:
| [...] | Try to remove the shared memory segment: | | shell> ipcs | grep 4096 | 0x02a622c6 327685 wwwrun 777 4096 0 | shell> ipcrm -m 327685 | | And start otrs again.
yep, you were right, although under my version of linux and bash (redhat 6.2) the command to remove the block was actually: $ ipcrm shm <id>
thank you very much! i'm up and running again.
do i need to take precautions when rebooting the box in the future? could it be that one of the cronjob was running when the machine was shutdown and that caused the shared memory segment to remain locked?
No, normally not. Shared memory segment are in the ram. And after rebooting the shared memory segments are empty. -=> Should work fine after rebooting! I don't know what was locking your shm.
~j
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- nohl: 12:41am up 51 days, 10:04, 6 users, load average: 0.48, 0.49, 0.40
participants (2)
-
jules
-
Martin Edenhofer