Adrian wrote: Thu Sep 23, 2021 8:19 am
computerworm01001 wrote: Thu Sep 23, 2021 5:32 am
Hello all,I send all my love to dolphin_oracle, Adrian, SwampRabbit, and all the rest of the MX developers.
A good bug report is showing love :)
Hello, Adrian. I'm glad you see it that way, and thank you for reading and responding to my findings.
Adrian wrote: Thu Sep 23, 2021 9:13 am
computerworm01001 wrote: Thu Sep 23, 2021 5:32 am
7. When using autologin, it logs in once, then after a few seconds logs out and logs in again. I found another post on this thread where an MX dev explained that X restarts because of a special MX fix for making the SDDM power buttons work in SysVinit, and that most people should barely see a flash. And when I login manually, I don't notice X restarting at all. I only see it when I use autologin.
I tried that multiple times, I can't replicate the issue. I think we removed the SDDM fix so that should not play a role. Do you have Beta2 or updated Beta1 to Beta2?
I installed directly from the beta2 iso, no upgrade.
Adrian wrote: Thu Sep 23, 2021 8:19 am
computerworm01001 wrote: Thu Sep 23, 2021 5:32 am8. Autologin doesn't work when laptop is not plugged in - computer goes to sleep before having a chance to login
That's another thing I don't see. Also seems like a bug in itself if the computer goes to sleep before the log in. Do you have a timezone issue on that computer? Is it set up on the wrong timezone or localtime?
I have my home time zone set in MX Date & Time, and my hardware clock is set in UTC mode. But I don't think it's a time issue, because when I say autologin isn't working, I'm referring to SDDM autologin, where SDDM logs you in on boot without you having to enter your password. I'm not referring to timed booting with rtcwake, although I do use that concurrently with SDDM autologin to record TV shows while I'm asleep. But rtcwake is working perfectly regardless of my laptop being attached to/detached from wall power, because every night I put my computer in S5, and when I wake up I find it in S3. So rtcwake did its job. It's SDDM that's dropping the ball. Or perhaps some kernel or other low-level power management that's goofing. Because as soon as I wake the computer from sleep by moving the mouse or the lid, SDDM immediately does autologin. And I have my Plasma power settings properly configured to make the machine stay awake, ignore lid closed, etc. So once I'm logged into Plasma, those settings should take over. The problem is making sure my computer gets all the way there without my intervention. For now, my solution is to keep the computer plugged in always. But I don't want to always do that because it wastes electricity to have it plugged in drawing power when I'm asleep.
Adrian wrote: Thu Sep 23, 2021 9:20 am
computerworm01001 wrote: Thu Sep 23, 2021 5:32 am
10. This is not specifically a KDE bug, but it is an MX beta2 bug; I tried the new Job Scheduler app, and I got these strange errors when I attempted to save my crontab edits, and for the record, I double checked my crontab syntax, and there was nothing wrong with it, so I don't know why the errors are raised:
Might be a Job Scheduler issue, but I could not replicate this either, I successfully created a user task. Do you have errors only when you do root tasks? Also what's the string exactly?
I think I figured this out, and I don't think it's a bug after all. You see, when I wanted to use job scheduler to edit the root crontab, I had to use "mx-pkexec job-scheduler" in the terminal because there's no app menu entry for launching Job Scheduler as root. So I had a terminal open on the other side of my screen outputting messages from Job Scheduler in real time. I did it again today, observing more closely, and the message
Code: Select all
CronTime::CronTime Invalid Week Format: ""
outputs whenever I leave a field empty in the Time box, so that's just a normal behavior. Likewise , the message
Code: Select all
CronTime::CronTime Invalid Item count: #
(# is a placeholder for any number) merely denotes how many fields are currently empty in the Time box. And I think that
Code: Select all
CronTime::CronTime Invalid Minute Format: "*/"
just means that I haven't added a number after the slash yet. So I think that there is nothing wrong with the Job Scheduler
Adrian wrote: Thu Sep 23, 2021 9:23 am
11. This may or may not tie in with the previous error, but the root crontab doesn't work. I know my syntax is correct because I entered the same commands in my personal user crontab (appending doas to the beginning, of course) and it works perfectly. So there's something wrong with the root crontab, and I don't know what it is.
Just tried, switched to root in Job Scheduler added the command to execute every other minute (a test command) saved, and the command executed without issue, again, what is the command?
However, the root crontab is definitely malfunctioning, and it doesn't matter what commands I enter. Ones I've tried include rtcwake, pm-suspend, fstrim, and they don't function under root crontab. They function perfectly under my user crontab (with doas tacked on front). Something else changed about it today that I find odd. Just yesterday when I was editing the root crontab in the terminal, the crontab file looked like this:
Code: Select all
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
Today when I opened it, it looked like this:
Code: Select all
# Home
HOME=/root
# Path
PATH=/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/bin
# Shell
SHELL=/bin/bash
What is that and how did it happen? I'm truly at a loss for what to do now, except to go to doas.conf and just set passwordless for my user any root commands I want to automate and enter them in my user crontab with doas at the beginning of each line. But it would probably be better and more secure to just be able to use the root crontab for root stuff. Or should I maybe just reinstall the cron daemon and use the --purge option?
Again, I thank you very kindly for your helping me, and for the good work you and your colleagues do with MX Linux!
Good night all