REISUB is broken

[Yaro]

Now, I'm not sure if this is in all installs of Intrepid or just some of them, but somehow the magic SysRq keys stopped working on several installs of Intrepd Ibex. I don't know what causes it, but it becomes very apparent thanks to Compiz Fusion somehow locking up the entire operating system.

A test of REISUB on this system when it is working shows none of it works (In fact, I got flooded by gnome-screenshot, indicating pretty clearly the magic keys are somehow disabled.)

I need bug confirmation, which means that if this problem has shown up in other systems, it's likely a bug and not some problem I caused.

[Uwe Hauck (bicyclist)]

Validated this report on three different ubuntu intrepid installations, one an update and two a fresh install. None of them allows the combination of ALT+SYSREQ + REISUB anymore

[Andres Monroy-Hernandez (andresmh)]

Confirming this bug on another Intrepid installation on a Thinkpad X300.

[ropers (ropers)]

I can also confirm this. And to repeat what I previously posted here ( http://www.reddit.com/r/linux/comments/7vry9/help_my_magic_sysrq_keys_reisub_no_longer_work_in/ ) :

Ever since I started running Ubuntu 8.10 (Intrepid Ibex), I found that the magic SysRq keys (REISUB or similar) no longer work from inside X. [It worked before, on prior versions.]

If I hit Ctrl+Alt+F1 to switch to a text mode console, the keys work fine there. (The easiest way to check is just to press AltGr+SysRq+R and it will print a message to the console.)

I can also see that the magic SysRq feature is turned on:

$ cat /proc/sys/kernel/sysrq

1

However, in the X Window environment (you typically hit Ctrl+Alt+F7 to switch back), I find that the keys do not work; when pressing AltGr+SysRq+R while having the GNOME terminal open, I can see that it just echos a registered trademark character (®).

I am using a standard Irish keyboard layout and a generic 105-key keyboard. I saw that by default the right Alt key (AltGr) was specified as a third level chooser and I first suspected that, but deactivating this didn't help. Switching to a US layout didn't appear to change anything either, except that it caused AltGr+SysRq+R to send an r instead of ®.

...

I did try the full REISUB sequence from X.

When I do that it doesn't work, and nothing gets echoed to the text mode console. However, if I happen to have a text entry box such as this one or the GNOME Terminal open while typing the REISUB sequence, I get ®éíßú when typing it using the right Alt key (AltGr). When I try the same with the left Alt key, then GNOME goes berserk and tries to take a gazillion screenshots as soon as I start holding down Alt+SysRq -- which I can recover from by going Ctrl+Alt+F1 and killall gnome-screenshot. The latter is sort of expected, as left Alt+PrintScreen is for taking screenshots of windows while the REISUB keys are supposed to work via the right Alt key (AltGr on UK and Irish keyboards). That's also how it used to work before Ubuntu 8.10. [I think.]

If I try the REISUB sequence from the text mode console it works ok.

...

...you do have an AltGr key. (...) it's the same key as the right Alt key. It's only labelled differently on on US / non-US keyboards. Whether or not you're getting the graphical characters or not depends on your keyboard layout settings, which is a software issue. But the kernel, and thus, the REISUB magic, doesn't care about that, because it always uses the same keys irrespective of higher level layout settings, because it queries the keyboard at a very low level. Which is why AltGr+SysRq+R,E,I,S,U,B. should work regardless of what's printed on the key or what your console or X keyboard layout settings are.

...

Does anyone have any ideas how to troubleshoot this? I tried googling and reading the Ubuntu forums, but all I found via that route appeared to be... even less informed.

[Dane Mutters (dmutters)]

Hello. I made this post on a duplicate bug; I thought it might be useful to post it to this one as well.

I have only tried it on my home Desktop computer, a Core 2 Duo machine with an nVidia 9600GT (by Asus) graphics card, using the proprietary nVidia driver; a logitech Cordless Desktop keyboard and (optical) mouse (model Y-RAJ56A, with sysrq on the prtscr key); running Ubuntu 8.10 with all updates (but no backports).

I have also tried using the right alt key as "altgr" instead of the prtscr/sysrq key, as suggested at some sites (which I don't remember what the addresses were or how I got there...). Additionally, I have tried a number of other key combinations, such as leftalt+shift+prtscr/sysrq+k, to no avail.

I should note, however, that my TTYs are all functional (F1-F6), and respond as expected to alt+sysrq+R/E/I/S/U/B and alt+sysrq+K. It's only in the Gnome GUI that there is no affect, other than asking the user whether to save a screenshot. :-p

I have also tried setting different keyboard models (us105, Logitech Cordless Desktop [and "alternate"], and Logitech Cordless Desktop Optical), different combinations of "alt/win key behavior" and "compose key position" (in system>preferences>keyboard), mapping "print screen/screen shot" to different key combinations (in system>preferences>keyboard shortcuts), and lots of various button mashing. :-)

Please let me/us (Michael et al) know if there's any further information that may be of assistance in solving this problem. With ctrl+alt+backspace disappearing in the next release, I think it's going to be important to get this resolved as soon as is reasonably possible. (Please note that I don't mean to put undue pressure on anybody by saying this.)

Thanks, Devs, for all your work; you make Ubuntu great!

--Dane

[Johnathon (kirrus)]

This issue should be reproducible with the live environment of the Desktop CD of the development release - Jaunty Jackalope. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Dane Mutters (dmutters)]

Confirmed. I am currently booted into the Jaunty Alpha 4 live CD. ctrl+sysrq+k and ctrl+sysrq+reisub have no effect in Gnome. I also tried holding down shift during the key presses, as my sysrq key is on the prtscr key.

Thanks for looking into this.

[Johnathon (kirrus)]

I'm returning this to confirmed status

[Paul Hoell (hoellp)]

I wanted to tune in with a partial success, but first things first. I'm on Kubuntu Jaunty 64bit and sysrq (which is FN+Del on my notebook) is mapped to the same keycode as the print button (FN+Ins) which causes MANY screenshot utilities to start. Even 'xev' shows the button as print.

With some playing around I found, that the magic sysrq combinations work if I start the combo with Alt->Fn->Del->R,E,I,S,U,B instead of Fn->Del->.....
The funny thing is, alt+sysrq+k still won't work, just "REISUB".

[lesshaste (ubuntu-lesshaste)]

I can confirm that on 8.10 alt-sysrq-h (for example) does not work in X but works fine in a virtual terminal. Can any developer confirm if it's even meant to work in X?

Raphael

[gorillastrong2 (millej6)]

i have the same problem, can't ever get the "magic key" to work because it just seems to be linked to my print screen button everytime i press alt+sysrq i get a print screen. If I make the mistake of trying to "hold" the button my comp just gets flooded. So i don't have a solution if my computer freezes.

Very disheartening since its the one thing keeping me from fully enjoying ubuntu 9.04. Can't keep hard shutting down my computer when it hangs up.

Hope this is the right place to say something. Look forward to changes/solutions

[Michael Jones (jonesmz)]

@gorillastrong2

    You can re-enable control-alt-backspace by modifying your xorg conf file to include the lines

Section “ServerFlags”
Option “DontZap” “false”
EndSection

or, according to a few blogs i found doing a search, you can run the command

dontzap –disable

I personally disagree with disabling that key combination by default, especially in regards to my laptop being unusable for the first few hours do to an issue with gfx at install... but *shrug*. once this issue with sysreq-k is resolved, i'll be a happy camper again.

 I hope that fixes your issue.

[ropers (ropers)]

2009/4/28 Michael Jones <email address hidden>:
> @gorillastrong2
>
>    You can re-enable control-alt-backspace by modifying your xorg conf
> file to include the lines
>
> Section “ServerFlags”
> Option “DontZap” “false”
> EndSectionOption “DontZap” “false”

The above is slightly bad information because it's copied and pasted
from or via some program that "prettified" the quotation marks (maybe
MS Word). To work in xorg.conf however, the quotation marks need to be
" [U+0022 (34)], which the above quotation marks aren't; cf.:
http://en.wikipedia.org/wiki/Quotation_mark_glyphs

[Michael Jones (jonesmz)]

How exactly are you able to verify that when you received the information
from a website that undoubtedly modified the input it was given to be
correctly represented internally, and then transmitted to be displayed on an
unknown browser that operates on an unknown operating system?

My suggestion is that a user types the xorg.conf information into xorg.conf
manually. its only a few lines, and alleviates any issue with correct type
settings.

On Thu, May 7, 2009 at 6:26 PM, Jens Ropers <email address hidden> wrote:

> 2009/4/28 Michael Jones <email address hidden>:
> > @gorillastrong2
> >
> > You can re-enable control-alt-backspace by modifying your xorg conf
> > file to include the lines
> >
> > Section “ServerFlags”
> > Option “DontZap” “false”
> > EndSectionOption “DontZap” “false”
>
> The above is slightly bad information because it's copied and pasted
> from or via some program that "prettified" the quotation marks (maybe
> MS Word). To work in xorg.conf however, the quotation marks need to be
> " [U+0022 (34)], which the above quotation marks aren't; cf.:
> http://en.wikipedia.org/wiki/Quotation_mark_glyphs
>
> --
> REISUB is broken
> https://bugs.launchpad.net/bugs/303601
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” source package in Ubuntu: Confirmed
>
> Bug description:
> Now, I'm not sure if this is in all installs of Intrepid or just some of
> them, but somehow the magic SysRq keys stopped working on several installs
> of Intrepd Ibex. I don't know what causes it, but it becomes very apparent
> thanks to Compiz Fusion somehow locking up the entire operating system.
>
> A test of REISUB on this system when it is working shows none of it works
> (In fact, I got flooded by gnome-screenshot, indicating pretty clearly the
> magic keys are somehow disabled.)
>
> I need bug confirmation, which means that if this problem has shown up in
> other systems, it's likely a bug and not some problem I caused.
>

[ropers (ropers)]

2009/5/8 Michael Jones <email address hidden>:
> How exactly are you able to verify that when you received the information
> from a website that undoubtedly modified the input it was given to be
> correctly represented internally, and then transmitted to be displayed on an
> unknown browser that operates on an unknown operating system?

Oh cop on. *You* provided the info. It would have been proper for
*you* to verify that what you're posting is actually useful and
doesn't contain erroneous characters. It ain't rocket science. I
checked the characters you provided and detected that they were wrong;
you ought to have done just that, *before posting them*. But hey, we
all make mistakes, so it's entirely understandable and forgivable --
just don't be defensive about your little screw-up.

> My suggestion is that a user types the xorg.conf information into xorg.conf
manually. its only a few lines, and alleviates any issue with correct type
settings.

My suggestion is that you're more diligent next time and don't try to
pass the buck and blame for your mistakes to others.

[Michael Jones (jonesmz)]

So Jens, I'm sorry if you felt I was accusing you, but I was asking how you
knew, not accusing you of being wrong. From the amount of knowledge I have,
which yes, is limited, I have no idea how you were able to verify what you
did.

    Also, the text that you are telling me is incorrect, was text I copied
into my xorg without suffering any issue. So I'm, again, not sure where
exactly your getting your information from. If for some reason the method by
which I copied the text from somehow corrected my own error, I would really
appreciate if you would point that out to me. However, I don't think that
the tone of your reply, that is, if I'm interpreting it correctly, is really
appropriate.

-Mike

On Thu, May 7, 2009 at 7:34 PM, Jens Ropers <email address hidden> wrote:

> 2009/5/8 Michael Jones <email address hidden>:
> > How exactly are you able to verify that when you received the information
> > from a website that undoubtedly modified the input it was given to be
> > correctly represented internally, and then transmitted to be displayed on
> an
> > unknown browser that operates on an unknown operating system?
>
> Oh cop on. *You* provided the info. It would have been proper for
> *you* to verify that what you're posting is actually useful and
> doesn't contain erroneous characters. It ain't rocket science. I
> checked the characters you provided and detected that they were wrong;
> you ought to have done just that, *before posting them*. But hey, we
> all make mistakes, so it's entirely understandable and forgivable --
> just don't be defensive about your little screw-up.
>
> > My suggestion is that a user types the xorg.conf information into
> xorg.conf
> manually. its only a few lines, and alleviates any issue with correct type
> settings.
>
> My suggestion is that you're more diligent next time and don't try to
> pass the buck and blame for your mistakes to others.
>
> --
> REISUB is broken
> https://bugs.launchpad.net/bugs/303601
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” source package in Ubuntu: Confirmed
>
> Bug description:
> Now, I'm not sure if this is in all installs of Intrepid or just some of
> them, but somehow the magic SysRq keys stopped working on several installs
> of Intrepd Ibex. I don't know what causes it, but it becomes very apparent
> thanks to Compiz Fusion somehow locking up the entire operating system.
>
> A test of REISUB on this system when it is working shows none of it works
> (In fact, I got flooded by gnome-screenshot, indicating pretty clearly the
> magic keys are somehow disabled.)
>
> I need bug confirmation, which means that if this problem has shown up in
> other systems, it's likely a bug and not some problem I caused.
>

[Michael Jones (jonesmz)]

Actually, in addition to that could you please link me to where the
differences in character types are discusses for xorg? I've not heard of
that distinction before and am curious to learn more.

-Mike

On Thu, May 7, 2009 at 8:53 PM, Mike Jones <email address hidden> wrote:

> So Jens, I'm sorry if you felt I was accusing you, but I was asking how you
> knew, not accusing you of being wrong. From the amount of knowledge I have,
> which yes, is limited, I have no idea how you were able to verify what you
> did.
>
> Also, the text that you are telling me is incorrect, was text I copied
> into my xorg without suffering any issue. So I'm, again, not sure where
> exactly your getting your information from. If for some reason the method by
> which I copied the text from somehow corrected my own error, I would really
> appreciate if you would point that out to me. However, I don't think that
> the tone of your reply, that is, if I'm interpreting it correctly, is really
> appropriate.
>
> -Mike
>
>
> On Thu, May 7, 2009 at 7:34 PM, Jens Ropers <email address hidden> wrote:
>
>> 2009/5/8 Michael Jones <email address hidden>:
>> > How exactly are you able to verify that when you received the
>> information
>> > from a website that undoubtedly modified the input it was given to be
>> > correctly represented internally, and then transmitted to be displayed
>> on an
>> > unknown browser that operates on an unknown operating system?
>>
>> Oh cop on. *You* provided the info. It would have been proper for
>> *you* to verify that what you're posting is actually useful and
>> doesn't contain erroneous characters. It ain't rocket science. I
>> checked the characters you provided and detected that they were wrong;
>> you ought to have done just that, *before posting them*. But hey, we
>> all make mistakes, so it's entirely understandable and forgivable --
>> just don't be defensive about your little screw-up.
>>
>> > My suggestion is that a user types the xorg.conf information into
>> xorg.conf
>> manually. its only a few lines, and alleviates any issue with correct type
>> settings.
>>
>> My suggestion is that you're more diligent next time and don't try to
>> pass the buck and blame for your mistakes to others.
>>
>> --
>> REISUB is broken
>> https://bugs.launchpad.net/bugs/303601
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>> Status in “linux” source package in Ubuntu: Confirmed
>>
>> Bug description:
>> Now, I'm not sure if this is in all installs of Intrepid or just some of
>> them, but somehow the magic SysRq keys stopped working on several installs
>> of Intrepd Ibex. I don't know what causes it, but it becomes very apparent
>> thanks to Compiz Fusion somehow locking up the entire operating system.
>>
>> A test of REISUB on this system when it is working shows none of it works
>> (In fact, I got flooded by gnome-screenshot, indicating pretty clearly the
>> magic keys are somehow disabled.)
>>
>> I need bug confirmation, which means that if this problem has shown up in
>> other systems, it's likely a bug and not some problem I caused.
>>
>
>

[Michael Jones (jonesmz)]

Testing it again, your right. Those quotes cause X to be unhappy.

I admit I gave broken information. I do not know why it worked for me initially.
I am filing a bug-report against this.

Thanks for pointing out my mistake, Jens.

[ropers (ropers)]

>>>> 2009/4/28 Michael Jones <email address hidden>:
>>>> > @gorillastrong2
>>>> >
>>>> > You can re-enable control-alt-backspace by modifying your xorg conf
>>>> > file to include the lines
>>>> >
>>>> > Section “ServerFlags”
>>>> > Option “DontZap” “false”
>>>> > EndSectionOption “DontZap” “false”

>>> Jens Ropers <email address hidden> wrote:
>>>> The above is slightly bad information because it's copied and pasted
>>>> from or via some program that "prettified" the quotation marks (maybe
>>>> MS Word). To work in xorg.conf however, the quotation marks need to be
>>>> " [U+0022 (34)], which the above quotation marks aren't; cf.:
>>>> http://en.wikipedia.org/wiki/Quotation_mark_glyphs

>> 2009/5/8 Michael Jones <email address hidden>:
>> > How exactly are you able to verify that when you received the information
>> > from a website that undoubtedly modified the input it was given to be
>> > correctly represented internally, and then transmitted to be displayed on
>> > an unknown browser that operates on an unknown operating system?

> On Thu, May 7, 2009 at 7:34 PM, Jens Ropers <email address hidden> wrote:
>> Oh cop on. *You* provided the info. It would have been proper for
>> *you* to verify that what you're posting is actually useful and
>> doesn't contain erroneous characters. It ain't rocket science. I
>> checked the characters you provided and detected that they were wrong;
>> you ought to have done just that, *before posting them*. But hey, we
>> all make mistakes, so it's entirely understandable and forgivable --
>> just don't be defensive about your little screw-up.

>> 2009/5/8 Michael Jones <email address hidden>:
>> > My suggestion is that a user types the xorg.conf information into
>> > xorg.conf manually. its only a few lines, and alleviates any issue with correct
>> > type settings.

> On Thu, May 7, 2009 at 7:34 PM, Jens Ropers <email address hidden> wrote:
>> My suggestion is that you're more diligent next time and don't try to
>> pass the buck and blame for your mistakes to others.

2009/5/8 Michael Jones <email address hidden>:
> I was asking how you
> knew, not accusing you of being wrong. From the amount of knowledge I have,
> which yes, is limited, I have no idea how you were able to verify what you
> did.

First, be aware of the difference between "prettified" so-called
"smart" quotation marks and the standard (old ASCII compatible) 0x22
quotation marks; cf.:
http://en.wikipedia.org/wiki/Quotation_mark#Typing_quotation_marks_from_a_computer_keyboard
http://en.wikipedia.org/wiki/Quotation_mark_glyphs#Quotation_marks_in_European_languages

I *think* both 0x27 and 0x22 [ie. U+0027 (39) and U+0022 (34)] are
legal in xorg.conf -- as in most Unix-like tools and config files.
"Prettified" quotes such as U+2018 (8216), U+2019 (8217), U+201C
(8220), and U+201D (8221) however probably are not.

One way to check exactly what character you're looking at --apart from
looking closely and visually distinguishing "prettified" quotation
marks from standard ASCII 0x22 quotation marks would be to copy the
quotation mark in question, open a shell prompt, type:
cat | hd[enter]
and then paste the character and press [enter] and Ctrl+D.
A slower w...

[motty (mottyporat)]

I worked around it by System->Preferences->Keyboard shortcuts - disable anything that was attached to the PrintScrn key. (on a laptop with PrintScrn & SysRq on the same key).
This is still very disturbing, because SysRq should have not depended on any application-level settings.
Besides, the more gentle ops, like SysRq-H (help), don't show anything within X.
Hope for it to work at the next freeze...

[Michael Jones (jonesmz)]

On my laptop, disabling the keyboard shortcuts associated with the SysReq
key didn't do it. I also had to modify

Some Linux distributions come with the magic sysrq disabled as a security
measure, considered by some to be misguided. You'll see in */etc/sysctl.conf
*

kernel.sysrq = 0

 Change this to

kernel.sysrq = 1

 and run

sysctl -p

 You should always check for this on a new Linux system before running into
a freeze that makes you wish magic sysrq was working.

from

http://en.wikipedia.org/wiki/Magic_SysRq_key

and THEN it worked.

Is this disabled in Ubuntu intentionally?

On Fri, Jun 26, 2009 at 6:22 PM, motty <email address hidden> wrote:

> I worked around it by System->Preferences->Keyboard shortcuts - disable
> anything that was attached to the PrintScrn key. (on a laptop with PrintScrn
> & SysRq on the same key).
> This is still very disturbing, because SysRq should have not depended on
> any application-level settings.
> Besides, the more gentle ops, like SysRq-H (help), don't show anything
> within X.
> Hope for it to work at the next freeze...
>
> --
> REISUB is broken
> https://bugs.launchpad.net/bugs/303601
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “linux” package in Ubuntu: Confirmed
>
> Bug description:
> Now, I'm not sure if this is in all installs of Intrepid or just some of
> them, but somehow the magic SysRq keys stopped working on several installs
> of Intrepd Ibex. I don't know what causes it, but it becomes very apparent
> thanks to Compiz Fusion somehow locking up the entire operating system.
>
> A test of REISUB on this system when it is working shows none of it works
> (In fact, I got flooded by gnome-screenshot, indicating pretty clearly the
> magic keys are somehow disabled.)
>
> I need bug confirmation, which means that if this problem has shown up in
> other systems, it's likely a bug and not some problem I caused.
>

[svaens (svaens)]

On my laptop (sony vaio with ATI graphics HD 3470 mobility)
when i've hit the alt-sysrq-k combination, i've had the following experience;

1. once when i needed it, because my system had frozen after trying to get my mobile broadband to work
result: Nothing at all. System still frozen, X still there and frozen
(wasn't this key combination supposed to be above all this?)

2. once after a fresh reboot and login (for testing purposes)
result: blank black screen, non-recoverable, needed a power switch hold for 5 seconds to force computer off.

not nice.

[Enrique (elatre)]

I found the answer (at least for Jaunty and Karmic) at
man xorg.conf

I created a file /etc/X11/xorg.conf with the following content:
Section "ServerFlags"
 Option "VTSysReq" "True"
EndSection

and restarted the X server.

[penalvch (penalvch)]

Yaro, thank you for reporting this and helping make Ubuntu better. Intrepid reached EOL on April 30, 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag:
needs-upstream-testing

This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text:
needs-upstream-testing

If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

Please let us know your results. Thank you for your understanding.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

[Dane Mutters (dmutters)]

I no longer use Ubuntu, but as of 11.10 (from initial installation to the release of 12.04 with all updates), I found REISUB to be working fine--for what that's worth. As I'd previously had this bug (as noted above), I thought you'd want to know.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Dane Mutters (dmutters)]

I've recently switched (back) to using Linux Mint with Mate. I can confirm that in this distro, REISUB is working just fine. Since Ubuntu is Mint's upstream, it's very likely that the bug is solved in Ubuntu, as well. Thought you might like to know. I see no reason to un-expire this bug, or otherwise keep it "open." Thanks for your support.