Socket disappearing
Closed this issue · 15 comments
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?
Sounds serious. I've never gotten this personally. The only thing I guess I can recommend is enable all logs with RUST_LOG=trace.
Can you assist me further, on how to apply this and then what to expect happening after activating it?
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.
Alright, activated logging now. Will check the logs as soon as this happens again.
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
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" }
Also getting connection refused. I needed to remove the old socket file before starting xidlehook again for xidlehook-client to work
Yeah, can confirm this. Maybe xidlehook should check for existing socket file and either fail to start or clean it up?
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.
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.
Yeah, you're right. I don't see why not
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.
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.
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.
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.