Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 days ago.
Improve this question
On a usual recent Linux desktop (in my case: Debian 11 with X11 and Plasma), imagine that I start a process which turns into a background process by fork()ing and then calling setsid().
(in my particular case, all that happens inside the execution of something like subprocess.Popen(["sleep", "999999"], start_new_session=True) in Python, if I understand it correctly)
I can see that my process survives a logout. That's fine. But when I shutdown or reboot my machine, at some point it gets terminated, right? I assume that it will receive SIGTERM from somewhere, and SIGKILL a bit later if still alive. SIGHUP would not surprise me either. Is that correct?
But what part of the system exactly does that? What are the modalities? When does that happen (i.e. what parts of the system can I assume to be still operating at that time)? How much time does the process have before getting killed? And who exactly does that (systemd? the display manager? something else?)?
I tried to handle SIGTERM in my Python code, and to make some cleanup there. It seems to work partially, but gets interrupted. The entire shutdown procedure takes just a few seconds, so it's not stuck. I tried finding something in journalctl -xb -1, but it's large, and I was not able to find any interesting traces.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
This post was edited and submitted for review 11 months ago and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
I read a forum post some time ago (unfortunately I don't have the link any more), that instructed me to invoke "reboot -h now" in Bash on a Raspberry Pi running the Unix-based Raspbian operating system.
It is supposed to reboot the system immediately.
What caught my eye though, was the -h switch.
There is no mention in the man page for the reboot function and I can't find anything about the switch on the Internet.
Since invoking the shutdown function together with the switch -h does not throw any errors, I have to assume, that the associated daemon (I believe it's systemd) does know the switch, making me conclude that it might be a deprecated feature, which is by default ignored today since it isn't needed any longer.
I also have to mention, that since I only used Raspberry Pi's with Linux up until now, I have no idea, whether this might even be a Raspberry-specific argument.
What is that specific switch supposed to do?
It was for stopping hard disks before restarting. The reboot/poweroff/halt was instantaneous, and data could be lost. sysvinit halt.c#L16 and sysvinit htdown.c.
Nowadays, it's just ignored by systemd systemd systemctl-compat-halt.c:
case 'i':
case 'h':
/* Compatibility nops */
break;
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
There's a complicated script that starts other scripts. It all runs for about 6 hours. But I've noticed that one or two child scripts are being killed from time to time.
All I get is a line in log saying that script is killed.
How do I get some info on who kills it? Is it possible?
The nature of killing a process does not provide an originator. A bit is set in a kernel structure associated with the process, indicating a signal is pending. If the signalling process does not indicate it is signalling, there's no way to find out.
Some processes do in fact announce their signalling. On Linux, the OOM (Out of Memory) killer might write a log entry to /var/log/messages. If the reason for the signalling to your script is an OOM condition, this might be the place to look.
See also Who "Killed" my process and why?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Can pkill guarantee the following situation never happens:
I use pkill -f "abc"
pkill finds process by name and remembers pid
process ends
Linux starts a new process with the same pid
pkill kills the process started at step 4
Pids do wrap and do eventually get reused. However, pids assigned to recently running processes are not soon reused.
so, in practice the problem you're worried about never happens.
It is theoretically possible as far as I can tell.
However, that would mean that
pkill was running slow enough that a whole bunch of new process IDs could get allocated between finding the process and killing it
the rest of the system was running fast enough to create all those processes and get to a point where the recently used pid was freed.
As pointed out in comments, either you are root or the process is running as the same user
It's possible there is some way of attacking pkill so it's that slow, but such an attack would almost certainly be a kernel bug.
I've never been in a situation where worrying about this problem was the right design decision.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm looking for a standard way or best practice to keep a daemon started by an init.d shell script alive.
Or even better, is there a way to keep it alive directly from /etc/init.d?
Specifically, I have a daemon called dtnd with and infinite loop that looks for down precess, if there are any, the daemon wake up them again. Also, I use the start-stop-daemon tool in order to let the precess by run from a given system user.
I want to run this dtnd daemon from startup. In order to achieve this behavior I created a init.d script that "wraps" the dtnd file using start, stop and status commands.
I have 2 questions that I will like to solve:
Is there a way to achieve keeping alive some process from init.d shell script. Is an standard/best way practice?
It's recommended to keep a daemon alive with infinite loop? I guess it's better to use some tool like daemon to achieve that. It's correct?
Thank you so much for your time!
You might want to use the daemon(3) library function inside the code of your daemon. You should be aware of syslog(3) (at least to log error conditions). You probably should catch gently the SIGTERM signal. Read carefully signal(7)
Server programs are often event loop based (and it is conceptually an infinite loop). You'll either use en existing event loop library (e.g. libev, libevent, glib, ...) or build your own one around a multiplexing syscall like poll(2)
Read Advanced Linux Programming and study the source code of some existing free software daemon.
Perhaps dbus is also relevant for your goals (which I don't really understand: what does "looks for down process" exactly means? You could set some limits with setrlimit(2) often invoked thru the ulimit bash builtin in some .bashrc)
There is also the #reboot entry for crontab(5), but that is not the recommended practice for system daemons (however you could use it in your user crontab file).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
What would happen if the Linux kernel deleted itself? Will there be a moment when it could no longer delete files because rm or the program used for deletion has been deleted too?
Regards.
The question is (apart from being off-topic) somewhat wrong in itself, as rm is not part of the kernel, but either a shell built-in or a separate user-level program. Admittedly, rm uses a syscall provided by the kernel, but that is irrelevant.
The kernel itself is loaded from a compressed image and locked in RAM. It does not matter whether you delete the compressed image until you reboot (which will fail with the boot loader giving you a message like "vmlinuz not found"). You have no way of removing the kernel from RAM (well, other than rebooting...).
Also, for the most part, it does not even matter whether you delete a file, including a running program's executable anyway (if we may be so daunting as to call the kernel a "program" for a moment) under Linux, because deleting a file merely removes the link, not the file. It is a Windows-typical assumption that deleting a file does evil, destructive things.
Under Unix-like systems, it is perfectly possible to delete (or replace) a program while it is running, and it will not cause any problems at all. You will remove the name in the filesystem, that's all. Any open descriptors will remain valid until the last one is closed, the original file will stay intact as-is for any observer who obtained a handle earlier, and it will be "gone" for everyone trying to get at it later.