Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a custom application running on an embedded x86 setup (built using buildroot and uClibc). The application has been running fine but this morning when I returned to work I discovered my process had been killed and the following output on my terminal

SAK: killed process 1008 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1009 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1011 (CX_SC3): fd#4 opened to the tty
SAK: killed process 1012 (CX_SC3): fd#4 opened to the tty

Now CX_SC3 is my process - it has multiple threads, one of which opens /dev/ttyS0 to send messages over a radio modem. The fd number is 4 for the serial port. What I don't understand is

  1. What the SAK means
  2. The PID listed above must refer to a process that was killed by my application as there is only ever one instance of my application running at a time. Is it possible that these PIDs are actually my thread IDs (as my application does run 4 threads always).
  3. If my application killed other processes, why was my application also killed?
  4. What does the opened to the tty part mean? From some research this suggests that this has something to do with a interrupt character sent to the tty that I used to start the program.

I am sure that the above is pretty obvious when you are a linux guru but I am struggling - can anyone suggest what events could have lead to the following output? My embedded setup is very small, uses busybox and runs vsftpd and very little else other than my custom application. It is vital that my application is robust so if anyone can suggest/guess as to what sequence of events could have caused the above I will be very grateful.

EDIT: In response to the comment below, if this is due to a SAK being detected, is there anything that can accidentally trigger this? Is it possible that anything being read on the serial port has triggered this? Also, how can I find the SAK combination for my system - I do not have a rc.sysinit or rc.local file anywhere in my root file system.

UPDATE: I have managed to pin this event down to the point at which my host machine shuts down. I have a serial cable between my host machine and my target device which I use to send serial data to the embedded target. When I leave the target running, but shutdown the host, my application is killed as described above. When I disconnect the serial cable prior to shutting down my host machine then my application does not get killed and runs as normal. This behaviour happens even after I have performed

echo 0 > /proc/sys/kernel/sysrq

as advised.

share|improve this question
2  
SAK in a Linux context is the Secure Attention Key. Although the document is dated, you may still find kernel.org/doc/Documentation/SAK.txt useful. –  Michael Kjörling Jun 27 '13 at 8:31
    
@MichaelKjörling Thanks for that - I will take a look. –  mathematician1975 Jun 27 '13 at 8:52
add comment

2 Answers 2

up vote 6 down vote accepted
+50

SAK in this case really means Secure Attention Key. The message you are seeing is a kernel message defined in drivers/tty/tty_io.c. SAK is a key combination which ensures secure login for a user on console. On Linux SAK ensures this by killing all processes attached to the terminal SAK is invoked on. It is expected that init will then restart the trusted login process like getty followed by login or X server with display manager.

The listed PIDs are indeed PIDs of threads of your application CX_SC3 which were killed by SAK.

fd#n opened to the tty means that the process/thread which was killed had the file descriptor n opened to the terminal on which the SAK was invoked.

In Linux there are two ways of invoking SAK:

  1. Through the magic SysRq key - typically Alt+SysRq+K (virtual terminal) or BreakK (serial console). This is not your case as you already tried to disable the magic SysRq by echo 0 > /proc/sys/kernel/sysrq and sending the BreakK sequence by accident is improbable.

  2. Through a defined key sequence (virtual terminal) or the break signal (serial console). SAK availability on a serial console is controlled by setserial.

Break signal on a serial line is continuous sending of spacing values over a time longer than the character sending time (including start, stop and parity bits). In you case it is highly probable that the condition of the Break signal appears during shutting your host machine down. Please try to turn the SAK off on your serial port on the target device by setserial:

setserial /dev/ttyS0 ^sak

You can check the SAK functionality status on the serial port by setserial -g /dev/ttyS0. When turned on it will show SAK after Flags:. For automatic setting of the option after boot see the startup scripts which on BusyBox systems are usually /etc/init.d/rcS and /etc/rc.d/S* or check /etc/inittab for other possibilities.

share|improve this answer
    
Thankyou for your answer - it is very helpful. Unfortunately, when my application is opening the serial port, the sak that I just disabled gets re-enabled. I must be setting a particular flag combination that is re-enabling the SAK on /dev/ttyS0 –  mathematician1975 Jul 1 '13 at 9:17
    
I finally managed to find a code based solution and I posted it on stackoverflow. I will add this answer here but I will accept your answer as this enabled me to identify the how and why of it all. Many thanks –  mathematician1975 Jul 1 '13 at 9:56
    
You are welcome! Unfortunately I cannot add comments anywhere except my reply. Please did you check by ioctl(fd, TIOCGSERIAL, &s_serial) immediately after open() that open() really enables SAK? For me it seems like a bug. Could you please run your application with strace to see if there is not hidden/overlooked ioctl() call somewhere? Useful is also to run catch syscall ioctl in gdb. This causes the program to stop on all ioct() syscalls. You can examine the arguments by printing the registers and stack even without symbols. en.wikipedia.org/wiki/X86_calling_conventions –  pabouk Jul 1 '13 at 20:57
    
@mathematician1975 I forgot to address you in the comment above. –  pabouk Jul 2 '13 at 8:49
    
On a run of strace I see no ioctl() calls inbetween my calls of open and ioctl using TIOCGSERIAL . It really does appear that either the open call is setting the SAK, or that the busybox implementation of setserial does not work properly. When I open /dev/ttyS0 the ASYNC_SAK bit is certainly set. –  mathematician1975 Jul 2 '13 at 11:19
add comment

I managed to resolve the issue with the help of pabouk's answer. The code based solution that I finally discovered which allows the SAK flag to be set/unset on the serial port when opening using userspace API can be found on stackoverflow here How can I disable the serial port SAK option on Linux using userspace API?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.