Back in my Arch Linux days, I was able to get lightdm to behave itself by creating /etc/systemd/system/lightdm.service.d/norestart.conf with this in it:

[Service]
Restart=no

What would be the Devuan/SysVinit equivalent?

Yes, you can mark it as solved. The timestamp in /var/spool/anacron/ is proof that the job ran

Now we're just making things more elegant and streamlined.

That's correct. For a simple one-liner task such as this, you don't need a script. I didn't want to point it out before--thinking it might be rewarding for you to get this working "your way"--but you can accomplish what you need by simply having this in /etc/anacrontab:

1 8    automatic.trim   /sbin/fstrim --all

(siva is right: the || true is not only superfluous, it can potentially be misleading. Without || true in there, if the fstrim command fails (not that it ever should) then the overall anacron job fails and if you investigate you'll be able to see that it failed. With || true in there, if the fstrim command fails then the true command runs, completes successfully (the true command always does nothing and completes sucessfully--that is what it does by design, which seems silly but is actually useful in several settings), and the overall anacron job completes successfully because the last command it ran completed successfully.)

Ron, anacron isn't even installed on your system. In my previous post I listed everything you need to do. Sorry but unless you try what I suggested I cannot help you further.

The script will do what you want it to.

I never needed acpi in my Jessie installation, so never installed it. acpi_listen command is not present.

Yep, when I was knee-deep in troubleshooting graphics issues on my T400 (graphics-related issues were by far the most painful part of upgrading from Devuan Jessie to Devuan Ascii for me) I tried uninstalling xserver-xorg-video-intel to see what would happen. Removing it had no effect on my system.

I am on Devuan Ascii and had tried the same kernel (3.16.something) I was using when I was running Devuan Jessie on this machine. Surprisingly, I had no issues on Jessie, but Ascii had occasional graphics-related lockups during boot (see this). Therefore, since identical hardware+kernel gave me no issues on Jessie but graphics-related boot lockups on Ascii, my guess is that from Jessie to Ascii there has been a change in Xorg that is problematic for my hardware (T400 with libreboot and integrated Intel graphics).

I considered lunario's idea of downgrading X to the version in Jessie (see post #9 here), but ultimately decided to keep Ascii's X version and try my luck with different kernels. I don't know if that was wise because I ended up trying 24 different kernels from 3.14.12 to 4.16.5 and not a single one was completely trouble-free for me.

At this point, I've done more troubleshooting than I can stomach. My current setup is quite tolerable: Devuan Ascii with its default Xorg, using linux-libre 4.16.2 (and its i915 module). With this setup, my only remaining issue is a lid-related graphics bug which I can avoid by disabling the lid switch (see this).

Oh, sorry to complicate things but if you installed Devuan Ascii from a live image (e.g., a Miyo live image), you may have been hit with this issue.

To check, run this command: ls -l /usr/sbin/anacron

If /usr/sbin/anacron is a link to /bin/true, then you need to run these commands for anacron to work properly:

sudo apt-get purge live-config live-config-doc live-config-sysvinit
sudo dpkg-divert --remove /usr/sbin/anacron
sudo apt-get install --reinstall anacron

Incidentally, this issue may explain why jobs in /etc/cron.daily aren't working for you. If anacron is present on your system, then cron delegates the jobs in /etc/cron.daily to anacron. However, if you installed from a live image, anacron is disabled until you do the above.

rolfie, my setup is very similar to yours (Devuan ASCII with LightDM and MATE) and I'm not having any permissions issues.

Is there a particular reason you are installing consolekit and friends? Neither MATE nor LightDM require consolekit, so maybe the consolekit packages are installed on your system but not actually being used.

I have no packages installed on my system with "consolekit" anywhere in the name. I have these with "elogind" in the name:

elogind 234.4-1+devuan1.5
libelogind0:amd64 234.4-1+devuan1.5
libpam-elogind:amd64 234.4-1+devuan1.5
libpolkit-backend-1-0-elogind:amd64 0.105-18+devuan2.4
libpolkit-gobject-1-0-elogind:amd64 0.105-18+devuan2.4

If I were you I'd backup my system, uninstall all the consolekit packages, and install the above elogind packages. I bet your permissions issues would go away.

Haha, indeed!

Parenthetically, this whole thread was just a workaround/bandaid for my issue. The real question is "which system component is changing display settings in response to the laptop lid?" Before I close the laptop lid my display settings are fine, but after closing and reopening the laptop lid the display settings are severely messed up (see post #1).

These are all excellent ideas, which makes me all the more flabbergasted that I don't have a hot lead yet:

1. My kernel is linux-libre 4.16.2, which causes me the fewest problems (only the bug described in post #1). The button driver is definitely not a kernel module for this particular kernel, so I guess it must be a built-in driver.

2. Indeed, I found the thinkpad_acpi module loaded. Surprisingly, blacklisting it has no discernible effect.

3. modinfo $(lsmod | sed 's/\s.*//') is a great idea. Alas, I cannot find the string "button" in the output. I did find the panel_ignore_lid parameter for the i915 kernel module and I tried all of the values, no joy.

4. I installed xserver-xorg-input-evdev. Interestingly, there is basically no change in /var/log/Xorg.0.log:

[     7.869] (II) config/udev: Adding input device Lid Switch (/dev/input/event1)
[     7.869] (II) No input driver specified, ignoring this device.
[     7.869] (II) This device may have been added with another device file.

5. I'd like to try disabling the Lid Switch input method in X with a custom config file in /usr/share/X11/xorg.conf.d similar to this (without the MatchIsTouchscreen, of course), but it's looking bleak given that $ xinput --list does not output anything that looks like a lid switch.

It seems that I underestimated the complexity involved in completely disabling the lid switch. One would think it would be simple.

Here is the output of udevadm info -a -n /dev/input/event1:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1/event1':
    KERNEL=="event1"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1':
    KERNELS=="input1"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{uniq}==""
    ATTRS{properties}=="0"
    ATTRS{phys}=="PNP0C0D/button/input0"
    ATTRS{name}=="Lid Switch"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00':
    KERNELS=="PNP0C0D:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="button"
    ATTRS{hid}=="PNP0C0D"
    ATTRS{path}=="\_SB_.PCI0.LPCB.EC__.LID_"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00':
    KERNELS=="PNP0C09:00"
    SUBSYSTEMS=="acpi"
    DRIVERS=="ec"
    ATTRS{uid}=="0"
    ATTRS{hid}=="PNP0C09"
    ATTRS{path}=="\_SB_.PCI0.LPCB.EC__"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a':
    KERNELS=="device:2a"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{adr}=="0x001f0000"
    ATTRS{path}=="\_SB_.PCI0.LPCB"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00':
    KERNELS=="PNP0A08:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{adr}=="0x00000000"
    ATTRS{hid}=="PNP0A08"
    ATTRS{path}=="\_SB_.PCI0"

  looking at parent device '/devices/LNXSYSTM:00/LNXSYBUS:00':
    KERNELS=="LNXSYBUS:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYBUS"
    ATTRS{path}=="\_SB_"

  looking at parent device '/devices/LNXSYSTM:00':
    KERNELS=="LNXSYSTM:00"
    SUBSYSTEMS=="acpi"
    DRIVERS==""
    ATTRS{hid}=="LNXSYSTM"
    ATTRS{path}=="\"

The lid switch has the convenient "Lid Switch" name attribute. Can someone help me write a udev rule that will disable the lid switch?

I know very little about udev rules, but tried creating /etc/udev/rules.d/90-disable-lid-switch with this in it:

ACTION=="add", ATTRS{name}=="Lid Switch", RUN="/bin/sh -c 'echo 0 >/sys/\$devpath/authorized'"

Not surprisingly, my feeble attempt at a udev rule had no effect--lid switch is still functional and able to trigger the video bug.

@ralph.ronnquist. I have very strange results to report:

1. My lid switch is /dev/input/event1, so manually deleted /dev/input/event1. I also deleted /var/log/Xorg.0.log
2. I then kill X (Control + Alt + Backspace) and log back in
3. /var/log/Xorg.0.log shows the same Lid Switch lines (it is added as /dev/input/event1) even though /dev/input/event1 does not exist
4. Closing and opening the lid triggers the crazy graphics bug

@mlsmith:

bruno@thinkpad:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
HDEF	  S4	*disabled  pci:0000:00:1b.0
USB1	  S4	*enabled   pci:0000:00:1d.0
USB2	  S4	*enabled   pci:0000:00:1d.1
USB3	  S4	*enabled   pci:0000:00:1d.2
EHC1	  S4	*enabled   pci:0000:00:1d.7
USB4	  S4	*enabled   pci:0000:00:1a.0
USB5	  S4	*enabled   pci:0000:00:1a.1
USB6	  S4	*enabled   pci:0000:00:1a.2
EHC2	  S4	*enabled   pci:0000:00:1a.7
SLT1	  S4	*disabled  pci:0000:05:00.0
SLT2	  S4	*disabled
SLT3	  S4	*disabled
SLT6	  S4	*disabled
LANC	  S3	*disabled
LANR	  S3	*disabled
SLPB	  S3	*enabled   platform:PNP0C0E:00
LID	  S3	*enabled   platform:PNP0C0D:00