Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIGTERM not handled correctly. #72

Open
ant-222 opened this issue Oct 24, 2024 · 5 comments
Open

SIGTERM not handled correctly. #72

ant-222 opened this issue Oct 24, 2024 · 5 comments

Comments

@ant-222
Copy link

ant-222 commented Oct 24, 2024

podman cannot stop your container gracefully:

StopSignal SIGTERM failed to stop container tvi in 10 seconds, resorting to SIGKILL

The detailed log is here.

By experiment, I learned that your container is to blame, for other containers respond well to the stop command, including this one, which says in the readme that many containers have this defect:

Don't handle signals properly, forcing docker to send SIGKILL to the process.

Consider fixing this, perhaps using the abovementioned container as reference.

@Guiorgy
Copy link

Guiorgy commented Oct 30, 2024

This image just executes /usr/bin/svnserve directly. Executing a shell inside the container and running ps confirms that svnserve has PID 1:

/var/opt/svn # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /usr/bin/svnserve --daemon --foreground --root /var/opt/svn

Yet strangely it doesn't react to SIGTERM.

I tried to 'fix' this in #68 by executing svnserve in the background, recording the PID it run with and explicitly sending SIGTERM to it by executing kill -s SIGTERM $PID. This looked to have sort-of worked, however, I was getting constant connection drops while the SVN server was running forcing me to revert back :/

@ant-222
Copy link
Author

ant-222 commented Nov 23, 2024

Thanks for the attempt. If you ever want to fix this, look into some Subversion containers that handle SIGTERM correctly, e.g. the one I mentioned in issue description.

@Guiorgy
Copy link

Guiorgy commented Nov 24, 2024

That repo doesn't specify a license, so leagally, it's "all rights reserved". I can't look at the contents and then use them, it would count as stealing :/

@ant-222
Copy link
Author

ant-222 commented Nov 24, 2024

I don't think it is that serious. Generally, since it is open source, you have the right to examine the code, understand how it handle SIGTERM, and then re-implement the same thing yourself, wihtout actually copy-pasting anything. It cannot be some secret game-changing know how, so referring to that source to learn about containers is fair use at most, but of course you should credit the author.

@Guiorgy
Copy link

Guiorgy commented Nov 25, 2024

No, that's not how it works. Just because something is on GitHub doesn't mean it's open source. The Unreal engine for example: "Unreal Engine, developed by Epic Games, is not open source; it is a proprietary game engine available under a source-available license.", we are not allowed to use the code there for any purpose. Any code without a specified license, as far as I know (I'm not a lawyer), is by copy right laws "all rights reserved", in other words, just like if someone uploads an art they made we can look at but not copy or sell, that code cad be looked at but not used. But if a developer working on similar code looks at it and makes similar changes, then arguably they stole that code, as such I can't do that. Just because you and I think that "it's fine as long as we attribute the creator", the laws don't care about what we think, rules are rules.

If we really want to make use of that repo, the best choice is to ask kindly the owner to choose and specify a license, hopefully a compatible with the one in this repo (yes open source licenses can be incompatible similarly preventing the use of the code).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants