How to regain access to running applications after accidentally zapping X.org?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I just accidentally hit CtrlAltBackspace. This apparently zapped the X server. After a short flash of the screen, my window manager asked me to log in again, and I was returned to a blank slate. A quick ps -ax showed that my applications were still running, but I didn't know how to bring them back to the foreground. (fg <foo> didn't.)
How can I regain access to running applications after accidentally zapping X.org?
Config: Free BSD 11.2, i3-4.16, xorg-7.7_3.
xorg
asked 13 hours ago
henninghenning
1385
add a comment |
I just accidentally hit CtrlAltBackspace. This apparently zapped the X server. After a short flash of the screen, my window manager asked me to log in again, and I was returned to a blank slate. A quick ps -ax showed that my applications were still running, but I didn't know how to bring them back to the foreground. (fg <foo> didn't.)
How can I regain access to running applications after accidentally zapping X.org?
Config: Free BSD 11.2, i3-4.16, xorg-7.7_3.
xorg
asked 13 hours ago
henninghenning
1385
add a comment |
I just accidentally hit CtrlAltBackspace. This apparently zapped the X server. After a short flash of the screen, my window manager asked me to log in again, and I was returned to a blank slate. A quick ps -ax showed that my applications were still running, but I didn't know how to bring them back to the foreground. (fg <foo> didn't.)
How can I regain access to running applications after accidentally zapping X.org?
Config: Free BSD 11.2, i3-4.16, xorg-7.7_3.
xorg
asked 13 hours ago
henninghenning
1385
I just accidentally hit CtrlAltBackspace. This apparently zapped the X server. After a short flash of the screen, my window manager asked me to log in again, and I was returned to a blank slate. A quick ps -ax showed that my applications were still running, but I didn't know how to bring them back to the foreground. (fg <foo> didn't.)
How can I regain access to running applications after accidentally zapping X.org?
Config: Free BSD 11.2, i3-4.16, xorg-7.7_3.
xorg
xorg
asked 13 hours ago
henninghenning
1385
asked 13 hours ago
henninghenning
1385
asked 13 hours ago
henninghenning
1385
asked 13 hours ago
henninghenning
1385
asked 13 hours ago
henninghenning
1385
1385
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
After zapping the X11 server and logging in again, the UNIX X11 socket in /tmp/.X11-unix/X0 has been deleted and recreated, and the X11 session cookie in ~/.Xauthority has been replaced with a new random cookie.
Even if the value of the DISPLAY environment variable is the same, the applications would have to close and re-open the socket and re-read the cookie. As far as I know, there is no generic mechanism to signal any X11 applications to do that. And that would be just the first step: after that, the applications would have to fully recreate all their windows and other GUI objects with the X11 server and restore their state to match the program's internal state. I'm afraid this functionality does not exist.
The best you can probably do is to use kill -HUP to stop the applications, giving them a chance to auto-save any unsaved work if they have been programmed to do that, and then restart them as normal.
(That actually matches exactly the original meaning of the HUP signal: it originally meant that the user's landline modem connection had been hung up, and the application should save any unsaved work in some way that allows it to be recovered in a new session, and then exit.)
answered 12 hours ago
telcoMtelcoM
20.6k12452
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f510707%2fhow-to-regain-access-to-running-applications-after-accidentally-zapping-x-org%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
After zapping the X11 server and logging in again, the UNIX X11 socket in /tmp/.X11-unix/X0 has been deleted and recreated, and the X11 session cookie in ~/.Xauthority has been replaced with a new random cookie.
Even if the value of the DISPLAY environment variable is the same, the applications would have to close and re-open the socket and re-read the cookie. As far as I know, there is no generic mechanism to signal any X11 applications to do that. And that would be just the first step: after that, the applications would have to fully recreate all their windows and other GUI objects with the X11 server and restore their state to match the program's internal state. I'm afraid this functionality does not exist.
The best you can probably do is to use kill -HUP to stop the applications, giving them a chance to auto-save any unsaved work if they have been programmed to do that, and then restart them as normal.
(That actually matches exactly the original meaning of the HUP signal: it originally meant that the user's landline modem connection had been hung up, and the application should save any unsaved work in some way that allows it to be recovered in a new session, and then exit.)
answered 12 hours ago
telcoMtelcoM
20.6k12452
add a comment |
After zapping the X11 server and logging in again, the UNIX X11 socket in /tmp/.X11-unix/X0 has been deleted and recreated, and the X11 session cookie in ~/.Xauthority has been replaced with a new random cookie.
Even if the value of the DISPLAY environment variable is the same, the applications would have to close and re-open the socket and re-read the cookie. As far as I know, there is no generic mechanism to signal any X11 applications to do that. And that would be just the first step: after that, the applications would have to fully recreate all their windows and other GUI objects with the X11 server and restore their state to match the program's internal state. I'm afraid this functionality does not exist.
The best you can probably do is to use kill -HUP to stop the applications, giving them a chance to auto-save any unsaved work if they have been programmed to do that, and then restart them as normal.
(That actually matches exactly the original meaning of the HUP signal: it originally meant that the user's landline modem connection had been hung up, and the application should save any unsaved work in some way that allows it to be recovered in a new session, and then exit.)
answered 12 hours ago
telcoMtelcoM
20.6k12452
add a comment |
After zapping the X11 server and logging in again, the UNIX X11 socket in /tmp/.X11-unix/X0 has been deleted and recreated, and the X11 session cookie in ~/.Xauthority has been replaced with a new random cookie.
Even if the value of the DISPLAY environment variable is the same, the applications would have to close and re-open the socket and re-read the cookie. As far as I know, there is no generic mechanism to signal any X11 applications to do that. And that would be just the first step: after that, the applications would have to fully recreate all their windows and other GUI objects with the X11 server and restore their state to match the program's internal state. I'm afraid this functionality does not exist.
The best you can probably do is to use kill -HUP to stop the applications, giving them a chance to auto-save any unsaved work if they have been programmed to do that, and then restart them as normal.
(That actually matches exactly the original meaning of the HUP signal: it originally meant that the user's landline modem connection had been hung up, and the application should save any unsaved work in some way that allows it to be recovered in a new session, and then exit.)
answered 12 hours ago
telcoMtelcoM
20.6k12452
After zapping the X11 server and logging in again, the UNIX X11 socket in /tmp/.X11-unix/X0 has been deleted and recreated, and the X11 session cookie in ~/.Xauthority has been replaced with a new random cookie.
Even if the value of the DISPLAY environment variable is the same, the applications would have to close and re-open the socket and re-read the cookie. As far as I know, there is no generic mechanism to signal any X11 applications to do that. And that would be just the first step: after that, the applications would have to fully recreate all their windows and other GUI objects with the X11 server and restore their state to match the program's internal state. I'm afraid this functionality does not exist.
The best you can probably do is to use kill -HUP to stop the applications, giving them a chance to auto-save any unsaved work if they have been programmed to do that, and then restart them as normal.
(That actually matches exactly the original meaning of the HUP signal: it originally meant that the user's landline modem connection had been hung up, and the application should save any unsaved work in some way that allows it to be recovered in a new session, and then exit.)
answered 12 hours ago
telcoMtelcoM
20.6k12452
answered 12 hours ago
telcoMtelcoM
20.6k12452
answered 12 hours ago
telcoMtelcoM
20.6k12452
answered 12 hours ago
telcoMtelcoM
20.6k12452
20.6k12452
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f510707%2fhow-to-regain-access-to-running-applications-after-accidentally-zapping-x-org%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
