Random backoff timing.

Hi All,
Was going thro this post
http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Wireless%20-%20Mobility&topic=WLAN%20Radio%20Standards&topicID=.ee6e8c2&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cc12631
And iam confused. Have some queries.
1. When does the random backoff timer start?
a) whenever the station wants to transmit after the completion of its NAV
b) Starts when Station wants to transmit irrespective of the NAV, later NAV gets added to backoff timer some other station is transmitting before completion of its backoff timer to 0
2. Who sets this Random number for the backoff time?
3. Can two devices on the same WLAN set the same random backoff time?
4. In the scenario that two stations finish their NAVs and start their ramdom backoff time. Is it possible that they both set the same time? if nope... how is this acheived? if yes then how r colisions avoided in such a scenario?
5. the above post spoke of intervals like 20ns etc
Can someone tel me the intervals for 802.11 a, b , b and n explicitely?
6. When calculating NAV, does it consider a whole frame or if there is frangments to that frame. does it consider only 1 fragment.
meaning... will the other stations have to wait for the whole frame to be transmitted or if there is fragmentation of that frame/data, after the 1st fragment, he other clients will get a chance to transmit data?
Pl help. any inputs r welcome.

When Both stations should have the same NAV values, and both will physically sense when the medium is idle. There is a high probability that both stations will attempt to transmit when the medium becomes idle, causing a collision. To avoid this situation, DCF uses a random backoff timer.
The random backoff algorithm randomly selects a value from 0 to the contention window (CW) value. The default CW values vary by vendor and are value-stored in the station NIC. The range of values for random backoff start at 0 slot times and increment up to the maximum value, which is a moving ceiling starting at CWmin and stopping at a maximum value known as CWmax. For the sake of this example, assume that the CWmin value begins at 7 and CWmax value is 255

Similar Messages

CSMA/CA NAV/Duration field and random backoff timer - Process

Hi guys,
Gotta a quick one for you.
Pls see text below
As a condition to accessing the medium, the MAC Layer checks the value of its network allocation vector (NAV), which is a counter resident at each station that represents the amount of time that the previous frame needs to send its frame. The NAV must be zero before a station can attempt to send a frame. Prior to transmitting a frame, a station calculates the amount of time necessary to send the frame based on the frame's length and data rate. The station places a value representing this time in the duration field in the header of the frame. When stations receive the frame, they examine this duration field value and use it as the basis for setting their corresponding NAVs. This process reserves the medium for the sending station.
An important aspect of the DCF is a random back off timer that a station uses if it detects a busy medium. If the channel is in use, the station must wait a random period of time before attempting to access the medium again. This ensures that multiple stations wanting to send data don't transmit at the same time. The random delay causes stations to wait different periods of time and avoids all of them sensing the medium at exactly the same time, finding the channel idle, transmitting, and colliding with each other. The back off timer significantly reduces the number of collisions and corresponding retransmissions, especially when the number of active users increases.
So, if all clients in a WLAN see a frame come from station A, and station A has set the duration field, all other stations set their NAV and wait until it expires.
THEN, i would expect all stations to start to contend for the medium at exactly the same time.
BUT you have the random backoff timer.
The question is does the NIC add a random number to the NAV field, ie, once it sees station As duration field value (lets say 300us) it adds 47us to this and the NAV is 347us? -- or do all stations decrement the NAV field to zero and then start a random backoff timer?
Many thx for the help,
Kind regards,
Ken

Sorry chaps, but I think you've got this wrong...
The whole point of a NAV being transmitted by the TX & RX ends is to stop hidden node issues - with both ends transmitting the NAV, you are guaranteeing that every 802.11 device within range of either end of the transaction is quiet for the duration of the NAV.
Lets say we have a TX (A) and an RX (B), and another device (C). Lets say that (A) can hear (B), and that (B) can hear (A) and (C). (A) and (C) cannot hear each other.
(A) <<>> (B) <<>> (C)
Applying that to your scenario...
<>
it now counts down to 310, it checks the air, and sees the same packet still being transmitted
309, 308, 307 .............
gets down to 12us, checks the ait, NOW DOES NOT see a packet being transmitted.
you count down to 11, it check the air, you donot see a packet being transmitted.
<>
The part where it jumps down from 312 to 11 is wrong. Just because (C) can't hear anything, doesn't mean that (B) isn't receiving something from (A).
What actually happens with NAV's is;
[Lets say (A) is transmitting to (B)]
1. (A) transmits NAV, value = "NAV-A"
2. (B) receives packet, along with everything else in range of (A), on the same channel as (A)
3. (B) responds to (A) with "NAV-B". "NAV B" = "NAV-A" [minus] "Elapsed Time"
4. (A) receives packet, along with everything in range of (B), on the same channel as (B)
At this point, every device on that channel will be silent for the duration of the NAV, regardless of whather or not they hear anything during the NAV countdown duration.
When the NAV expires, the Random Backoff Timer begins, and the lowest/ quickest client to get to zero then gets to transmit, and the whole process starts again.
Let me know what you think, but I'm pretty sure that's how it actually works.
Rgds,
Richard

RTS/CTS -unicast or broadcast + Random backoff time

Hi everybody,
Iam reading through the frame handshake in WiFi. Also went through some of the good articles in this forum.
I understand that to avoid collision, RST/CTS handshake is used in the wireless Air medium.
I have attached the RTS-CTS handshake and I would like to know if these frames are unicast or broadcast.
Since they are sent from a specific source say Wifi Client to a specifc destination say Wifi AP, i assume the RTS and CTS signals to be unicast but i dont understand then how the other wifi stations/clients will listen/get the duration (NAV)
Also regarding the backoff time interval, I would like to know how this time is decided by the waiting clients? Say client A and Client B are waiting for the medium to be free. Both get the NAV duration as client C is using the medium. Now after the NAV time is complete, the clients A and B will wait for a backoff time.
>how much is this random time?
>Can both set the same backoff time say 1? >Will the clients with min backoff time will get to check the medium first.
>What is the max time each client will get to use the medium? What if Cient C using the medium has lots of data to send. Will clients A and B have to wait till Client C finishes? OR is there a max time duration.
Pl advise.

Whenever a wireless client wants to send a data packet to the access point, it actually transmits a four-packet sequence called the RTS-CTS-DATA-ACK packet sequence. Each of the four 802.11 frames carries a NAV field that indicates the number of microseconds that the channel is reserved for by a wireless client. During the RTS/CTS handshake between the wireless client and access point, the wireless client sends a small RTS frame that includes a NAV interval large enough to complete the entire sequence. This includes the CTS frame, the data frame, and the subsequent acknowledgment frame from the access point.
When the wireless client transmits its RTS packet with the NAV set, the transmitted value is used to set the NAV timers on all other wireless clients associated to the access point. The access point replies to the RTS packet from the client with a CTS packet that contains a new NAV value updated to account for the time already elapsed during the packet sequence. After the CTS packet is sent, every wireless client that can receive from the access point has updated their NAV timer and defers all transmissions until their NAV timer reaches 0. This keeps the channel free for the wireless client to complete the process of transmitting a packet to the access point.

Premiere CC Multicamera: random or timed edits?

I've got a multicamera project setup and synchronized with Pluraleyes. Is it possible to automate the editing process? The way this was filmed, it's fine to cut randomly from one camera to the other, or time edits to cut every 5 seconds or so. How can this be accomplished?

Ben, I'm having the same issue. Never had it before yesterday.
I'm editing on CC with R3D's. I have 8 tracks of audio. When I'm exporting (either through Encoder or through Premier) I'm getting a final product that has no audio, and in its place a loud clicking sound. I performed a number of reboots and got it to export once. But I've tried dozen's of times now and can't get audio to export through this sequence.
When I go to render the project I'm getting an "Error Compiling Movie. Unknown Error" message. I suspect that's related. Not sure what's happening. I'm going to keep testing. I'll let you know if I discover anything. But it is VERY FRUSTRATING:( Deadlines are looming.
-Brian

ICal auto-setting random & ridiculously timed reminders in OSX

I purchased a new iMac a couple of months ago with the new OSX installed. My macbook has Snow Leopard still and works fine..
For some reason my iCal is auto-setting reminders at the most random and ridiculous reminder times. Sometimes its 1390 minutes, other times it may be 1600 minutes or 975 minutes. Its the most insane thing ever and I can't figure out A. Why its happening or B. What's causing the random numbers, as of right now they seem to be just that- random.
I'm so incredibly annoyed b/c I have to set a time and then manually go in and change each and every one. And as far as I can see via my multiple searches, I can't find anyone that has the same problem.
I've tried:
- deleting my calendar and re-adding (I sync with Google Apps).
- Setting a default alert for 15 mins prior in settings
To no avail none of these work. Its such a pain in my *** that I'm contemplating downgrading to Snow Leopard. Any suggestions before I take that extreme measure?

Hello ~
I know this is an old post, but I'm hoping you are still out there John Maisey...? I followed the instructions on your link several times, however my reminders still come up as a message at 4:50pm the day before, plus an email at 4:50pm the day before.
I would like to set it up so that when I create a new event in my calendar, the default reminder time is at 8am that day. Message only, no email.
And the time it is set for is an hour ahead of the time I am creating the new event (i.e., if it is 12 noon when I open a new calendar appt, the default time for this appt sets at 1pm).
Is there a way to do these two things?
I am using iCal Version 5.0.3 / Mac OS X Version 10.7.5 (MacBook Air purchased in December of 2012).
Thank you!
Annette

Random audio timing errors

Here's a weird one:
In various Logic songs I experience audio tracks playing randomly out of time.
For instance, I will start playing the song at bar 35, everything plays fine, then I will play again from bar 35 and the cello track which has no audio at that bar will start playing something from another part of the song. I hit play once again at bar 35 and everything is fine. Hit play again, fine then one more time and the same cello track plays from somewhere else in the song. This happens with DAE audio tracks and with DTDM audio tracks. This happens in many different songs and at various locations within the songs.
Major glitch!
Quad G5 - 6.5 gig RAM Mac OS X (10.4.6) Logic 7.2.1 / ProTools 7.1cs6 HD2

This may be a fade file issue. Save, create, close, open... etc... sometimes the regions get wacky. There is an option to delete and rerender all fades from the audio window. May be your problem, maybe not. It happens often enough that this needs tobe in your arsenal/
J

Random Session Expiration

Hi,
I've been going through all related messages but nobody has answered this question clearly and stated the solution yet.
On our server, we use latest Resin version and its max session inactive time is 45 minutes. But user sessions are randomly getting timed out before 45 min is reached.
From a short list that i am suspected about following thigns might be a reason for this problem.
- An IE patch that people are talking about. (I don't use cookies in our application but people are talkign about changing some IE settigns in order to sovle the problem but it apperas like it is not the solution.)
- Resin Server
- A possible system Error (When a problem happens in our system, problem gets reproted and user gets kicked out to login page with a proper error message. But this is again so low probability.)
- Compilation of a new or modified class file (It is the most common reason but i can assure even thoguh there are no new classes the problem happens)
- SSL time-outs ?? (I am not sure if this is an exact option but if there is a possiblity of SSL connection expiration, i am suspecting it might be happening and expiring session before its supposable time.)
If anyone can tell me why a session could expire before max inactivity time is reached and no call is happened from application side to expire the session?
Thanks in advance.

URL rewriting is an alternative to using cookie to keep session. Of course if a particular URL does not have the JSESSIONID (or whatever) parameter in it, it is as good as anonymous/unlogon session. You should know if you are using URL rewriting by simply inspecting the URL.
The reason why I suspect load balancing is because certain load balancing software server may not be sensitive to session and thus redirect traffic (of a logon session) to another server which does not aware that the user is logon. However, most load balancing server does not suffer from this problem nowadays.
Have you tried to test run your app on a tomcat ? Can it be a resin problem ?
If you have the time and energy, you might want to try the following :
1. Use HttpSessionBindingListener to trap session binding/unbinding event. Then log info such timestamp, session id to a log file.
2. Run a periodic (say every minute) logging of all sessions information (such as browser PC IP addr, session ID, login userid, access URL). Then try to match this log with the session with the HttpSessionBindingListener log. If a session got unbind without prior access to logout URL or timeout (can be determined by finding its last access timestamp), then that may points you to possible causes/circumstances of the problem.

How long did it take for your Zen Touch battery to go down to two ba

Mine seemed fairly quick like 3-4 hours at most.

I wouldn't worry about it, if I were you. I was freaking out at first, worrying that I was only getting like 3 hours or something it seemed out of it. I just happened to be listening to it longer than I thought and listening to higher-bitrate (256k) songs. so I set it on random and timed how long it played (between 256k, 92, and 28k files randomly). The battery lasted for abou 2-23 hours if I remember correctly. So I found I didn't have a faulty one, so I was happy. Any shorter life must be because of changing songs frequently.

Good WMM Examples

Does anyone have a link to any good examples of how WMM works? I know the process is for the device to look for a clear signal, reduce down the random time and then send frame, but I'm having a hard time visualizing the exact process. Let me give an example (questions are in bold):
John and Rita are trying to access the network. John is using the VO (Video) class and Rita is using BE (Best Effort) class. Both produce a random wait time between 0 and the contention window minimum (lets say 2 for John and 4 for Rita). Let's say John's random number is 1 and Rita's is 4. So after they hear the channel is clear the reduce down the random number (how is this decremated, per microsecond or is there a different reduction?) and the frame is sent (does it just send the frame or does it check the channel again?). Since John has the lower random number he will send, but when Rita hits 0 she will check the channel and double her random number (again does she check the channel before sending? Also, does this start counting down after the channel is clear again?).
I don't know why I can't seem to wrap my head around this process but it's driving me nuts. Conceptually I understand it but I want to get into the nuts and bolts so I REALLY get it.
Thanks in advance.
Ryan

Well, the answer was somewhat in front of me (found here (page 2-11): https://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/vowlan/41dg/vowlan_ch2.pdf).
This bit is a decent example:
1. While Station X is transmitting its frame, three other stations determine that they must send a frame.
Each station defers because a frame was already being transmitted, and each station generates a
random backoff.
2. Because the Voice station has a traffic classification of voice, it has an arbitrated interframe space
(AIFS) of 2, and uses an initial CWmin of 3, and therefore must defer the countdown of its random
backoff for 2 slot times, and has a short random backoff value.
3. Best-effort has an AIFS of 3 and a longer random backoff time, because its CWmin value is 5.
4. Voice has the shortest random backoff time, and therefore starts transmitting first. When Voice starts
transmitting, all other stations defer.
5. After the Voice station finishes transmitting, all stations wait their AIFS, then begin to decrement
the random backoff counters again.
6. Best-effort then completes decrementing its random backoff counter and begins transmission. All
other stations defer. This can happen even though there might be a voice station waiting to transmit.
This shows that best-effort traffic is not starved by voice traffic because the random backoff
decrementing process eventually brings the best-effort backoff down to similar sizes as high priority
traffic, and that the random process might, on occasion, generate a small random backoff number
for best-effort traffic.
7. The process continues as other traffic enters the system. The AC settings shown in Table 2-3 and
Table 2-4 are, by default, the same for an 802.11a radio, and are based on formulas defined in
WMM.

Why can't I block certain people face timing and imessageing me? I keep receiving random facetime calls every 5 minutes got to the point where I have has to turn facetime off.

Why can't I block certain people face timing and imessageing me? I keep receiving random facetime calls every 5 minutes got to the point where I have has to turn facetime off.

I'm having the same problem, but it's also coming through on my computer, through my Apple email address. I have a very short Apple email, and little kids are trying to facetime their little friends, and then when I tell them I'm not their friend, they FaceTime or iMessage me even more, thinking that I'm still their friend, and I'm just kidding around.
I can't block the kids before they call...I don't know who they are. I want to restrict my FaceTime to only my phone number, and block all FaceTime and iMessage requests that are coming in through my email address. Can I do that?
I have another thread: https://discussions.apple.com/thread/5840011

RDWeb Site Timing Out Seemingly Random

We have a local cloud environemt the three session hosts, two gateways, and three connection brokers for all sorts of load balance and fail resistance. We have a rather annoying random problem that is plaguing our end users.
The RDweb site is timing out at random intervals, some within 5 minutes and others with multiple hours. I have gone into IIS and set the timeout for both private and public to six hours but still some are timing out short. I have also set the sessions to
never end unless they are idle for 6 hours as well. Any ideas on a setting I overlooked?
I also looked at the gateway and make sure the Authorization polices were set to 6 hours as well for idle sessions.
Server 2012 on all machines.

Hi Matthew,
Thank you for posting in Windows Server Forum.
From when you are facing this issue?
Is there any latest update which you have done?
If that’s the case, then please restart the server for proper working.
Have you find any related Event log on the server side when this issue happens? If so, please let’s know the detail including the Event ID.
Please enable RD Keep Alives on your server and then restart it. To do this logon to the server as an admin, Start-Run-gpedit.msc, in the left pane navigate to the following:
Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections
Configure keep-alive connection interval, select
Enabled, change the Keep-Alive interval to 2 and Restart your server. After this check the connection and verify whether there is any difference.
Hope it helps!
Thanks.
Dharmesh Solanki
TechNet Community Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact [email protected]

My iphone 4 randomly froze while i was face timing and now its just a black screen with thin grey lines on it. it wount turn on even if i press the lockscreen or home screen button. ive tried chargingit but that wont work either.

my iphone 4 randomly froze while i was face timing and now its just a black screen with thin grey lines on it. it wount turn on even if i press the lockscreen or home screen button. ive tried chargingit but that wont work either. It's been like this for about two hours now.

Hold down the Home and Power button for 20 seconds. And try to update again.
Also read and follow this:
http://www.apple.com/support/iphone/assistant/restore/

Macbook Air 2012: intermittent, random freezes of trackpad and keyboard lasting a few seconds each

There have been a few other people to have reported this problem, but there has been no consistent solution for me on my Macbook Air 13" 2012, running 10.8.4.
What happens is this: while typing, the built-in keyboard and trackpad will suddenly lock up at the same time, randomly, intermittently, and for just a few seconds before returning to normal. This has been true through all the updates of 10.8.x since I bought the system last year.
During the freeze, one of the three behaviors occurs:
1) both keyboard and trackpad are completely unresponsive
2) both keyboard and trackpad get really slow, with high latency. Keys pressed show up much later or have to be pressed several times before registering. Trackpad is jumpy if it moves at all.
3) key gets stuck, sometimes the BACKSPACE key, which usually results in several dozen emails getting deleted or entire paragraphs, or rows and rows of the same stuck key. Pressing other keys does nothing.
I've spoken online with various other people who have the same problem and confirmed that the built-in keyboard and trackpad seem to be joined together whenever this problem strikes. You never see one freeze without the other also freezing.
Also, these commonly-recommended solutions don't work:
a) Reset PRAM. Done this many times. Does nothing.
b) Bring it in to Apple. Did this too. They replaced the keyboard and trackpad but the problem remains.
c) Clearing caches in safe mode. No improvement.
d) Removing "com.google.keystone.deamon.plist" and "com.google.keystone.agent.plist" doesn't seem to work either, even though the errors and behavior are exactly the same for me as for george.e.gonzalez in this thread: https://discussions.apple.com/message/19702976#19702976
These files do come back, though, thanks to Google Software Update. The keystone software appears to be part of Google Chrome, although I cannot confirm this.
e) I DO have Google Android File Transfer installed like one other person reported; they said uninstalling it fixed the problem. Unfortunately, that has not worked for me. Also, Android File Transfer is installed (same version 1.0.50.2266, same Mac OS 10.8.4) on an older 2008 Macbook, and it works fine, which points to something on just this Macbook Air as being the cause.
f) I don't use the Radio Silence firewall app--can't remove it.
g) I don't have the telldus device or whatever it is, so I don't have the "com.telldus.service.plist" to remove.
h) Completely clearing out /Library/LaunchAgents, /Library/LaunchDaemons, and /Library/StartupItems doesn't do anything.
i) Repairing permissions or repairing the volume does nothing.
j) Reinstalling the OS fresh does nothing.
k) I don't have an external trackpad, mouse, or keyboard for testing while the freezing happens, but the machine itself seems to be working, just not the built-in input devices, which are on the same USB bus.
l) Pressing ESC does not stop the key stuck situation, as it does for some people.
It feels to me like a hardware problem, not an OS problem, and it feels like a USB bus issue. I have noticed that when I insert USB flash drives, I get the same lock-up for a few seconds, something which my other Macs don't do.
I've also noticed various USB errors in the Console around the same time (same as george.e.gonzalez):
7/26/13 1:20:04.000 AM kernel[0]: AppleUSBMultitouchDriver::_deviceGetReport - DeviceRequest for reportID 0x0 returned with result 0xe000404f - retrying
7/26/13 1:20:05.000 AM kernel[0]: USBF: 844075.636 AppleUSBEHCI[0xffffff80157f1000]::Found a transaction which hasn't moved in 5 seconds on bus 0x1a, timing out! (Addr: 2, EP: 0)
But I'm not able to precisely correlate these errors to the pause.
Is anybody else having this problem that can shed more light on it than these other suggested repairs? This has been frustrating for quite a while, but I've had the stuck BACKSPACE key delete hundreds of emails on a webmail platform that I was unable to recover using Undo and out of the trash, and that's just no longer tolerable...
Thank you, thank you, thank you, if anyone can help me fix this!

Hi, Dan--
Nope, none of those four... I do have Dropbox but never installed it on this machine. The other three are services I've never signed up for.
I am basically using these apps up-front:
Mail.app, Safari, Notes, Terminal, maybe LibreOffice 4.0.x, maybe Sublime Text 2, Console.
And the freezes happen about twice a day, usually when I'm in Mail or Terminal, but that's because those are the ones where I'm typing the most and can see immediately when the freezes happen. It could be happening even more frequently while I'm browsing, but I might not know it because I'm merely reading what's on the screen.
This is a list from Activity Monitor of what I'm using right now, which is very typical of what I use all day:
407
XType.FontHelper
dchang
0.0
2
2.8 MB
Intel (64 bit)
278
xpcd
dchang
0.0
2
5.0 MB
Intel (64 bit)
313
WebKitPluginAgent
dchang
0.0
2
944 KB
Intel (64 bit)
250
usernoted
dchang
0.0
2
4.0 MB
Intel (64 bit)
233
UserEventAgent
dchang
0.0
3
7.6 MB
Intel (64 bit)
347
Terminal
dchang
0.0
5
51.3 MB
Intel (64 bit)
280
tccd
dchang
0.0
2
3.8 MB
Intel (64 bit)
243
talagent
dchang
0.0
2
6.2 MB
Intel (64 bit)
244
SystemUIServer
dchang
0.1
3
26.5 MB
Intel (64 bit)
4254
System Preferences
dchang
0.5
3
24.8 MB
Intel (64 bit)
995
Sublime Text 2
dchang
0.0
12
82.5 MB
Intel (64 bit)
380
ssh-agent
dchang
0.0
3
3.0 MB
Intel (64 bit)
4321
ssh
dchang
0.0
1
2.0 MB
Intel (64 bit)
4276
ssh
dchang
0.0
1
2.0 MB
Intel (64 bit)
335
ShareKitHelper
dchang
0.0
2
9.1 MB
Intel (64 bit)
429
ScopedBookmarkAgent
dchang
0.0
2
5.0 MB
Intel (64 bit)
318
Safari Web Content
dchang
2.1
23
835.4 MB
Intel (64 bit)
316
Safari
dchang
0.2
17
127.9 MB
Intel (64 bit)
3975
QuickLookSatellite-general
dchang
0.0
4
6.0 MB
Intel (64 bit)
3974
Quick Look Helper
dchang
0.0
4
6.4 MB
Intel (64 bit)
3978
QTKitServer-(3975) QuickLookSatellite-general
dchang
0.0
2
3.7 MB
Intel
319
QTKitServer-(318) Safari Web Content
dchang
0.0
5
8.2 MB
Intel
3979
QTKitMoviesValidator-(3978) QTKitServer
dchang
0.0
3
5.3 MB
Intel
359
printtool
dchang
0.0
2
5.4 MB
Intel (64 bit)
327
pbs
dchang
0.0
4
3.7 MB
Intel (64 bit)
249
pboard
dchang
0.0
1
904 KB
Intel (64 bit)
254
Notification Center
dchang
0.0
3
18.4 MB
Intel (64 bit)
676
Notes
dchang
0.0
9
47.1 MB
Intel (64 bit)
277
NetworkBrowserAgent
dchang
0.0
3
4.4 MB
Intel (64 bit)
4156
mdworker
dchang
0.0
3
11.7 MB
Intel (64 bit)
298
Mail
dchang
0.0
11
151.5 MB
Intel (64 bit)
302
lsboxd
dchang
0.0
2
3.4 MB
Intel (64 bit)
54
loginwindow
dchang
0.1
2
25.8 MB
Intel (64 bit)
3589
LibreOffice
dchang
0.2
6
105.9 MB
Intel
230
launchd
dchang
0.0
2
1.4 MB
Intel (64 bit)
469
iTunes Helper
dchang
0.0
3
3.8 MB
Intel (64 bit)
258
imagent
dchang
0.0
3
5.3 MB
Intel (64 bit)
3508
Image Capture Extension
dchang
0.0
3
9.7 MB
Intel (64 bit)
3980
helpd
dchang
0.0
2
2.0 MB
Intel (64 bit)
270
fontd
dchang
0.0
2
6.5 MB
Intel (64 bit)
322
Flash Player (Safari Internet plug-in)
dchang
1.7
21
255.7 MB
Intel (64 bit)
245
Finder
dchang
0.1
5
73.1 MB
Intel (64 bit)
242
Dock
dchang
0.0
3
43.1 MB
Intel (64 bit)
234
distnoted
dchang
0.0
4
4.1 MB
Intel (64 bit)
3550
Dashboard
dchang
0.0
8
24.5 MB
Intel (64 bit)
663
cookied
dchang
0.0
2
3.4 MB
Intel (64 bit)
499
Console
dchang
0.0
2
26.8 MB
Intel (64 bit)
326
com.apple.NotesMigratorService
dchang
0.0
2
10.9 MB
Intel (64 bit)
4328
com.apple.iCloudHelper
dchang
0.0
3
5.5 MB
Intel (64 bit)
685
com.apple.hiservices-xpcservice
dchang
0.0
2
2.5 MB
Intel (64 bit)
315
com.apple.hiservices-xpcservice
dchang
0.0
2
2.5 MB
Intel (64 bit)
279
com.apple.dock.extra
dchang
0.0
2
13.9 MB
Intel (64 bit)
320
com.apple.audio.SandboxHelper
dchang
0.0
2
2.6 MB
Intel (64 bit)
3976
com.apple.audio.SandboxHelper
dchang
0.0
2
2.6 MB
Intel (64 bit)
3977
com.apple.audio.ComponentHelper
dchang
0.0
2
2.7 MB
Intel (64 bit)
321
com.apple.audio.ComponentHelper
dchang
0.0
2
2.9 MB
Intel (64 bit)
236
cfprefsd
dchang
0.0
4
11.6 MB
Intel (64 bit)
262
CalendarAgent
dchang
0.0
6
22.5 MB
Intel (64 bit)
4318
bash
dchang
0.0
1
1.2 MB
Intel (64 bit)
4121
bash
dchang
0.0
1
1.2 MB
Intel (64 bit)
329
AppleSpell.service
dchang
0.0
2
14.8 MB
Intel (64 bit)
261
AppleIDAuthAgent
dchang
0.0
3
2.0 MB
Intel (64 bit)
4330
Activity Monitor
dchang
2.5
5
17.9 MB
Intel (64 bit)
272
accountsd
dchang
0.0
2
3.5 MB
Intel (64 bit)
At this time, the only thing generating errors in the console log is the now-famous "coreaudiod[246]: Enabled automatic stack shots because audio IO is inactive" error that is considered normal behavior...

System freezes randomly for 5+ minutes at a time

Hi, I've been having random hard freezes (only remedy would to wait it out or push the dreaded power button while saying "shhhhhh, it'll be over soon" and weeping). I have looked at the logs and it seems journald has something to do with it, but I don't know what the problem is. I suspected that firefox/aurora globbling too much memory might be the problem, but the freezes occur even without any programs open at all except openbox and sxhkd.
Here's the relevant log which coincides with one of the times the freeze occurred:
Sep 29 12:14:44 Monaco systemd[1]: systemd-journald.service watchdog timeout (limit 1min)!
Sep 29 12:15:00 Monaco systemd-journal[133]: Journal stopped
Sep 29 12:17:27 Monaco systemd-journal[16848]: Permanent journal is using 32.0M (max allowed 20.0M, trying to leave 2.7G free of 6.0G available → current limit 32.0M).
Sep 29 12:17:34 Monaco systemd-journald[133]: Received SIGTERM from PID 1 (systemd).
Sep 29 12:17:36 Monaco systemd[1]: Unit systemd-journald.service entered failed state.
Sep 29 12:17:40 Monaco systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
Sep 29 12:17:43 Monaco systemd[1]: Stopping Journal Service...
Sep 29 12:17:43 Monaco systemd[1]: Starting Journal Service...
Sep 29 12:17:43 Monaco systemd[1]: Started Journal Service.
Sep 29 12:17:49 Monaco systemd-journal[16848]: Journal started
Sep 29 12:15:56 Monaco openvpn[11774]: Connection reset, restarting [0]
Sep 29 12:15:56 Monaco openvpn[11774]: SIGUSR1[soft,connection-reset] received, process restarting
Sep 29 12:15:56 Monaco openvpn[11774]: Restart pause, 5 second(s)
Sep 29 12:16:03 Monaco openvpn[11774]: Re-using pre-shared static key
Sep 29 12:25:56 Monaco systemd-journal[16896]: Permanent journal is using 36.0M (max allowed 20.0M, trying to leave 2.7G free of 6.0G available → current limit 36.0M).
Sep 29 12:25:56 Monaco systemd[1]: Starting Journal Service...
Sep 29 12:25:56 Monaco systemd[1]: systemd-journald.service stop-sigterm timed out. Killing.
Sep 29 12:25:56 Monaco systemd[1]: Starting Journal Service...
Sep 29 12:25:56 Monaco systemd[1]: systemd-journald.service: main process exited, code=killed, status=9/KILL
Sep 29 12:25:56 Monaco systemd[1]: Unit systemd-journald.service entered failed state.
Sep 29 12:25:56 Monaco kernel: termite invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Sep 29 12:25:56 Monaco kernel: termite cpuset=/ mems_allowed=0
Sep 29 12:25:56 Monaco kernel: CPU: 1 PID: 16841 Comm: termite Tainted: P O 3.16.3-1-ARCH #1
Sep 29 12:25:56 Monaco kernel: Hardware name: HP-Pavilion GN551AA-ABA m8200n/Nettle2, BIOS 5.16 08/14/2007
Sep 29 12:25:56 Monaco kernel: 0000000000000000 00000000b33a5399 ffff88004697ba08 ffffffff8152b3bc
Sep 29 12:25:56 Monaco kernel: ffff88003ecd5180 ffff88004697ba80 ffffffff8152a89a ffffffff8106e696
Sep 29 12:25:56 Monaco kernel: ffff88004697ba70 ffffffff810d544c 00000000b33a5399 00000000000200da
Sep 29 12:25:56 Monaco kernel: Call Trace:
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152b3bc>] dump_stack+0x4d/0x6f
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152a89a>] dump_header+0xad/0x235
Sep 29 12:25:56 Monaco kernel: [<ffffffff8106e696>] ? put_online_cpus+0x56/0x90
Sep 29 12:25:56 Monaco kernel: [<ffffffff810d544c>] ? rcu_oom_notify+0xdc/0x110
Sep 29 12:25:56 Monaco kernel: [<ffffffff8114fd0c>] oom_kill_process+0x26c/0x3f0
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b35>] ? has_ns_capability_noaudit+0x35/0x50
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b67>] ? has_capability_noaudit+0x17/0x20
Sep 29 12:25:56 Monaco kernel: [<ffffffff811505cb>] out_of_memory+0x52b/0x580
Sep 29 12:25:56 Monaco kernel: [<ffffffff8115631d>] __alloc_pages_nodemask+0xbfd/0xc20
Sep 29 12:25:56 Monaco kernel: [<ffffffff8119c04f>] alloc_pages_vma+0xaf/0x1c0
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117acb4>] do_cow_fault+0x64/0x250
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117ccf4>] handle_mm_fault+0x6c4/0x1090
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c3cf>] __do_page_fault+0x18f/0x600
Sep 29 12:25:56 Monaco kernel: [<ffffffff81184741>] ? mprotect_fixup+0x151/0x260
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c862>] do_page_fault+0x22/0x30
Sep 29 12:25:56 Monaco kernel: [<ffffffff81532ff8>] page_fault+0x28/0x30
Sep 29 12:25:56 Monaco kernel: Mem-Info:
Sep 29 12:25:56 Monaco kernel: Node 0 DMA per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 186, btch: 31 usd: 171
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 186, btch: 31 usd: 30
Sep 29 12:25:56 Monaco kernel: active_anon:566070 inactive_anon:141732 isolated_anon:0
active_file:784 inactive_file:815 isolated_file:0
unevictable:34 dirty:0 writeback:24 unstable:0
free:14235 slab_reclaimable:5656 slab_unreclaimable:5394
mapped:10704 shmem:8528 pagetables:6076 bounce:0
free_cma:0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA free:12212kB min:232kB low:288kB high:348kB active_anon:1056kB inactive_anon:1108kB active_file:40kB inactive_file:84kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15976kB managed:15892kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:56kB slab_unreclaimable:60kB kernel_stack:32kB pagetables:28kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:2455 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 2995 2995 2995
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 free:44728kB min:44820kB low:56024kB high:67228kB active_anon:2263224kB inactive_anon:565820kB active_file:3096kB inactive_file:3176kB unevictable:136kB isolated(anon):0kB isolated(file):0kB present:3128192kB managed:3069416kB mlocked:136kB dirty:0kB writeback:96kB mapped:42816kB shmem:34112kB slab_reclaimable:22568kB slab_unreclaimable:21516kB kernel_stack:4096kB pagetables:24276kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:9562 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 0 0 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA: 7*4kB (UE) 7*8kB (UEM) 2*16kB (U) 12*32kB (UEM) 9*64kB (UM) 1*128kB (E) 1*256kB (E) 1*512kB (E) 2*1024kB (EM) 2*2048kB (ER) 1*4096kB (M) = 12212kB
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32: 244*4kB (UEM) 341*8kB (UE) 250*16kB (UEM) 203*32kB (UEM) 237*64kB (UEM) 94*128kB (UEM) 13*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44728kB
Sep 29 12:25:56 Monaco kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Sep 29 12:25:56 Monaco kernel: 10380 total pagecache pages
Sep 29 12:25:56 Monaco kernel: 265 pages in swap cache
Sep 29 12:25:56 Monaco kernel: Swap cache stats: add 548468, delete 548203, find 29936/36511
Sep 29 12:25:56 Monaco kernel: Free swap = 0kB
Sep 29 12:25:56 Monaco kernel: Total swap = 2116244kB
Sep 29 12:25:56 Monaco kernel: 786042 pages RAM
Sep 29 12:25:56 Monaco kernel: 0 pages HighMem/MovableOnly
Sep 29 12:25:56 Monaco kernel: 14694 pages reserved
Sep 29 12:25:56 Monaco kernel: 0 pages hwpoisoned
Sep 29 12:25:56 Monaco kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Sep 29 12:25:56 Monaco kernel: [ 158] 0 158 8069 14 18 152 -1000 systemd-udevd
Sep 29 12:25:56 Monaco kernel: [ 222] 0 222 4270 60 11 110 0 mount.ntfs-3g
Sep 29 12:25:56 Monaco kernel: [ 234] 0 234 3793 43 11 25 0 systemd-logind
Sep 29 12:25:56 Monaco kernel: [ 235] 0 235 18482 0 40 343 0 cupsd
Sep 29 12:25:56 Monaco kernel: [ 236] 81 236 6275 81 17 82 -900 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 238] 0 238 1106 34 8 21 0 dhcpcd
Sep 29 12:25:56 Monaco kernel: [ 249] 0 249 9997 3 24 146 -1000 sshd
Sep 29 12:25:56 Monaco kernel: [ 251] 32 251 7713 16 20 73 0 rpcbind
Sep 29 12:25:56 Monaco kernel: [ 259] 0 259 8726 0 20 92 0 lircd
Sep 29 12:25:56 Monaco kernel: [ 260] 124 260 72948 2 42 590 0 colord
Sep 29 12:25:56 Monaco kernel: [ 283] 0 283 17646 2 39 143 0 login
Sep 29 12:25:56 Monaco kernel: [ 301] 0 301 69839 66 133 493 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 304] 0 304 69970 86 130 473 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 307] 1000 307 6700 0 16 146 0 systemd
Sep 29 12:25:56 Monaco kernel: [ 309] 1000 309 18439 123 36 429 0 (sd-pam)
Sep 29 12:25:56 Monaco kernel: [ 311] 1000 311 10143 2 24 477 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 332] 1000 332 3817 2 12 109 0 startx
Sep 29 12:25:56 Monaco kernel: [ 354] 1000 354 3980 0 13 54 0 xinit
Sep 29 12:25:56 Monaco kernel: [ 355] 1000 355 65132 9680 112 4643 0 Xorg.bin
Sep 29 12:25:56 Monaco kernel: [ 401] 1000 401 51109 1696 99 4190 0 openbox
Sep 29 12:25:56 Monaco kernel: [ 412] 1000 412 158444 522 134 5366 0 mpd
Sep 29 12:25:56 Monaco kernel: [ 414] 1000 414 3160 21 12 25 0 sxhkd
Sep 29 12:25:56 Monaco kernel: [ 415] 1000 415 52991 173 105 3950 0 volumeicon
Sep 29 12:25:56 Monaco kernel: [ 416] 1000 416 47411 109 96 3123 0 tint2
Sep 29 12:25:56 Monaco kernel: [ 424] 1000 424 4507 0 13 70 0 dbus-launch
Sep 29 12:25:56 Monaco kernel: [ 425] 1000 425 6215 56 17 46 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 427] 1000 427 83835 0 32 192 0 at-spi-bus-laun
Sep 29 12:25:56 Monaco kernel: [ 431] 1000 431 6189 23 18 57 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 434] 1000 434 30771 40 30 148 0 at-spi2-registr
Sep 29 12:25:56 Monaco kernel: [ 496] 1000 496 71998 496 105 3768 0 termite
Sep 29 12:25:56 Monaco kernel: [ 497] 1000 497 10168 2 25 481 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 518] 1000 518 4781 2 15 66 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 520] 1000 520 5365 74 15 71 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 521] 1000 521 10735 2 26 535 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1087] 1000 1087 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1093] 1000 1093 36873 0 38 157 0 chromedriver
Sep 29 12:25:56 Monaco kernel: [ 1278] 1000 1278 8763 2 21 84 0 xfconfd
Sep 29 12:25:56 Monaco kernel: [ 1284] 1000 1284 109910 967 139 4237 0 keepassx
Sep 29 12:25:56 Monaco kernel: [ 1288] 1000 1288 11207 35 26 59 0 gconfd-2
Sep 29 12:25:56 Monaco kernel: [ 1444] 1000 1444 44034 2 22 154 0 dconf-service
Sep 29 12:25:56 Monaco kernel: [ 4107] 1000 4107 46937 1858 91 3445 0 weechat
Sep 29 12:25:56 Monaco kernel: [ 7602] 1000 7602 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 7605] 1000 7605 3818 2 13 121 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7615] 1000 7615 3886 2 13 168 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7616] 1000 7616 1873 2 10 21 0 tee
Sep 29 12:25:56 Monaco kernel: [11774] 99 11774 6141 70 17 71 0 openvpn
Sep 29 12:25:56 Monaco kernel: [13718] 1000 13718 5560 2 17 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13721] 1000 13721 94096 2319 150 5932 0 sonata
Sep 29 12:25:56 Monaco kernel: [13897] 1000 13897 5560 2 16 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13900] 1000 13900 1217352 653232 2274 376361 0 aurora
Sep 29 12:25:56 Monaco kernel: [14180] 1000 14180 70205 262 102 4007 0 termite
Sep 29 12:25:56 Monaco kernel: [14182] 1000 14182 87917 5172 78 3419 0 livestreamer
Sep 29 12:25:56 Monaco kernel: [14190] 1000 14190 356932 11656 374 6706 0 vlc
Sep 29 12:25:56 Monaco kernel: [16825] 1000 16825 48332 2732 79 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16841] 1000 16841 48332 2065 77 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16851] 1000 16851 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16853] 1000 16853 30085 118 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16857] 1000 16857 30085 119 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16859] 1000 16859 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16861] 1000 16861 30085 118 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16863] 1000 16863 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16865] 1000 16865 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16867] 1000 16867 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16869] 1000 16869 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16882] 0 16882 69839 88 125 471 0 smbd
Sep 29 12:25:56 Monaco kernel: Out of memory: Kill process 13900 (aurora) score 793 or sacrifice child
Sep 29 12:25:56 Monaco kernel: Killed process 14180 (termite) total-vm:280820kB, anon-rss:1048kB, file-rss:0kB
Sep 29 12:25:56 Monaco kernel: termite invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Sep 29 12:25:56 Monaco kernel: termite cpuset=/ mems_allowed=0
Sep 29 12:25:56 Monaco kernel: CPU: 1 PID: 16841 Comm: termite Tainted: P O 3.16.3-1-ARCH #1
Sep 29 12:25:56 Monaco kernel: Hardware name: HP-Pavilion GN551AA-ABA m8200n/Nettle2, BIOS 5.16 08/14/2007
Sep 29 12:25:56 Monaco kernel: 0000000000000000 00000000b33a5399 ffff88004697ba08 ffffffff8152b3bc
Sep 29 12:25:56 Monaco kernel: ffff88003ecd5180 ffff88004697ba80 ffffffff8152a89a ffffffff8106e696
Sep 29 12:25:56 Monaco kernel: ffff88004697ba70 ffffffff810d544c 00000000b33a5399 00000000000200da
Sep 29 12:25:56 Monaco kernel: Call Trace:
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152b3bc>] dump_stack+0x4d/0x6f
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152a89a>] dump_header+0xad/0x235
Sep 29 12:25:56 Monaco kernel: [<ffffffff8106e696>] ? put_online_cpus+0x56/0x90
Sep 29 12:25:56 Monaco kernel: [<ffffffff810d544c>] ? rcu_oom_notify+0xdc/0x110
Sep 29 12:25:56 Monaco kernel: [<ffffffff8114fd0c>] oom_kill_process+0x26c/0x3f0
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b35>] ? has_ns_capability_noaudit+0x35/0x50
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b67>] ? has_capability_noaudit+0x17/0x20
Sep 29 12:25:56 Monaco kernel: [<ffffffff811505cb>] out_of_memory+0x52b/0x580
Sep 29 12:25:56 Monaco kernel: [<ffffffff8115631d>] __alloc_pages_nodemask+0xbfd/0xc20
Sep 29 12:25:56 Monaco kernel: [<ffffffff8119c04f>] alloc_pages_vma+0xaf/0x1c0
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117acb4>] do_cow_fault+0x64/0x250
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117ccf4>] handle_mm_fault+0x6c4/0x1090
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c3cf>] __do_page_fault+0x18f/0x600
Sep 29 12:25:56 Monaco kernel: [<ffffffff81184741>] ? mprotect_fixup+0x151/0x260
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c862>] do_page_fault+0x22/0x30
Sep 29 12:25:56 Monaco kernel: [<ffffffff81532ff8>] page_fault+0x28/0x30
Sep 29 12:25:56 Monaco kernel: Mem-Info:
Sep 29 12:25:56 Monaco kernel: Node 0 DMA per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 186, btch: 31 usd: 176
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 186, btch: 31 usd: 33
Sep 29 12:25:56 Monaco kernel: active_anon:566070 inactive_anon:141732 isolated_anon:0
active_file:792 inactive_file:793 isolated_file:0
unevictable:34 dirty:0 writeback:24 unstable:0
free:14235 slab_reclaimable:5656 slab_unreclaimable:5394
mapped:10704 shmem:8528 pagetables:6076 bounce:0
free_cma:0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA free:12212kB min:232kB low:288kB high:348kB active_anon:1056kB inactive_anon:1108kB active_file:72kB inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15976kB managed:15892kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:56kB slab_unreclaimable:60kB kernel_stack:32kB pagetables:28kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:2492 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 2995 2995 2995
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 free:44728kB min:44820kB low:56024kB high:67228kB active_anon:2263224kB inactive_anon:565820kB active_file:3096kB inactive_file:3124kB unevictable:136kB isolated(anon):0kB isolated(file):0kB present:3128192kB managed:3069416kB mlocked:136kB dirty:0kB writeback:96kB mapped:42816kB shmem:34112kB slab_reclaimable:22568kB slab_unreclaimable:21516kB kernel_stack:4096kB pagetables:24276kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:9658 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 0 0 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA: 7*4kB (UE) 7*8kB (UEM) 2*16kB (U) 12*32kB (UEM) 9*64kB (UM) 1*128kB (E) 1*256kB (E) 1*512kB (E) 2*1024kB (EM) 2*2048kB (ER) 1*4096kB (M) = 12212kB
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32: 244*4kB (UEM) 341*8kB (UE) 250*16kB (UEM) 203*32kB (UEM) 237*64kB (UEM) 94*128kB (UEM) 13*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 44728kB
Sep 29 12:25:56 Monaco kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Sep 29 12:25:56 Monaco kernel: 10380 total pagecache pages
Sep 29 12:25:56 Monaco kernel: 265 pages in swap cache
Sep 29 12:25:56 Monaco kernel: Swap cache stats: add 548468, delete 548203, find 29936/36512
Sep 29 12:25:56 Monaco kernel: Free swap = 0kB
Sep 29 12:25:56 Monaco kernel: Total swap = 2116244kB
Sep 29 12:25:56 Monaco kernel: 786042 pages RAM
Sep 29 12:25:56 Monaco kernel: 0 pages HighMem/MovableOnly
Sep 29 12:25:56 Monaco kernel: 14694 pages reserved
Sep 29 12:25:56 Monaco kernel: 0 pages hwpoisoned
Sep 29 12:25:56 Monaco kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Sep 29 12:25:56 Monaco kernel: [ 158] 0 158 8069 14 18 152 -1000 systemd-udevd
Sep 29 12:25:56 Monaco kernel: [ 222] 0 222 4270 60 11 110 0 mount.ntfs-3g
Sep 29 12:25:56 Monaco kernel: [ 234] 0 234 3793 43 11 25 0 systemd-logind
Sep 29 12:25:56 Monaco kernel: [ 235] 0 235 18482 0 40 343 0 cupsd
Sep 29 12:25:56 Monaco kernel: [ 236] 81 236 6275 81 17 82 -900 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 238] 0 238 1106 34 8 21 0 dhcpcd
Sep 29 12:25:56 Monaco kernel: [ 249] 0 249 9997 3 24 146 -1000 sshd
Sep 29 12:25:56 Monaco kernel: [ 251] 32 251 7713 16 20 73 0 rpcbind
Sep 29 12:25:56 Monaco kernel: [ 259] 0 259 8726 0 20 92 0 lircd
Sep 29 12:25:56 Monaco kernel: [ 260] 124 260 72948 2 42 590 0 colord
Sep 29 12:25:56 Monaco kernel: [ 283] 0 283 17646 2 39 143 0 login
Sep 29 12:25:56 Monaco kernel: [ 301] 0 301 69839 66 133 493 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 304] 0 304 69970 86 130 473 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 307] 1000 307 6700 0 16 146 0 systemd
Sep 29 12:25:56 Monaco kernel: [ 309] 1000 309 18439 123 36 429 0 (sd-pam)
Sep 29 12:25:56 Monaco kernel: [ 311] 1000 311 10143 2 24 477 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 332] 1000 332 3817 2 12 109 0 startx
Sep 29 12:25:56 Monaco kernel: [ 354] 1000 354 3980 0 13 54 0 xinit
Sep 29 12:25:56 Monaco kernel: [ 355] 1000 355 65132 9680 112 4643 0 Xorg.bin
Sep 29 12:25:56 Monaco kernel: [ 401] 1000 401 51109 1696 99 4190 0 openbox
Sep 29 12:25:56 Monaco kernel: [ 412] 1000 412 158444 522 134 5366 0 mpd
Sep 29 12:25:56 Monaco kernel: [ 414] 1000 414 3160 21 12 25 0 sxhkd
Sep 29 12:25:56 Monaco kernel: [ 415] 1000 415 52991 173 105 3950 0 volumeicon
Sep 29 12:25:56 Monaco kernel: [ 416] 1000 416 47411 109 96 3123 0 tint2
Sep 29 12:25:56 Monaco kernel: [ 424] 1000 424 4507 0 13 70 0 dbus-launch
Sep 29 12:25:56 Monaco kernel: [ 425] 1000 425 6215 56 17 46 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 427] 1000 427 83835 0 32 192 0 at-spi-bus-laun
Sep 29 12:25:56 Monaco kernel: [ 431] 1000 431 6189 23 18 57 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 434] 1000 434 30771 40 30 148 0 at-spi2-registr
Sep 29 12:25:56 Monaco kernel: [ 496] 1000 496 71998 496 105 3768 0 termite
Sep 29 12:25:56 Monaco kernel: [ 497] 1000 497 10168 2 25 481 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 518] 1000 518 4781 2 15 66 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 520] 1000 520 5365 74 15 71 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 521] 1000 521 10735 2 26 535 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1087] 1000 1087 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1093] 1000 1093 36873 0 38 157 0 chromedriver
Sep 29 12:25:56 Monaco kernel: [ 1278] 1000 1278 8763 2 21 84 0 xfconfd
Sep 29 12:25:56 Monaco kernel: [ 1284] 1000 1284 109910 967 139 4237 0 keepassx
Sep 29 12:25:56 Monaco kernel: [ 1288] 1000 1288 11207 35 26 59 0 gconfd-2
Sep 29 12:25:56 Monaco kernel: [ 1444] 1000 1444 44034 2 22 154 0 dconf-service
Sep 29 12:25:56 Monaco kernel: [ 4107] 1000 4107 46937 1858 91 3445 0 weechat
Sep 29 12:25:56 Monaco kernel: [ 7602] 1000 7602 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 7605] 1000 7605 3818 2 13 121 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7615] 1000 7615 3886 2 13 168 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7616] 1000 7616 1873 2 10 21 0 tee
Sep 29 12:25:56 Monaco kernel: [11774] 99 11774 6141 70 17 71 0 openvpn
Sep 29 12:25:56 Monaco kernel: [13718] 1000 13718 5560 2 17 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13897] 1000 13897 5560 2 16 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13900] 1000 13900 1217352 653232 2274 376361 0 aurora
Sep 29 12:25:56 Monaco kernel: [14183] 1000 14180 70205 265 102 4006 0 gmain
Sep 29 12:25:56 Monaco kernel: [14182] 1000 14182 87917 5172 78 3419 0 livestreamer
Sep 29 12:25:56 Monaco kernel: [14190] 1000 14190 356932 11656 374 6706 0 vlc
Sep 29 12:25:56 Monaco kernel: [16825] 1000 16825 48332 2732 79 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16841] 1000 16841 48332 2065 77 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16851] 1000 16851 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16853] 1000 16853 30085 118 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16857] 1000 16857 30085 119 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16859] 1000 16859 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16861] 1000 16861 30085 118 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16863] 1000 16863 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16865] 1000 16865 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16867] 1000 16867 30085 118 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16869] 1000 16869 30085 119 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16882] 0 16882 69839 88 125 471 0 smbd
Sep 29 12:25:56 Monaco kernel: Out of memory: Kill process 13900 (aurora) score 793 or sacrifice child
Sep 29 12:25:56 Monaco kernel: Killed process 14183 (gmain) total-vm:280820kB, anon-rss:1052kB, file-rss:8kB
Sep 29 12:25:56 Monaco systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
Sep 29 12:25:56 Monaco systemd[1]: Stopping Journal Service...
Sep 29 12:25:56 Monaco systemd[1]: Starting Journal Service...
Sep 29 12:25:56 Monaco systemd[1]: Started Journal Service.
Sep 29 12:25:56 Monaco kernel: termite invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Sep 29 12:25:56 Monaco kernel: termite cpuset=/ mems_allowed=0
Sep 29 12:25:56 Monaco kernel: CPU: 1 PID: 16867 Comm: termite Tainted: P O 3.16.3-1-ARCH #1
Sep 29 12:25:56 Monaco kernel: Hardware name: HP-Pavilion GN551AA-ABA m8200n/Nettle2, BIOS 5.16 08/14/2007
Sep 29 12:25:56 Monaco kernel: 0000000000000000 00000000db03e644 ffff880007f17a08 ffffffff8152b3bc
Sep 29 12:25:56 Monaco kernel: ffff88003ecd5180 ffff880007f17a80 ffffffff8152a89a ffffffff8106e696
Sep 29 12:25:56 Monaco kernel: ffff880007f17a70 ffffffff810d544c 00000000db03e644 00000000000200da
Sep 29 12:25:56 Monaco kernel: Call Trace:
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152b3bc>] dump_stack+0x4d/0x6f
Sep 29 12:25:56 Monaco kernel: [<ffffffff8152a89a>] dump_header+0xad/0x235
Sep 29 12:25:56 Monaco kernel: [<ffffffff8106e696>] ? put_online_cpus+0x56/0x90
Sep 29 12:25:56 Monaco kernel: [<ffffffff810d544c>] ? rcu_oom_notify+0xdc/0x110
Sep 29 12:25:56 Monaco kernel: [<ffffffff8114fd0c>] oom_kill_process+0x26c/0x3f0
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b35>] ? has_ns_capability_noaudit+0x35/0x50
Sep 29 12:25:56 Monaco kernel: [<ffffffff81077b67>] ? has_capability_noaudit+0x17/0x20
Sep 29 12:25:56 Monaco kernel: [<ffffffff811505cb>] out_of_memory+0x52b/0x580
Sep 29 12:25:56 Monaco kernel: [<ffffffff8115631d>] __alloc_pages_nodemask+0xbfd/0xc20
Sep 29 12:25:56 Monaco kernel: [<ffffffff8119c04f>] alloc_pages_vma+0xaf/0x1c0
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117acb4>] do_cow_fault+0x64/0x250
Sep 29 12:25:56 Monaco kernel: [<ffffffff8117ccf4>] handle_mm_fault+0x6c4/0x1090
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c3cf>] __do_page_fault+0x18f/0x600
Sep 29 12:25:56 Monaco kernel: [<ffffffff81184741>] ? mprotect_fixup+0x151/0x260
Sep 29 12:25:56 Monaco kernel: [<ffffffff8105c862>] do_page_fault+0x22/0x30
Sep 29 12:25:56 Monaco kernel: [<ffffffff81532ff8>] page_fault+0x28/0x30
Sep 29 12:25:56 Monaco kernel: Mem-Info:
Sep 29 12:25:56 Monaco kernel: Node 0 DMA per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 0, btch: 1 usd: 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 per-cpu:
Sep 29 12:25:56 Monaco kernel: CPU 0: hi: 186, btch: 31 usd: 138
Sep 29 12:25:56 Monaco kernel: CPU 1: hi: 186, btch: 31 usd: 128
Sep 29 12:25:56 Monaco kernel: active_anon:565660 inactive_anon:141680 isolated_anon:0
active_file:33 inactive_file:39 isolated_file:0
unevictable:34 dirty:6 writeback:1590 unstable:0
free:16000 slab_reclaimable:5526 slab_unreclaimable:5480
mapped:10239 shmem:8528 pagetables:5958 bounce:0
free_cma:0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA free:12156kB min:232kB low:288kB high:348kB active_anon:1060kB inactive_anon:1208kB active_file:32kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15976kB managed:15892kB mlocked:0kB dirty:4kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:56kB slab_unreclaimable:60kB kernel_stack:32kB pagetables:28kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:68 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 2995 2995 2995
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32 free:51844kB min:44820kB low:56024kB high:67228kB active_anon:2261580kB inactive_anon:565512kB active_file:100kB inactive_file:184kB unevictable:136kB isolated(anon):0kB isolated(file):0kB present:3128192kB managed:3069416kB mlocked:136kB dirty:20kB writeback:6360kB mapped:40952kB shmem:34112kB slab_reclaimable:22048kB slab_unreclaimable:21860kB kernel_stack:4224kB pagetables:23804kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:429 all_unreclaimable? yes
Sep 29 12:25:56 Monaco kernel: lowmem_reserve[]: 0 0 0 0
Sep 29 12:25:56 Monaco kernel: Node 0 DMA: 10*4kB (UEM) 5*8kB (UE) 4*16kB (UEM) 10*32kB (UEM) 9*64kB (UM) 1*128kB (E) 1*256kB (E) 1*512kB (E) 2*1024kB (EM) 2*2048kB (ER) 1*4096kB (M) = 12176kB
Sep 29 12:25:56 Monaco kernel: Node 0 DMA32: 1586*4kB (UEM) 519*8kB (UEM) 268*16kB (UEM) 198*32kB (UEM) 227*64kB (UEM) 99*128kB (UEM) 14*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 51904kB
Sep 29 12:25:56 Monaco kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Sep 29 12:25:56 Monaco kernel: 10971 total pagecache pages
Sep 29 12:25:56 Monaco kernel: 2314 pages in swap cache
Sep 29 12:25:56 Monaco kernel: Swap cache stats: add 556759, delete 554445, find 391956/398651
Sep 29 12:25:56 Monaco kernel: Free swap = 0kB
Sep 29 12:25:56 Monaco kernel: Total swap = 2116244kB
Sep 29 12:25:56 Monaco kernel: 786042 pages RAM
Sep 29 12:25:56 Monaco kernel: 0 pages HighMem/MovableOnly
Sep 29 12:25:56 Monaco kernel: 14694 pages reserved
Sep 29 12:25:56 Monaco kernel: 0 pages hwpoisoned
Sep 29 12:25:56 Monaco kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Sep 29 12:25:56 Monaco kernel: [ 158] 0 158 8069 14 18 152 -1000 systemd-udevd
Sep 29 12:25:56 Monaco kernel: [ 222] 0 222 4270 60 11 110 0 mount.ntfs-3g
Sep 29 12:25:56 Monaco kernel: [ 234] 0 234 3793 43 11 25 0 systemd-logind
Sep 29 12:25:56 Monaco kernel: [ 235] 0 235 18482 0 40 343 0 cupsd
Sep 29 12:25:56 Monaco kernel: [ 236] 81 236 6275 81 17 82 -900 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 238] 0 238 1106 34 8 21 0 dhcpcd
Sep 29 12:25:56 Monaco kernel: [ 249] 0 249 9997 3 24 146 -1000 sshd
Sep 29 12:25:56 Monaco kernel: [ 251] 32 251 7713 16 20 73 0 rpcbind
Sep 29 12:25:56 Monaco kernel: [ 259] 0 259 8726 0 20 92 0 lircd
Sep 29 12:25:56 Monaco kernel: [ 260] 124 260 72948 2 42 590 0 colord
Sep 29 12:25:56 Monaco kernel: [ 283] 0 283 17646 2 39 143 0 login
Sep 29 12:25:56 Monaco kernel: [ 301] 0 301 69839 66 133 493 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 304] 0 304 69970 86 130 473 0 smbd
Sep 29 12:25:56 Monaco kernel: [ 307] 1000 307 6700 0 16 146 0 systemd
Sep 29 12:25:56 Monaco kernel: [ 309] 1000 309 18439 123 36 429 0 (sd-pam)
Sep 29 12:25:56 Monaco kernel: [ 311] 1000 311 10143 2 24 477 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 332] 1000 332 3817 2 12 109 0 startx
Sep 29 12:25:56 Monaco kernel: [ 354] 1000 354 3980 0 13 54 0 xinit
Sep 29 12:25:56 Monaco kernel: [ 355] 1000 355 65470 9962 112 4632 0 Xorg.bin
Sep 29 12:25:56 Monaco kernel: [ 401] 1000 401 51109 1696 99 4190 0 openbox
Sep 29 12:25:56 Monaco kernel: [ 412] 1000 412 158444 522 134 5366 0 mpd
Sep 29 12:25:56 Monaco kernel: [ 414] 1000 414 3160 21 12 25 0 sxhkd
Sep 29 12:25:56 Monaco kernel: [ 415] 1000 415 52991 173 105 3950 0 volumeicon
Sep 29 12:25:56 Monaco kernel: [ 416] 1000 416 47411 109 96 3123 0 tint2
Sep 29 12:25:56 Monaco kernel: [ 424] 1000 424 4507 0 13 70 0 dbus-launch
Sep 29 12:25:56 Monaco kernel: [ 425] 1000 425 6215 56 17 46 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 427] 1000 427 83835 0 32 192 0 at-spi-bus-laun
Sep 29 12:25:56 Monaco kernel: [ 431] 1000 431 6189 23 18 57 0 dbus-daemon
Sep 29 12:25:56 Monaco kernel: [ 434] 1000 434 30771 40 30 148 0 at-spi2-registr
Sep 29 12:25:56 Monaco kernel: [ 496] 1000 496 71998 499 105 3765 0 termite
Sep 29 12:25:56 Monaco kernel: [ 497] 1000 497 10168 2 25 481 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 518] 1000 518 4781 2 15 66 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 520] 1000 520 5365 74 15 71 0 tmux
Sep 29 12:25:56 Monaco kernel: [ 521] 1000 521 10735 2 26 535 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1087] 1000 1087 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 1278] 1000 1278 8763 2 21 84 0 xfconfd
Sep 29 12:25:56 Monaco kernel: [ 1284] 1000 1284 109910 967 139 4237 0 keepassx
Sep 29 12:25:56 Monaco kernel: [ 1288] 1000 1288 11207 35 26 59 0 gconfd-2
Sep 29 12:25:56 Monaco kernel: [ 1444] 1000 1444 44034 2 22 154 0 dconf-service
Sep 29 12:25:56 Monaco kernel: [ 4107] 1000 4107 46934 1884 91 3424 0 weechat
Sep 29 12:25:56 Monaco kernel: [ 7602] 1000 7602 5560 2 16 109 0 zsh
Sep 29 12:25:56 Monaco kernel: [ 7605] 1000 7605 3818 2 13 121 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7615] 1000 7615 3886 2 13 168 0 bash
Sep 29 12:25:56 Monaco kernel: [ 7616] 1000 7616 1873 2 10 21 0 tee
Sep 29 12:25:56 Monaco kernel: [11774] 99 11774 6141 70 17 71 0 openvpn
Sep 29 12:25:56 Monaco kernel: [13718] 1000 13718 5560 2 17 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13897] 1000 13897 5560 2 16 108 0 zsh
Sep 29 12:25:56 Monaco kernel: [13900] 1000 13900 1217352 645627 2274 383966 0 aurora
Sep 29 12:25:56 Monaco kernel: [16825] 1000 16825 48325 2931 90 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16841] 1000 16841 48325 2932 90 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16851] 1000 16851 48332 2316 77 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16853] 1000 16853 48325 2932 87 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16857] 1000 16857 30085 121 53 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16859] 1000 16859 30085 121 54 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16861] 1000 16861 48332 548 69 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16863] 1000 16863 30929 121 55 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16865] 1000 16865 48332 308 68 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16867] 1000 16867 48332 1870 75 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16869] 1000 16869 48332 1864 75 0 0 termite
Sep 29 12:25:56 Monaco kernel: [16896] 0 16896 186 2 3 0 0 systemd-journal
Sep 29 12:25:56 Monaco kernel: [16897] 0 16897 1328 12 4 0 0 systemctl
Sep 29 12:25:56 Monaco kernel: Out of memory: Kill process 13900 (aurora) score 793 or sacrifice child
Sep 29 12:25:56 Monaco kernel: Killed process 13900 (aurora) total-vm:4869408kB, anon-rss:2582508kB, file-rss:0kB
Sep 29 12:25:56 Monaco systemd-journal[16896]: Journal started
Sep 29 12:16:41 Monaco systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
Sep 29 12:17:48 Monaco systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
Sep 29 12:17:49 Monaco systemd[1]: Looping too fast. Throttling execution a little.
Sep 29 12:20:19 Monaco systemd[1]: systemd-journald.service watchdog timeout (limit 1min)!
Sep 29 12:25:43 Monaco systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
Sep 29 12:25:56 Monaco systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
Sep 29 12:25:57 Monaco systemd[1]: Looping too fast. Throttling execution a little.
I'm also unsure why 12:16:41 timestamp appears *after* 12:25:56!
What I want to know is what might be causing the freezes or how I can figure out what's causing the freezes, and hopefully how to fix it!
Thanks!
edit: I'm aware of the "Out of memory" error related to firefox/aurora, but the freeze happens even without firefox/aurora running!
Last edited by fengshaun (2014-10-09 04:56:51)

Thanks! I had already tried the wiki article about disabling crash dumps and it didn't help! Also, I don't have access to previous logs anymore since "buhman" on [email protected] suggested I remove /var/log/journal directory which solved the problem for now (I waited for a few days before reporting to make sure I don't get freezes).
Also, he had this to say: "feel free to mention that even crap like buhDB is a better implementation of a binary log database"
I'll see when the freezes happen again (or if they do at all) and report back if it happens again.
Thanks!
Last edited by fengshaun (2014-10-12 04:01:42)

TNS-12535 Operation timed out

Hi
I am working on IBM AIX, Oracle 10.2.0.4 version.
Here I got the TNS-12535 error while running a report at particular time. (i.e 8:30 PM to 10:00 PM PST). But aftter this particular time it runs good.
There is no errors found in alert log file. The below is the error found in the sqlnet.log file.
Please help me to resolve this...
Time: 18-FEB-2011 17:05:53
Tracing not turned on.
Tns error struct:
ns main err code: 12535
TNS-12535: TNS:operation timed out
ns secondary err code: 12560
nt main err code: 505
TNS-00505: Operation timed out
nt secondary err code: 78
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))
nt OS err code: 0
Thanks

Hi,
Nothing to investigate at the application side, there is everything to investigate at the network side.
Check the below points.
- is there any firewall in play
- is there any Network Address Translation into play
- have the correct ports been opened in the firewall
- is Oracle using random return ports (by default Oracle always uses 2 tcp/ip ports, the first one fixed, and configured in tnsnames.ora, the actual communication takes place on a radom port. If that is a problem at your site you need to fix that)
- You need to run netstat -r to identify which ports are actually used.
- Pavan kumar N

Random backoff timing.

Similar Messages

Maybe you are looking for