hugo server doesn't stop on Ctrl+C if theme name is misspelled after starting the server
#8340
Labels
Comments
rootkea
changed the title
hugo server doesn't stop on Ctrl+C if theme names is misspelled after starting the server
|
Doesn't matter even if the spelling is corrected later. Ctrl+C just doesn't stop the |
rootkea
changed the title
hugo server doesn't stop on Ctrl+C if theme names is misspelled after starting the serverhugo server doesn't stop on Ctrl+C if theme name is misspelled after starting the server
|
I started looking into this. It started with version v0.80.0 with commit cea1574 Update: It's likely a race condition, and I just noticed that Deps.Close is already deferred in Update 2: The method |
|
I (accidentally) reproduced this bug on my development machine this morning. What version of Hugo are you using (
|
|
I had a similar problem. It looks like any error that would result in a "fail to reload config" would break CTRL-C expected behavior. Change of config file detected, rebuilding site.
2021-07-07 22:02:24.482 -0300
ERROR 2021/07/07 22:02:24 Failed to reload config:
ERROR 2021/07/07 22:02:24 Module "github.com/twbs/bootstrap" not found; either add it as a Hugo Module or store it in "/home/me/Dev/work/martin/symbols-doc/themes".: module does not exist
Rebuilt in 2 ms
^C^C^C^C^C^C^C^C^C^C^C^C
Change of config file detected, rebuilding site.
2021-07-07 22:02:59.482 -0300
Rebuilt in 886 ms
^C^C^C^C^C^C^C^C^Czsh: killed hugo server --disableFastRender --environment testingVersion: 0.84.4-1 (Arch Linux) |
|
I'm having the same issue as @danisztls (Ctrl+C stops working on ANY error) with v0.89.4-AB01BA6E on Manjaro |
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 13, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel and changes less code.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 13, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 15, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 17, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 18, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 20, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Mar 26, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Apr 10, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
Apr 23, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
ptgott
added a commit
to ptgott/hugo
that referenced
this issue
May 14, 2022
If a user starts hugo server and writes to the config file in a way that renders it invalid, hugo server stops responding to SIGINTs, meaning that a user needs to send a SIGKILL to the hugo process to stop it. *commandeer.serve needs to obtain a *hugolib.HugoSites in order to close the Hugo environment. After handling signals/the stop channel, *commandeer.serve calls c.hugo() to get the *hugolib.HugoSites. This function receives from the c.created channel, which is closed when the HugoSites is ready. However, if an error took place while loading the config, c.created would never be closed, so Hugo would block on this channel even after handling SIGINT. The solution is to close c.created if we failed to load a config when rebuilding the site, then check at the end of *commandeer.serve whether the *hugolib.HugoSites is nil. If it is, we stop waiting for a HugoSites to close, and exit the hugo process. One issue that resulted from this fix was how to reset the c.created channel during site rebuilds. In the current code, this is done by assigning c.commandeerHugoState to a newCommandeerHugoState in *commandeer.fullRebuild. However, this creates a race condition, since other goroutines can be reading the value of c.created just as *commandeer.fullRebuild is attempting to reassign it. This change fixes the race condition by adding the lazy.Notifier type, which preserves the use of c.created while allowing for it to be reset in a goroutine-safe way. c.created is now a lazy.Notifier. I added this type to the lazy package because it didn't seem worth it to add a new package, but we can do this if it's cleaner. (I was thinking about using sync.Cond for this, but the approach I used is closer to the original use of the c.created channel.) Also adds an integration test for interrupting the server after fixing an invalid configuration. An earlier version of this change caused hugo server to stop exiting with a SIGINT after fixing a bad config, so I wanted to ensure that we can prevent this. Fixes gohugoio#8340
|
Unable to reproduce with v0.105.0. Fixed in v0.99.0 with #9899. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello!
hugo serversays "Press Ctrl+C to stop" but the server doesn't stop if theme name is misspelled after starting the server. The only way to exit thehugo serverprocess then is to close the terminal forcefully.Steps to reproduce:
hugo serverwith correcttheme: <theme_name>in config<theme_name>to some non-existent theme name (e.g. misspelling)Ctrl+CThe text was updated successfully, but these errors were encountered: