Talk:Magic SysRq key

This article was nominated for deletion on 31 July 2008. The result of the discussion was keep.

Linux Low‑importance

	Linux portal This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
Low	This article has been rated as Low-importance on the project's importance scale.

Computing: Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

RSEIUB

I readded the paragraph on RSEIUB, as there is a redirection from that acronym to this article and people searching for RSEIUB might not understand the relation to SysRq without it. (By the way: Why is it "and an incorrect one as well"?) --84.143.39.40 21:30, 12 January 2007 (UTC)[reply]

RSEIUB is incorrect because S is the "Sync data to disk" command, and the E or I commands that signal applications to exit may cause the application to write more data to the disk, which would then be un-sync'd.

REISUB

It's considered safer to sync after killing the processes so it might make sense to rewrite the mnemonic to Raising Elephants Is So Utterly Boring.

Perhaps one might even keep the "Skinny" part in place.

No changes made yet. —The preceding unsigned comment was added by 194.94.224.254 (talk) 08:33, 23 April 2007 (UTC).[reply]

'It's considered safer'? Who considers it safer? Why would when you sync the disk matter? I think we need someone authoritative on this to say which one is better (if either) and why.--Cogburnd02 22:24, 17 August 2007 (UTC)[reply]

I'm no authoritative reference, but if you sync before killing all processes, wouldn't they have a chance to queue more data to be written, which may be only partially written by the time the Unmount command is received? --Khumba 19:19, 29 August 2007 (UTC)[reply]

Hmm... someone should ask a kernel developer which is best 75.70.81.208 11:15, 9 September 2007 (UTC)[reply]

Processes can (and do) handle the SIGTERM signal. It's reasonable that a process that is asked to terminate gracefully will likely write log data (which might very well get cached). On the other hand, SIGKILL can't be handled, so doing a sync and then sending SIGKILL to all processes is safe. Andareed (talk) 06:44, 11 January 2008 (UTC)[reply]

What if a process writes a file after the sync but before the SIGKILL? 2001:9E8:460D:E300:64FD:A42B:AA79:261A (talk) 19:54, 8 January 2024 (UTC)[reply]

I'm no kernel hacker, but wouldn't remounting filesystems read-only in the end flush all the data anyway? --Piotr Mitas (talk) 13:51, 30 December 2008 (UTC)[reply]

Explanation of REISUB commands

When the article explains the actions taken by each command: REISUB, I is esplained kills all processes (except init), but before that its function is l sends the SIGKILL signal to all processes, including init., so, which one is right? the one that kills init or the one that doesn't? —Preceding unsigned comment added by 200.126.237.106 (talk) 16:22, 9 September 2007 (UTC)[reply]

REISUB is at fault here. I removed it before, as it contradicts authoritative sources (the sysrq help file in the Linux sources), but it appears it was added again. I don't believe it appears in any reliable source. --Constantine 06:36, 4 November 2007 (UTC)[reply]

Raising Skinny Elephants Is Utterly Boring

"Raising Skinny Elephants Is Utterly Boring" redirects here, but is not explained in the article. I'm curious about what it means. -- Beland 02:51, 15 November 2007 (UTC)[reply]

See this revision. -- intgr [talk] 03:59, 15 November 2007 (UTC)[reply]

Enabling SysRq

I think this info should have it's own section, or at the very least remain in 'Command line access and configuration' but be placed at the beginning and have the section renamed 'Configuration and command line access'. It just makes more sense to explain how to enable the feature before explaining advanced features which require the feature to already be activated. If there is agreement I'm happy to make the changes. -- (Kinslayer11 (talk) 04:14, 7 May 2008 (UTC))[reply]

In my opinion this article has already crossed the "Wikipedia is not a manual" line, and should be trimmed rather than expanded. I believe this content is more appropriate on some Linux-oriented wiki like HowtoForge or others. -- intgr [talk] 11:37, 7 May 2008 (UTC)[reply]

Is This Right?

I'm confused. In the table, it seems to give conflicting info:
"Send the SIGTERM signal to all processes except init (PID 1)" = Qwerty key "e"
"Send the SIGKILL signal to all processes except init" = Qwerty key "i"
Is one supposed to quit all except init and the other including init? Or, do they both exclude init and maybe there's some difference between SIGTERM and SIGKILL that matters instead? I'm new to Linux, so maybe the article is right? If so, sorry~ ZeniffMartineau (talk) 12:24, 1 August 2010 (UTC)[reply]

See SIGTERM, SIGKILL. -- intgr [talk] 09:39, 2 August 2010 (UTC)[reply]

Thank you! Now it makes sense. I guess I didn't notice those links in the article somehow. :P ZeniffMartineau (talk) 07:11, 10 August 2010 (UTC)[reply]

Power distribution unit

Should it really be in "See Also" list? —Preceding unsigned comment added by 86.57.158.78 (talk) 18:02, 15 March 2011 (UTC)[reply]

No, it shouldn't (I think). Removed it. PiusImpavidus (talk) 11:41, 5 April 2012 (UTC)[reply]

REISUB Deletion

Several people think the section on REISUB needs to be deleted. However, I disagree. I understand that Wikipedia should not be giving how-to instructions, but seriously, REISUB is the most common use of the SysRq key and some mention to it should be included. I agree the section previously included was much to instructional and should be re tweaked, but deleting it entirely (especially when REISUB redirects here) is the wrong way to do this.62.155.227.60 (talk) 17:56, 1 April 2011 (UTC)[reply]

The Security concerns section

I think the security concern section as it currently stands has some problems. From reading the section and the associated sources, it doesn't become clear to me how important the debate on the security issues on the SysRq key is, and if we, by including a section on it, are overrepresenting it. The second half of the section is rather how-to'ish. It leaves me wondering: 1. Should we include a section on the security in the first place? 2. If yes, what do we want it to include? Martijn Hoekstra (talk) 18:57, 6 April 2011 (UTC)[reply]

Update (and History)

It might be worth checking the history of the SysReq key as used in Linux. The keys used and files used for access have changed in purpose over the years. (For instance, one refered-to document - or source - mentiones /proc/sysrq-sticky which doesn't seem to exist in my current kernel). DavidDouthitt (Talk) 16:41, 3 February 2012 (UTC)[reply]

How to use CTRL-ALT-F2 after SYSRQ would be a good example

I agree that format of the current article is good. I hope the Wikipedia doesn't become like old fashioned printed encylopedias.

It would be useful to have a plausible example of how a person can un-stick a frozen system and get to a console without rebooting because often it's helpful to look at logs (like .xsession-errors) that will be overwritten if the system reboots.

Tashiro (talk) 00:50, 1 August 2012 (UTC)[reply]

FreeBSD screenshot

This article is talking about a Linux feature, but the kernel panic image near the end is FreeBSD.

If FreeBSD also supports magic SysRq in the same way (I do not believe it does), the article should be adjusted to clarify that. If not, a linux kernel panic image would be more appropriate. — Preceding unsigned comment added by 184.65.99.106 (talk) 04:22, 9 February 2013 (UTC)[reply]

When the combination doesn't work.

Last year my desktop computer (Fedora Linux, kept fully updated) started freezing. I activated the Magic SysRq Key and made sure it worked. However, it only worked when I didn't need it; that is, if the system froze, it wouldn't respond even to this. Eventually, I found that my CPU fan was dying and the freezes were caused by overheating. It should probably be mentioned in the article that hardware issues can prevent the system from responding to this, but all I have right now is a personal anecdote. Is this something that needs citation, or is it worth putting in as is?JDZeff (talk) 20:08, 20 September 2013 (UTC)[reply]

I don't think so, as it is obvious that software (in systems like PCs, which are not specifically designed to be failsafe) is not garanteed to work if the underlying hardware is not working as it should. --Matthiaspaul (talk) 01:43, 21 September 2013 (UTC)[reply]

laptops

Hi, I added new method for laptops, I tesed it and it works(original laptop method mentioned in article doesn't work) please don't remove it. thanks, Alipoor90 (talk) 23:04, 14 December 2014 (UTC)[reply]

I think it's only a matter of time before most of this article is written, because it fails WP:NOTHOWTO. -- intgr [talk] 06:47, 15 December 2014 (UTC)[reply]

deleting REISUB entry

My replacement of the REISUB entry by a mention that it's obsolete and sometimes actively harmful got reverted by an IP. I'm reverting back, not fishing for refs elsewhere -- I can point to [1] which is a self-quote, but one reviewed by multiple kernel maintainers. -KiloByte (talk) 09:34, 27 July 2022 (UTC)[reply]

WRT previous discussions: I don't deny that REISUB was useful in the past. But that was then, and now is now. -KiloByte (talk) 20:31, 29 July 2022 (UTC)[reply]