allow interrupt generation in command line (Ctrl+C) by light-and-ray · Pull Request #15210 · AUTOMATIC1111/stable-diffusion-webui

light-and-ray · 2024-03-11T00:12:35Z

Description

Ctrl+C in console will set interrupt flag, if --allow-interrupt-generation-in-command-line cmd option is used

Checklist:

I have read contributing wiki page
I have performed a self-review of my own code
My code follows the style guidelines
My code passes tests

light-and-ray · 2024-03-11T00:15:14Z

+                            print(f"Unknown server command: {server_command}")
+                break
+            except KeyboardInterrupt:
+                if shared.cmd_opts.allow_interrupt_generation_in_command_line and shared.state.job != "" and not shared.state.interrupted:


shared.state.job != "" - for case if there's not generation in process. If is set to "" in gpu job queue wrapper after job

not shared.state.interrupted - for double pressed Ctrl+C

light-and-ray · 2024-03-11T00:15:59Z

 parser.add_argument("--unix-filenames-sanitization", action='store_true', help="allow any symbols except '/' in filenames. May conflict with your browser and file system")
 parser.add_argument("--filenames-max-length", type=int, default=128, help='maximal length of filenames of saved images. If you override it, it can conflict with your file system')
 parser.add_argument("--no-prompt-history", action='store_true', help="disable read prompt from last generation feature; settings this argument will not create '--data_path/params.txt' file")
+parser.add_argument("--allow-interrupt-generation-in-command-line", action='store_true', help="set interrupt generation flag on KeyboardInterrupt signal (Ctrl+C)")


Maybe need to do shorter flag

light-and-ray · 2024-03-11T00:29:27Z

        os._exit(0)

-    if not os.environ.get("COVERAGE_RUN"):
+    if not (os.environ.get("COVERAGE_RUN") or shared.cmd_opts.allow_interrupt_generation_in_command_line):


Maybe it's better to move sigint_handler entry inside webui.sh under except KeyboardInterrupt ?

else: if os.environ.get("COVERAGE_RUN": ... os._exit(0) print('Caught KeyboardInterrupt, stopping...') server_command = "stop" break

If yes, it's better to do in a new PR

AUTOMATIC1111 · 2024-03-11T04:48:59Z

Is there a need for this? The UI button works.

w-e-w · 2024-03-11T10:34:22Z

I also don't see much of the use case for this
also I think for those whe enable this, they people might accidentally kill the server if they sent a keyboard interrupt thinking that a job is still running, as the behavior changes based on what the server is doing at the moment

webui is not a CLI app, we have no CLI interface
so one is either using the webui or api
if using the UI use the button or hotkey to interupt
if via api then theres is the interrupt api route
adding a interupt in CLI for a non CLI app, the case would be extremely niche

light-and-ray · 2024-03-11T10:55:19Z

I really often press Ctrl+C in console to interrupt generation even if it requires server restart. CLI progress bar is much more informative. 🤷🏻‍♀️

Also the browser with this gradio session can be closed

light-and-ray · 2024-03-11T11:04:33Z

those whe enable this, they people might accidentally kill the server if they sent a keyboard interrupt thinking that a job is still running

Vice versa, I think people who didn't enable it, and used to use command line, might accidentally kill the server, thinking they were interrupting the generation.

thinking that a job is still running

It's hard to misunderstand because State prints into console if job is ended

Starting job task(7dob9zajuf7xlss)
...
Ending job task(7dob9zajuf7xlss) (3.14 seconds)

w-e-w · 2024-03-11T14:45:41Z

It's hard to misunderstand because State prints into console if job is ended

no, you set must have set you loglevel above INFO, default should be WARN
which dose not print when a job ends

in fact I believe there's no other clear indication that a job has ended
the closest thing is the progress bar (enabled by default)
but it is not guaranteed because there's still other things going on after progress bar has rached 100%

hence a slight misunderstanding
normally there is no indication of when a job is really finished the closest thing is the progress bar but that is still not a guarantee indication
and so after the progress bar without looking a the web client you can't know what stat a server is in, worse even if the progress bar is disabled

but that's besides the point my main argument is that web UI is not a CLI app
for a none CLI app if it has a terminal, the termal is normally only for info and for kiling the process by sending a keyboard interupt or when the termianl is closed

the only time that I can see people accidentally killing the server with the keyboard interrupt is when they're actually trying to use ctrl + c to copy text

light-and-ray · 2024-03-11T14:57:06Z

no, you set must have set you loglevel above INFO, default should be WARN

I have the default. I traced it after:

def setup_logging(loglevel):
    if loglevel is None:
        loglevel = os.environ.get("SD_WEBUI_LOG_LEVEL")

And it's None (argparser's default)

in fact I believe there's no other clear indication that a job has ended

But I didn't make new feature by default for everyone :( Only if --allow-interrupt-generation-in-command-line

w-e-w · 2024-03-11T14:57:53Z

too be honest I don't really care if this gets merged or not as this is an opt-in feature
I just feel the use case is very niche

too slow to edit this into the end of last message before you replied

w-e-w · 2024-03-11T15:02:55Z

the default loglevel for python is wanring
https://docs.python.org/3/howto/logging.html
so irrc if it is set to none it should be warn by default
so likey you have some configuration some overrides it

light-and-ray · 2024-03-11T15:12:40Z

I've found. Deoldify extension overrides it. Will make PR to them

Also to consider your notice I can add enabling loglevel.INFO for shared_state logger if this flag provided

light-and-ray · 2024-03-11T15:14:40Z

Also there is an other use-case: if my laptop discharged or android killed browser how it likes to do while a big generation, it's possible to interrupt without shutting down the server

w-e-w · 2024-03-11T16:10:36Z


 log = logging.getLogger(__name__)
+if shared.cmd_opts.allow_interrupt_generation_in_command_line:
+    log.setLevel(logging.INFO)


don't do this
this is bad
ie I set it log level to debug and hear you force it to INFO
this is not the way to solve it

I can check are cmd opt and env var None, and do it only in this case. Would it be okay?

about this 2 line of code, I am just saying that you should change set the loglevel for the user
that like adding a SpenserCai/sd-webui-deoldify#60 issue but in base webui

as for this PR
I made my point already
I don't think adding a CLI gen interrupt is constituent with with webui as it is a none CLI application
I still think the use case is very niche

that like adding a SpenserCai/sd-webui-deoldify#60 issue but in base webui

In this issue extension sets global logger level, as I see. In my case log = logger.getLogger(__name__), so it's changed only for this file

upd yes, I had HTTP logs (And didn't know how to remove them) before deoldify fix, and it disappeared. After this shared_state logger came back only job logs. So it's not globally. I will push commit to not override if user set cmd flag of env variable

w-e-w · 2024-03-11T16:11:10Z

Also there is an other use-case: if my laptop discharged or android killed browser how it likes to do while a big generation, it's possible to interrupt without shutting down the server

..... the reconnect function seem to be broken

light-and-ray · 2024-03-11T18:06:36Z

If I understand you right, you are talking about the vortex emoji button next to styles. I saw it few times, but it works only for completed generations as I understand. And it's unstable, I never relied on it. Or did you mean my patch broke something?

w-e-w · 2024-03-11T18:53:28Z

If I understand you right, you are talking about the vortex emoji button next to styles. I saw it few times, but it works only for completed generations as I understand. And it's unstable, I never relied on it. Or did you mean my patch broke something?

the restore porgress button is somehow "slightly" broken between 1.7 and 1.8 (nothing to do with this PR)
I just made a fix just now

fix "Restore progress" button #15221

unstable

really, seem to be very stable for me

I added in the fix PR so that if when you use it reconnect it also show the interrupt | skip if the server is still working on the job

… variable

AUTOMATIC1111 · 2024-03-16T06:50:49Z

My decision is, if you want this, make a script/extension. If something is needed from webui (callbacks) for this, we can add them.

light-and-ray · 2024-03-16T08:10:43Z

Okay! I will make callbacks for interruption signal, and turn it into an extension

allow interrupt generation in command line

674dfe3

light-and-ray requested a review from AUTOMATIC1111 as a code owner March 11, 2024 00:12

light-and-ray commented Mar 11, 2024

View reviewed changes

logging.INFO for State if allow ctrl+C

f8ea261

light-and-ray mentioned this pull request Mar 11, 2024

fix logger level SpenserCai/sd-webui-deoldify#60

Merged

w-e-w reviewed Mar 11, 2024

View reviewed changes

w-e-w mentioned this pull request Mar 11, 2024

fix "Restore progress" button #15221

Merged

4 tasks

dont override shared_state log level if user provided cmd flag or env…

3c99cf1

… variable

light-and-ray closed this Mar 16, 2024

Conversation

light-and-ray commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist:

Uh oh!

light-and-ray Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

light-and-ray Mar 11, 2024

Choose a reason for hiding this comment

Uh oh!

light-and-ray Mar 11, 2024

Choose a reason for hiding this comment

Uh oh!

light-and-ray Mar 12, 2024

Choose a reason for hiding this comment

Uh oh!

AUTOMATIC1111 commented Mar 11, 2024

Uh oh!

w-e-w commented Mar 11, 2024

Uh oh!

light-and-ray commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

light-and-ray commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

w-e-w commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

light-and-ray commented Mar 11, 2024

Uh oh!

w-e-w commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

w-e-w commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

light-and-ray commented Mar 11, 2024

Uh oh!

light-and-ray commented Mar 11, 2024

Uh oh!

w-e-w Mar 11, 2024

Choose a reason for hiding this comment

Uh oh!

light-and-ray Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

w-e-w Mar 11, 2024

Choose a reason for hiding this comment

Uh oh!

light-and-ray Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

w-e-w commented Mar 11, 2024

Uh oh!

light-and-ray commented Mar 11, 2024

Uh oh!

w-e-w commented Mar 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AUTOMATIC1111 commented Mar 16, 2024

Uh oh!

light-and-ray commented Mar 16, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

light-and-ray commented Mar 11, 2024 •

edited

Loading

light-and-ray Mar 11, 2024 •

edited

Loading

light-and-ray commented Mar 11, 2024 •

edited

Loading

light-and-ray commented Mar 11, 2024 •

edited

Loading

w-e-w commented Mar 11, 2024 •

edited

Loading

w-e-w commented Mar 11, 2024 •

edited

Loading

w-e-w commented Mar 11, 2024 •

edited

Loading

light-and-ray Mar 11, 2024 •

edited

Loading

light-and-ray Mar 11, 2024 •

edited

Loading

w-e-w commented Mar 11, 2024 •

edited

Loading