Skip to content

Instantly share code, notes, and snippets.

Last active April 10, 2017 03:58
Show Gist options
  • Save lazywithclass/78a78eab8569c1125b0357ec796c8c0d to your computer and use it in GitHub Desktop.
Save lazywithclass/78a78eab8569c1125b0357ec796c8c0d to your computer and use it in GitHub Desktop.
[CSE373] Lecture, Ubuntu weirdness, winston-cloudwatch behaviour (-174)

[CSE373] Lecture, Ubuntu weirdness, winston-cloudwatch behaviour (-174)

CSE373 2012 - Lecture 17 - Backtracking

Addressed the caps-twice-halts-your-pc and suspend-loop problems

The first was the most puzzling one: pressing caps twice in a row would halt my pc with a weird scrambled graphics effect on the monitor. It turned out to be a quite common problem and somehow linked to the suspend-loop one.

The caps wasn't a real problem with me since I always remap it to CTRL.

Solving the suspend was a bit trickier and in the end involved adding a parameter to grub boot params.

I've never done that in the past but it turned out to be easy thanks to this askubuntu post: instead of foo=bar just append button.lid_init_state=open, then follow the instructions.

I rebooted my laptop and the problem went away...

but why

This post sums it nicely enough (at least for a kernel newbie like me):

On most platforms, _LID returning value, lid open/close events are all reliable, but there are exceptions.


In order not to trigger issues on such buggy platforms, the ACPI button driver currently implements a lid_init_state=open quirk to send additional "open" event after resuming.

and also on the same matter, the same person suggest the fix.

Archlinux advises for the same fix, for exactly my laptop.

Oh, and there's also a bug for this:

Errors in winston-cloudwatch console output

It looks like, despite my efforts to never send empty logs, there are some edge case scenarios in which a payload with empty logEvents is sent to AWS, which answers with an error, making users of the library worried about its correctness.

I think the action here is add another check before invoking aws.putLogEvents, and to create a sample app that constantly sends log to AWS CloudWatch so that I can spot errors or strange behaviours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment