Message boards : Questions and problems : BOINC 7.8.3 not resuming under Kubuntu 17.10
Message board moderation
Author | Message |
---|---|
Send message Joined: 3 Nov 17 Posts: 4 ![]() |
Hi Thought I'd share a problem I've encountered with BOINC under Kubuntu 17.10 so that others can find answers. I recently upgraded from Kubuntu 17.04 to 17.10 and noted that BOINC would not seem to resume form idle. Memory fails me but I suspect a similar situation under 17.04 but I wasn't taking much notice. I also upgrade to a Nivida GTX 1060 graphics card (keeping the old GTX 730 also). The GPU processing across both boards seems to work well but the resume from idle not. Linux 4.13.0-16-generic #19-Ubuntu SMP Wed Oct 11 18:35:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux DISTRIB_ID=Ubuntu DISTRIB_RELEASE=17.10 DISTRIB_CODENAME=artful DISTRIB_DESCRIPTION="Ubuntu 17.10" boinccmd --version boinccmd, built from BOINC 7.8.3 Preferences as follows. Resume should be after 1 minute. <global_preferences> <run_on_batteries>1</run_on_batteries> <run_if_user_active>0</run_if_user_active> <run_gpu_if_user_active>0</run_gpu_if_user_active> <idle_time_to_run>1.000000</idle_time_to_run> <suspend_cpu_usage>30.000000</suspend_cpu_usage> <start_hour>0.000000</start_hour> <end_hour>0.000000</end_hour> <net_start_hour>0.000000</net_start_hour> <net_end_hour>0.000000</net_end_hour> <leave_apps_in_memory>1</leave_apps_in_memory> <confirm_before_connecting>0</confirm_before_connecting> <hangup_if_dialed>0</hangup_if_dialed> <dont_verify_images>0</dont_verify_images> <work_buf_min_days>0.200000</work_buf_min_days> <work_buf_additional_days>0.500000</work_buf_additional_days> <max_ncpus_pct>75.000000</max_ncpus_pct> <cpu_scheduling_period_minutes>120.000000</cpu_scheduling_period_minutes> <disk_interval>60.000000</disk_interval> <disk_max_used_gb>0.000000</disk_max_used_gb> <disk_max_used_pct>90.000000</disk_max_used_pct> <disk_min_free_gb>1.000000</disk_min_free_gb> <vm_max_used_pct>75.000000</vm_max_used_pct> <ram_max_used_busy_pct>50.000000</ram_max_used_busy_pct> <ram_max_used_idle_pct>90.000000</ram_max_used_idle_pct> <max_bytes_sec_up>0.000000</max_bytes_sec_up> <max_bytes_sec_down>0.000000</max_bytes_sec_down> <cpu_usage_limit>75.000000</cpu_usage_limit> <daily_xfer_limit_mb>0.000000</daily_xfer_limit_mb> <daily_xfer_period_days>0</daily_xfer_period_days> </global_preferences> Downloading the master branch I compiled 7.9 and uncommented some of the debug lines. Output as follows: tty: /dev/pts/2 1509684457 1509686099 tty: /dev/pts/1 1509686080 1509686099 tty: /dev/pts/3 1509684128 1509686099 tty: /dev/pts/0 1509669223 1509686099 tty: /dev/pts/ptmx 1509715852 1509686099 not idle 29753 Would appear I have a ptmx sessions (what ever that is - researching) that is inhibiting the idle resume. I'll share once I track down what this is and why. ASIDE: I did get resume to idle to work twice but could never nail down why, seemed random. SUGGESTION: Would be good if the "idle_detection_debug" output which tty is potentially blocking resume. I resorted to the code as debug was outputting nothing.[/code] |
Send message Joined: 3 Nov 17 Posts: 4 ![]() |
stat /dev/pts/ptmx File: /dev/pts/ptmx Size: 0 Blocks: 0 IO Block: 1024 character special file Device: 15h/21d Inode: 2 Links: 1 Device type: 5,2 Access: (0000/c---------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2017-11-04 02:30:52.508000039 +1300 Modify: 2017-11-04 02:30:52.508000039 +1300 Change: 2017-11-04 02:30:52.508000039 +1300 date Fri Nov 3 18:40:44 NZDT 2017 Appears to be modified with a timestamp in the future, hence the idle will be a long time coming. [/code] |
![]() Send message Joined: 29 Aug 05 Posts: 15632 ![]() |
Forwarded to the Linux Release Manager. |
Send message Joined: 3 Nov 17 Posts: 4 ![]() |
touch /dev/pts/ptmx Reset the timestamp on ptmx and all seems good. Not found a cause for why ptmx was in the future, will monitor.[/code] |
![]() ![]() Send message Joined: 19 May 15 Posts: 123 ![]() |
You forgot to install the delorean module. |
Send message Joined: 3 Nov 17 Posts: 4 ![]() |
You forgot to install the delorean module. oh I wish :) Further investigation has identified that the future timestamp of /dev/pts/ptmx (not to be confused with /dev/ptmx which seems ok and not linked in any way that I can see) is been set on fresh reboots/start up. Finding what creates this device is going to be interesting. |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.