1/8/2023 0 Comments Keepassxc waitI'll probably poke through the sources to see what I can find so I can make a more educated guess than "general linux programming" I'm not really sure how the signals are handled but if the cause is the minimize on close setting. Killing.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Killing process 4843 (keepassxc) with signal SIGKILL.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Killing process 5104 (QDBusConnection) with signal SIGKILL.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Killing process 5111 (gmain) with signal SIGKILL.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Killing process 5113 (gdbus) with signal SIGKILL.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Failed with result 'timeout'.Īpr 27 06:12:08 Valhalla systemd: Stopped Session 2 of user cocaine_johnssonĪs a slight aside, you almost certainly know this already but I'd rather mention it just in case than omit important information: whatever signal handler was defined last overwrites the previous one, so if some library sets a handler for SIGTERM (e.g SDL2) you can override that by invoking signal() yourself for the appropriate signal(s) The signature for a signal handler function is void signal_handler(int signum), you can make one that doesn't take parameters but that is UB iirc.Īt least that's what I'd infer, relevant journalctl output:Īpr 27 06:09:08 Valhalla systemd: rvice: Succeeded.Īpr 27 06:09:12 Valhalla systemd: rvice: Succeeded.Īpr 27 06:09:12 Valhalla systemd: Stopped Light Display Manager.Īpr 27 06:09:12 Valhalla systemd: Stopping Getty on tty1.Īpr 27 06:09:12 Valhalla systemd: Succeeded.Īpr 27 06:09:12 Valhalla systemd: Stopped Getty on tty1.Īpr 27 06:09:12 Valhalla systemd: Removed slice system-getty.slice.Īpr 27 06:12:08 Valhalla systemd: session-2.scope: Stopping timed out. Probably in this case it would be worthwhile to trap SIGTERM, if there is unsaved data either prompt the user to save via gui or just flush to disk for them (or assume they didn't want to save, whatever floats your boat). Though init's shutdown job will almost certainly use SIGTERM followed by waiting for some timeout (probably 120s, at least on most systemd based environments) and then forcefully ending you with SIGKILL. You might also be interested in SIGINT, i.e keyboard interrupt (typically CTRL+C from controlling terminal), these are generally the ones most likely to be used to terminate the application. This is sometimes desirable but for correct shutdown it's worthwhile handling SIGTERM specially, maybe SIGABRT too (though in my experience that shouldn't be necessary unless dealing with poorly coded abort-zealous libraries) Notably on virtually any *nix platform you can manually override the SIGTERM handler as such (C, also legal C++ refer to your language of choice's manual if different) signal(SIGTERM, signal_handler) //signal_handler is void (*)(int signum), if using something like SDL2 it will by default trap a few different signals as well as WM_DELETE_WINDOW in the SDL_QUIT event. On system shutdown, do we receive a WM_DELETE_WINDOW or a SIGTERM? I'd suspect we'd receive a SIGTERM since init doesn't really know or care what is and isn't an X-client. KeePassXC 2.5.4, kernel 5.6.6 on Arch running AwesomeWM. Operating system: Debian GNU/Linux 10 (buster) Keepassxc does that since at least version 2.3.x Debug Info Killing.Īpr 15 10:51:43 RMMbook systemd: session-3.scope: Killing process 1496 (keepassxc) with signal SIGKILL.Īpr 15 10:51:43 RMMbook systemd: session-3.scope: Failed with result 'timeout'. In the log it looks like that:Īpr 15 10:51:43 RMMbook systemd: session-3.scope: Stopping timed out. So I get the nice message of Systemd waiting for a stop job, for 90 seconds. (probably ignoring the kill signal? or whatever is send). When rebooting or shuting down the computer, keepassxc should quit properly.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |