Socket disappearing

[mindrunner]

xidlehook is running

le        169947  0.0  0.0 761660    72 ?        Sl   Dec21   0:02 xidlehook --socket /tmp/xidlehook.socket .......

but socket does not exist

[le@w530]: ~>$ stat /tmp/xidlehook.socket
stat: cannot stat '/tmp/xidlehook.socket': No such file or directory

This is not always the case. It is mainly working fine. Not sure how to reproduce this, though. Is this a bug or am I missing something here?

[jD91mZM2]

Sounds serious. I've never gotten this personally. The only thing I guess I can recommend is enable all logs with RUST_LOG=trace.

[mindrunner]

Can you assist me further, on how to apply this and then what to expect happening after activating it?

[jD91mZM2]

Sorry for that. RUST_LOG is an environment variable which env_logger reads. Assuming you are using the latest xidlehook version, it will print out a bunch of log messages to the console executing xidlehook (systemd logs if you're using systemd), which might be of use in finding why it doesn't work.

[mindrunner]

Alright, activated logging now. Will check the logs as soon as this happens again.

[mindrunner]

Something seems weird.... Now, I lost the process, but the socket is still there (gives connection refused if I try to access it)

[le@w530]: ~>$ cat .xidlehook.err 
[2019-12-23T15:40:37Z INFO  async_std::task::builder] spawn
[2019-12-23T15:40:37Z INFO  async_std::task::block_on] block_on
[2019-12-23T15:40:37Z WARN  xidlehook] Socket handling errored: Address already in use (os error 98)
[2019-12-23T15:40:37Z INFO  async_std::task::builder] completed
[2019-12-23T15:40:37Z TRACE xidlehook_core] Taking the first timer into account. Remaining: 600s
[2019-12-23T15:40:37Z TRACE xidlehook_core] Relative time: 9ms
[2019-12-23T15:40:37Z TRACE xidlehook_core] Taking next timer into account. Remaining: 599.991s
[2019-12-23T15:40:37Z TRACE xidlehook_core] Sleeping for 599.991s
[2019-12-23T15:40:37Z INFO  async_std::task::block_on] completed
[2019-12-23T15:40:37Z INFO  async_std::task::block_on] block_on
[2019-12-23T15:40:37Z TRACE xidlehook_core] Taking the first timer into account. Remaining: 600s
[2019-12-23T15:40:37Z TRACE xidlehook_core] Relative time: 9ms
[2019-12-23T15:40:37Z TRACE xidlehook_core] Taking next timer into account. Remaining: 599.991s
[2019-12-23T15:40:37Z TRACE xidlehook_core] Sleeping for 599.991s
[2019-12-23T15:50:37Z TRACE xidlehook_core] Taking the first timer into account. Remaining: 600s
[2019-12-23T15:50:37Z TRACE xidlehook_core] Relative time: 95ms
[2019-12-23T15:50:37Z TRACE xidlehook_core] Taking next timer into account. Remaining: 599.905s
[2019-12-23T15:50:37Z TRACE xidlehook_core] Sleeping for 599.905s

[mindrunner]

Restarted xidlehook:

# Only exported variables can be used within the timer's command.
export PRIMARY_DISPLAY="$(xrandr | awk '/ primary/{print $1}')"

export RUST_LOG=trace
# Run xidlehook
xidlehook \
  --socket /tmp/xidlehook.socket \
  --not-when-fullscreen \
  --timer 600 \
    'dunstify -a xidlehook locking....' \
    '' \
  `# Undim & lock after 10 more seconds` \
  --timer 10 \
    'xrandr --output "$PRIMARY_DISPLAY" --brightness 1; ~/bin/i3lock-dpms' \
    '' \
  `# Finally, suspend an hour after it locks` \
  --timer 3600 \
    'grep 0 /sys/class/power_supply/AC/online > /dev/null && /home/le/bin/suspend-then-hibernate' \
    '' \
    >> /home/le/.xidlehook.log 2>> /home/le/.xidlehook.err

[le@w530]: ~>$ ls -ahl /tmp/xidlehook.socket 
srwxr-xr-x 1 le users 0 Dec 22 22:20 /tmp/xidlehook.socket

[le@w530]: ~>$ xidlehook-client --socket /tmp/xidlehook.socket control --action trigger --timer 1
Error: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }

[unai-ndz]

Also getting connection refused. I needed to remove the old socket file before starting xidlehook again for xidlehook-client to work

[mindrunner]

Yeah, can confirm this. Maybe xidlehook should check for existing socket file and either fail to start or clean it up?

[jD91mZM2]

Yeah that's a good point. It's supposed to remove the socket when closed, but that sometimes fails (I suppose when closed in an abnormal way) so personally I have a rm /tmp/xidlehook.sock run before startup.

[ncoder-1]

Just got burned by a pre-existing/tmp/xidlehook.sock and saw this issue from 2019 :)

Any chance xidlehook could check if the --socket file exists and rm it when starting, that would be better than having a rm /tmp/xidlehook.sock in config files such as i3's config file.

[jD91mZM2]

Yeah, you're right. I don't see why not

[desbma]

I solved this a while ago with a systemd service unit containing:

[Service]
RuntimeDirectory=xidlehook
ExecStart=/usr/local/bin/xidlehook --socket ${RUNTIME_DIRECTORY}/%N.socket ...

The runtime directory is managed by systemd, so the directory and its socket is removed when xidlehook stops.

[ncoder-1]

The systemd option works, but I'm running multiple DE for dev testing and I'd have to stop that service should I switch to Gnome for example so I'm trying to avoid running a systemd service for xidlehook.

If I use i3, I have it launched as follows in my config file:

exec --no-startup-id rm /tmp/xidlehook.socket
exec --no-startup-id xidlehook --not-when-audio --not-when-fullscreen --socket /tmp/xidlehook.socket --timer 180 '$HOME/bin/lock_screen.sh' ''
bindsym Control+Mod1+l exec xidlehook-client --socket /tmp/xidlehook.socket control --action trigger --timer 0

I'm just trying to get rid of the "rm" bit, without using a systemd service.

[desbma]

The systemd option works, but I'm running multiple DE for dev testing and I'd have to stop that service should I switch to Gnome for example so I'm trying to avoid running a systemd service for xidlehook.

Systemd user services are precisely made to start and stop with your session.

[ncoder-1]

Systemd user services are precisely made to start and stop with your session.

Thanks for the valuable info. I get that if I leave i3, the service will stop. What I'm saying is that I don't need the service starting again if I launch a Gnome session. All idlehook has to do is check if the socket file exists at launch, and if so, remove it.