system completly freezes when using awesome wm and disallows even opening the virtual terminals.

[yilkalargaw]

Output of awesome --version: Output of awesome --version

awesome v4.2 (Human after all)
 • Compiled against Lua 5.3.5 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

I do not know what causes the problem because it is so random. When using awesome-wm after several hours or so the system randomly freezes and disallows any keyboard or mouse interaction; It even opening the virtual terminals using Ctrl + Alt + F1-6 . I think it might be something similar to the issue #1060 but I am unable to fix it. My computer is a lenovo thinkpad E550 with Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz cpu. No dedicated graphics card or nothing. I use Fedora and the problem persists both on fedora 27 and 28.

[Elv13]

Can you switch tags? Does your config have widgets that use io.popen/os.system()? I didn't upload your repository .gitmodules so i can't tell. Also watch for the number of open file descriptor from ctrl+alt+f1. Otherwise what's that application having the focus? It might abuse its privilege and eat all inputs.

[psychon]

even opening the virtual terminals using Ctrl + Alt + F1-6

Awesome is not involved in that and cannot prevent it. This happens only between your kernel and Xorg.

My suggestion would be: Do you have another computer and can ssh into your main computer? If so, you could check if the ssh session still works when the graphical interface freezes. Also, via this, you could access some log files or try running chvt to switch to another virtual terminal.

Speaking of log files: Anything in the kernel's or Xorg's logs after this happens? (I guess you need to hard reset your computer, so for Xorg this would be Xorg.0.log.old)

[yilkalargaw]

@Elv13. Yes. I use the runonce.lua file to disallow the repeated opening and closing of startup files the code in it is

local awful = require('awful')
--awful.util = require('awful.util')
awful.spawn = require('awful.spawn')
local gears = require('gears')

local M = {}

-- get the current Pid of awesome
local function getCurrentPid()
    -- get awesome pid from pgrep
    local fpid = io.popen("pgrep -u " .. os.getenv("USER") .. " -o awesome")
    local pid = fpid:read("*n")
    fpid:close()

    -- sanity check
    if pid == nil then
        return -1
    end

    return pid
end

local function getOldPid(filename)
    -- open file
    local pidFile = io.open(filename)
    if pidFile == nil then
        return -1
    end

    -- read number
    local pid = pidFile:read("*n")
    pidFile:close()

    -- sanity check
    if pid <= 0 then
        return -1
    end

    return pid;
end

local function writePid(filename, pid)
    local pidFile = io.open(filename, "w+")
    pidFile:write(pid)
    pidFile:close()
end

local function shallExecute(oldPid, newPid)
    -- simple check if equivalent
    if oldPid == newPid then
        return false
    end

    return true
end

local function getPidFile()
    local host = io.lines("/proc/sys/kernel/hostname")()
    return gears.filesystem.get_dir("cache") .. "/awesome." .. host .. ".pid"
end

-- run Once per real awesome start (config reload works)
-- does not cover "pkill awesome && awesome"
function M.run(shellCommand)
    -- check and Execute
    if shallExecute(M.oldPid, M.currentPid) then
        awful.spawn.with_shell(shellCommand)
    end
end

M.pidFile = getPidFile()
M.oldPid = getOldPid(M.pidFile)
M.currentPid = getCurrentPid()
writePid(M.pidFile, M.currentPid)

return M

[yilkalargaw]

@psychon. Yep that is what I guessed but the problem only happens when I use awesome. As for ssh I am unable to access the device from the network.

[Elv13]

So it's a full kernel panic?

Can you try using Awesome with --no-argb? If that helps, then report bug to your favorite graphic driver developer.

[mainrs]

@Elv13 I added the --no-argb flag and it stopped crashing.

I use the kernel driver for my integrated intel graphics.

It's odd since this only happens when running awesome.

[Elv13]

It's odd since this only happens when running awesome.

It's not odd. Awesome is the only WM without a built-in compositor to use ARGB surfaces by default. It stresses some driver codepaths that are rarely tested.

[mainrs]

@Elv13 Is there something I can do about the argb feature? I am just using the kernel driver and it keeps crashing on me. Maybe filing a bug somewhere? :smile:

[kindlehl]

This is happening to me on Fedora 34, if I try to load an invalid config

[Elv13]

if I try to load an invalid config

Invalid or just a config containing a deadlock? Because that's not really the same type of issue.

[actionless]

Awesome is the only WM without a built-in compositor to use ARGB surfaces by default

should we consider also swapping default value to be in line? ie --no-argb behavior by default, and explicit --argb flag to enable it back

[actionless]

there is also a new way to do it just from the rc.lua config file, without modifying desktop session:

https://awesomewm.org/apidoc/documentation/09-options.md.html#modelines