SAM Backup error 'Interrupted system call'

[T Mark Grundy]

The SAM backup on our server has been running for several years without any trouble.

In the last couple of weeks it has been producing the following errors.

"fbackup(9999): Interrupted system call
fbackup(2004): WARNING: reader 1: 1st read error, firstread=32768, n=0"

This repeats to the point that the temp file it is held in obviously fills up and can't take any further input, since the email report cuts off mid line.

The backup appears to complete normally, as the br_index.full file is written normally at the end of the process, which occurs at the expected time.

Nothing has been changed on the server that I am aware of. Can anyone suggest a possible cause or at least point me in the direction I should be looking.

Thanks.

[Ludovic Derlyn]

Hi

Error 32768 occurs when a largefiles is detected sometimes
Check if your mount point are mounted with option largefiles


Regards

L-DERLYN

[spex]

Mark,

You may have a bad disk. These threads should be of use:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1012153

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=943856

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=507671

PCS

[T Mark Grundy]

Ludovic.

Thanks for your reply. I've checked and all except / and one other filesystem are set to use large files.

Spex.

Thanks for that. The thought that it might be a bad or failing disk was hovering at the back of my mind. I'll try the dd test sugested in the other threads and see what it produces.

[Bill Hassell]

This may also be a shortage of shared memory for fbackup's cache of filenames and paths. Use ipcs -bmop to look at the current segments. If you usde the dreaded kill -9 on any process (including fbackup) that uses shared memory, that area is not returned and creates a shortage for the next process.

[T Mark Grundy]

Thanks Bill. It does look as if there are 3 dead processes hogging the majority of the shared memory. Is there a simple way to release this?

[Bill Hassell]

Before I give you the secret command, you need to determine the complete set of processes that share each big segment. The reason is that the initiator for the segment may have terminated normally and there are several programs that use that segment. They may not be currently attached but may still be using the segment.

Once you kinow that specific segments are no longer used, you can run ipcrm (check the man page) to remove the segment(s).