This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[proposal] Allow graceful programmatic shutdown #1192
Comments
dryajov
changed the title
[proposal] Allow graceful programmatic shutdown on windows
[proposal] Allow graceful programmatic shutdown
Jan 26, 2018
This was referenced Jan 26, 2018
@richardschneider thanks for finding that, however I don't see this endpoint anywhere in |
Seems like on win10 |
@mkg20001 hehe - yes, node correctly emulates From the docs:
It's when using |
This was referenced Jan 30, 2018
Merged
This was referenced Feb 16, 2018
Closed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's currently not possible to programmatically do a graceful shutdown of ipfs daemons on windows through the use of signals, the way it's done on Unix like systems - due to windows lack of signal support. From Node.js documentation - https://nodejs.org/api/process.html#process_signal_events.
This is an issue for applications that try to interact with the daemons programmatically such as
ipfsd-ctl
, since sending aSIGINT
to any process will not trigger a signal handler, but simply kill the process, which in turn leaves the repo locked and possibly in an inconsistent state.One possible solution would be to add some sort of explicit shutdown command (
ipfsd shutdown
) - that would shutdown the daemon. So far, I think this can be implemented either as an additional HTTP endpoint or by the presence of a 0 byte file at the root of the repo:i.e.
/api/v0/shutdown
resource - when calling the endpoint, the daemon responds with a200
or202
HTTP response code and beggins the shutdown of the daemon.jsipfs/shutdown
file - the daemon monitors the repo for the presence of this file, if its there, it will delete the file and initiate the daemon shutdownThis is just a suggestion, and if there are better/cleaner ways of achieving this, I'd love to hear about them.
Note that anything we do here, would also have to be done in the go implementation, since it affects both daemon types - // cc - @whyrusleeping @lgierth @Stebalien
The text was updated successfully, but these errors were encountered: