| 1 |
On Wed, May 8, 2013 at 4:06 PM, Chí-Thanh Christopher Nguyễn |
| 2 |
<chithanh@g.o> wrote: |
| 3 |
> You could be looking at someone trying to compromise your system through a |
| 4 |
> buffer overflow or similar vulnerability. If you enable automatic respawn |
| 5 |
> then congratulations, you just gave the attacker unlimited tries to guess |
| 6 |
> the correct address/offset for his exploit. |
| 7 |
|
| 8 |
Hence the reason it is highly use-case dependent. The same could be |
| 9 |
said of inittab restarting agetty indefinitely. |
| 10 |
|
| 11 |
You can configure rate-limiting on restarts, etc. |
| 12 |
|
| 13 |
Somebody mentioned fork-bombs and cgroups. From what I can read when |
| 14 |
a systemd restarts something it first stops it and then starts it. |
| 15 |
Stopping a unit by default involves sending SIGTERM followed by |
| 16 |
SIGKILL to the cgroup. In general your processes won't be getting |
| 17 |
away unless they're root and manipulating such things. |
| 18 |
|
| 19 |
Much of the systemd behavior is configurable though - you could |
| 20 |
configure a unit to only kill the "main" process, and for that matter |
| 21 |
you can configure how systemd figures out the PID of the "main" |
| 22 |
process. |
| 23 |
|
| 24 |
This is getting a bit off-topic though. I doubt anybody is going to |
| 25 |
want default behavior on a systemd unit to be to auto-restart, unless |
| 26 |
you're talking about stuff that already goes into inittab. If anybody |
| 27 |
wants stuff to auto-restart they'll edit their unit files (so files in |
| 28 |
/etc should override files elsewhere, or they should get config |
| 29 |
protection). |
| 30 |
|
| 31 |
Rich |
Archives