Systemd service not working properly about circadian HOT 19 CLOSED

Thank you so much, I'll install it from the AUR now as I can see that @bbx0 updated it there too.

from circadian.

sleep 10 && sudo circadian -t
w* : 3279 xssstate* : 10 xprintidle* : 10 Wake block : 600 TTY (combined)* : 3279 X11 (combined)* : 10 Idle (min) : 10 Idle target : 600 Until idle : 590 IDLE? : false CPU load* : false SSH* : false SMB : false NFS : false Audio* : false Processes* : false BLOCKED? : false

Looks like xprintidle is actually showing idle times. Could it be that there is something wrong with the systemd service then.

from circadian.

Hmmm, if I run circadian from the terminal and not through the systemd service, everything seems to register and work properly. There's something wrong with the systemd service (perhaps users and permissions?). I will look into it.

from circadian.

I'm afraid this is similar to #12. The idle_fn relies on having the DISPLAY in the third column of w, which is not the case on Arch.

Could you share w -hus and w -husf from your machine?

from circadian.

dxwil tty1 14:54 xinit /home/dxwil/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth -hus
dxwil tty1 - 15:01 xinit /home/dxwil/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth -husf

You're right, it doesn't say anything about the DISPLAY. I installed circadian from the AUR package which seems to be yours.

from circadian.

Thanks! I just released a new PKGBUILD partially restoring the w_arg.patch for idle_fn to mitigate.

Sadly, looking at your w -husf output, this may not fix the problem. If I read the function correctly a value of - would still cause fallthrough to the root user but let's see.

from circadian.

Does it consistently suspend every 10 minutes when running from the systemd service? Or is it a one-off suspend? The fact that it works from the terminal points more to an environment problem than an issue with w, but I'm not certain.

Can you post the systemd logs from one of the unexpected suspends? journalctl -u circadian --since "yesterday" | cat should dump recent ones (adjusting "yesterday" to "2 days ago" or whatever you need).

It would also be helpful if you can collect logs from running this (as root) while continuously using X11:

$ systemctl start circadian && sleep 60 ; pkill -SIGUSR1 circadian ; sleep 60 ; pkill -SIGUSR1 circadian ; systemctl stop circadian
$ journalctl -u circadian --since "10 minutes ago" | cat

Sending the SIGUSR1 signal triggers it to dump its current state to the logs. This does it twice at 1 minute intervals so we can see which idle times are changing.

I suppose you could run the systemd service and a terminal process at the same time, send a few SIGUSR1 signals with pkill, and compare the two. Just be sure not to keep them both running!

from circadian.

The update from the AUR unfortunately did not change anything. It is still constantly sleeping 10 mins after boot, then after I wake it up, it goes to sleep after 10 mins again (and the cycle continues). A log from the unexpected suspend is pasted here - https://pastebin.com/8UDXXtLZ.
The log to see which idle times are changing is here - https://pastebin.com/BTm04NPv. I am starting circadian from my wm autostart file, which is a workaround but obviously not ideal.

from circadian.

Hmm, interesting. Both xssstate and xprintidle are failing when run from the systemd unit.

I had forgotten that circadian uses w to map UIDs to X11 displays, and that also depends on whether the FROM field is enabled. Since the FROM field is missing on Arch, it should default to 'root'. I'm not sure why that isn't just using the UID of X's socket, and I think I'll change it to do that.

I'm still unsure of why it works when you run it from a terminal... but I'll have a patch ready soon that you can try.

from circadian.

er.... right, stat doesn't work. When X11 is launched as root, we need to find the regular users with active sessions... I wonder how w implements this internally?

from circadian.

@dxwil can you can try PR #20? It's quite a similar fix to what @bbx0 tried, though more deterministic... and that means there's a pretty good chance it won't work, unfortunately.

If not, I can put together a debug build that dumps a bunch of info to your syslog. Assuming you have time to help, of course.

from circadian.

Unfortunately, xssstate and xprintidle are still showing those numbers instead of proper information. I would be able to try out a debug build if that isn't too much of a hassle for you.

from circadian.

@dxwil thanks for helping out!

You can do a fresh pull PR #20 now and rebuild/reinstall it. You'll need to modify your /etc/circadian.conf and add the following to the top of the file:

##
## Settings
##
## Options used to configure Circadian itself.
##
[settings]
# How verbose the output should be while running, between 0 and 4
# inclusive.  '0' is for normal usage, '4' is intended for active
# debugging.
#
# Default: 0
verbosity = 4

And when running in a terminal, add -vvvv to get more output. Please post some logs from this version running with verbosity 4, and hopefully we can get some answers.

There are four more changes here:

1. a bunch of debug output
2. try all usernames instead of just the first encountered
3. also try the owner of the X11 socket
4. explicitly specify the user's .Xauthority file, if found

If we're lucky, this will fix it. I'm somewhat hopefully that the problem is an undefined XAUTHORITY environment variable; that would explain why it's working in a terminal, but not from systemd.

from circadian.

I pushed one more commit to that branch that additionally tries to find the xauth file from the X11 process's command line arguments.

I'm suspicious that it might be xauth-related, since the two X11 systems I'm testing on seem to have quite different usage of xauth. root can poll the X servers without an xauth file on one of my machines, but not on the other. Unfortunately, there's absolutely no standard for where the xauth files are stored... could be in /var/run/<something>/:0 or /tmp/xauth-whatever or $HOME/.Xauthority, depending on your setup.

With this change, Circadian will poke around the file system a bit and try to choose a good candidate.

from circadian.

In case this does not work (hopefully it does :)), we can also fallback to systemd itself to invoke the commands in user context with DISPLAY and XAUTHORITY set. On Arch this is supported but this must not be the case for all distributions (requires systemd >=219).

# Get all active users sessions
$ systemctl list-units --state=active --quiet 'user@*.service' | grep --only-matching --perl-regexp '(?<=user@)[[:digit:]]+(?=.service)'
1000

# Run command in user context
$ systemd-run --user --machine [email protected] --wait --collect --pipe --quiet --service-type=exec printenv DISPLAY
:0
$ systemd-run --user --machine [email protected] --wait --collect --pipe --quiet --service-type=exec xssstate -i

This should work as root and from other systemd units.

from circadian.

Yesss !!! It works :), #20 fixed it. I did not do anything apart from installing this commit, nothing in the config, no -vvvv and none of what @bbx0 suggested (because I didn't need to :) ). You were right, it was something to do with the X11 xauth. Thank you for both of your help.

from circadian.

@dxwil Great news! I'll merge that PR and make a fresh release sometime this weekend. Thanks again for helping to test these changes.

@bbx0 That's an interesting idea. I'd like to avoid using systemd for... well, anything... but can certainly come back to this suggestion if people report other cases where the current implementation fails. Just like X11 itself, there are a million ways to configure systemd, and it may or may not be configured to handle X. My main machine runs two X servers, for instance, and systemd isn't aware of either. I guess it would need to be an alternative option instead of a modification to the current one.

from circadian.

Glad it works. Yeah, going with the systemd option could only be a fallback. If it's not needed, the better!

from circadian.

and the release is issued :)

from circadian.