QEMU is used by me as an emulator with PetaLinux kernel (terminal-only with -nographic option).
At the beginning QEMU initializes itself and once it's ready it boots-up the system. Usually, boot messages are printed in a terminal during the process. With that scenario everything works fine, system starts and one can login and use the system.
Then, another simple peripheral device is implemented, which similarly is initialized (printing control message to the output) and the rest goes on the same way.
The problem rises when there is a child process spawned from inside the peripheral implementation ( fork() followed by execvp() ). The main QEMU process (parent) no longer prints to the terminal output, the new process (child) only can do it. It seems like the parent process is probably still executing but loses the terminal. Without it one cannot see login prompt, so basically cannot use the system at all.
What is the reason?
I found the solution. The problem was because the child process was using SIGUSR1 to signal some event to the parent process. Apparently, QEMU itself uses SIGUSR1 so there was a collision of handlers, maybe both of them had been invoked, and somehow the parent process was freezing. Everything works fine after changing my signal to SIGUSR2. Hopefully there is no more collision with QEMU internals.
Related
Background processes don't belong to a user and a terminal, nor do daemon processes. What is the main difference between the two? If I were to write a server program, should I run it as a background process or a daemon?
When one says 'background process', it's usually in the context of a shell (like bash), which implements job control.
When a process (or a process group) is put into the background, it's still part of the session created by the shell and will still have an association with the shell's controlling terminal. The standard input/output of a background process will still be linked to the terminal (unless explicitly changed). Also, depending on how the shell exits, it may send a SIGHUP signal to all the background processes (See this answer to know exactly when). Until the shell terminates, it remains the parent of the background process.
A daemon on the other hand does not have a controlling terminal and is usually explicitly made to be a child of the init process. The standard input/output of a dare usually redirected to /dev/null
A Background process usually refers to a process which:
Another process is its parent; eg, a shell;
It has standard streams (input, output, error) connected to that parent
The most common type is when you run a shell program with a trailing &. It generally shares the shell’s output streams, but will get a signal and stop if it tries to read from its input stream.
More significantly (usually), a background process like this is still parented, so signals to that process group will continue to it. If the parent process terminates, the children will receive signals that will most likely terminate them, as well. (This is probably the biggest difference between the two for most users.)
A Daemon process is one that:
Has no parent, ie, its parent process is the system (or container) initial thread, commonly systemd (Linux), init (other Unix), or launchd? (MacOS);
Typically has its output disconnected, or connected to a log file;
Typically has its input disconnected.
Daemons are usually also written to accept the “user hung up” signal (SIGHUP), which would terminate a program if not handled, as a special instruction to re-read their configuration files and continue working.
Most often, these are processes created by some system-level facility that continue to operate completely independently of user activity (logins, logouts, and the like). Things that, themselves, handle logins (getty or gdm and the like), as well as other network-facing services (web servers, mail servers, etc) may be daemons, as well as self-monitoring services like cron, or smartd.
I'm writing a software to test some peripherals on my device.
I have to check some tty devices, so I writed a C binary that writes and reads from a given tty. It works perfectly called from command line, but it doesn't work if called from an init.d script.
Any ideas?
Login prompt appears after start-up scripts are executed - that is why they are called start-up scripts.
I am not sure changing the order would be wise and safe. I would probably wait (sleep) for a while. Just don't forget to run your program in the background mode, otherwise it'll block boot process:
my_test_tty_program &
I'm developing code for Linux, and cannot seem to kill processes when running in a Jenkins environment.
I have test script that spawns processes and cleans them up as it goes through the tests. One of the processes also spawns and cleans up one of its own subprocesses. All of the "cleanup" is done by sending a SIGINT, followed by a wait. Everything works fine with this when run from a terminal, except when running through Jenkins.
When the same exact thing is run in Jenkins, processes killed with SIGINT do not die, and the call to wait blocks forever. This wreaks havoc on my test. I could update the logic to not do a blocking wait, but I don't feel I should have to change my production code to accommodate Jenkins.
Any ideas?
Process tree killer may be your answer - https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller
In testing, this would usually work when I ran the tests from the command line, but would almost always fail when that unit test script was called from another script. Frankly, it was bizarre....
Then I realized that when I had stray processes, they would indeed go away when I killed them with SIGTERM. But WHY?????
I didn't find a 100%-definitive answer. But thinking about it logically, if the process is not attached to a terminal, then maybe the "terminal interrupt" signal (SIGINT), wouldn't work...?
In doing some reading, what I learned is that, basically, when it's a shell that executes a process, the SIGINT action may be set to 'ignore'. That make sense (to me, anyway) because you wouldn't want CTRL-C at the command line to kill all of your background processes:
When the shell executes a process “in the background” (or when another background process executes another process), the newly executed process should ignore the interrupt and quit characters. Thus, before a shell executes a background process, it should set SIGINT and SIGQUIT to SIG_IGN.
Our production code isn't a shell, but it is started from a shell, and Jenkins uses /bin/sh to run stuff. So, this would add up.
So, since there is an implied association between SIGINT and the existence of a TTY, SIGTERM is a better option for killing your own background processes:
It should be noted that SIGINT is nearly identical to SIGTERM. (1)
I've changed the code that kills the proxyserver processes, and the Python unit test code, to use the SIGTERM signal. Now everything runs at the terminal and in Jenkins.
Is there any way to list all the killed processes in a linux device?
I saw this answer suggesting:
check in:
/var/log/kern.log
but it is not generic. there is any other way to do it?
What I want to do:
list thread/process if it got killed. What function in the kernel should I edit to list all the killed tid/pid and their names, or alternitavily is there a sysfs does it anyway?
The opposite of do_fork is do_exit, here:
do_exit kernel source
I'm not able to find when threads are exiting, other than:
release_task
I believe "task" and "thread" are (almost) synonymous in Linux.
First, task and thread contexts are different in the kernel.
task (using tasklet api) runs in software interrupt context (meaning you cannot sleep while you are in the task ctx) while thread (using kthread api, or workqueue api) runs the handler in process ctx (i.e. sleep-able ctx).
In both cases, if a thread hangs in the kerenl, you cannot kill it.
if you run "ps" command from the shell, you can see it there (normally with "[" and "]" braces) but any attempt to kill it won't work.
the kernel is trusted code, such a situation shouldn't happen, and if it does, it indicates a kernel (or kernel module) bug.
normally the whole machine will hand after a while because the core running that thread is not responding (you will see a message in /var/log/messages or the console with more info) in some other cases the machine may survive but that specific core is dead. depends on the kernel configuration.
I installed a SIGSEV and SIGABRT signal handler which forks a child process that:
1. stops its parent process with SIGSTOP.
2. invokes gdb on the parent process to gather crash diagnostics.
Problem is, fork is not async signal safe on glibc thanks to ptmalloc installing pthread_atfork handlers. Now my signal handler has the potential to freeze because fork() tries to allocate memory, which in turn may grab a mutex that's already locked.
I want to work around this problem by calling the fork system call directly, bypassing any libc wrappers and therefore bypassing any atfork handlers. How do I do that? The following code works on Linux, but doesn't seem to work on OS X. It always returns the child PID, never 0, or is it supposed to do that? I'm also not sure whether I'm capturing the return value correctly because the definition is int syscall(...) but fork returns an integer of type pid_t.
pid = syscall(SYS_fork);
My app runs on many platforms, including Linux and OS X.
EDIT: fix typo: s/thread safe/async signal safe/.
On Linux, if you just want to automatically fire a debugger on software core dumping signals, you could make your core dump piping into some script, according to core(5) you just need to start your coredump_filter with a | (pipe character followed by command).
This trick avoids any extra programming (except for the script you make for that)