Bob
]]>HTH
KatolaZ
]]>dxrobertson@acer:/run$ ls -l
total 32
-rw------- 1 root root 0 Feb 13 15:15 agetty.reload
drwxr-xr-x 2 root root 80 Feb 13 15:15 console-setup
-rw-r--r-- 1 root root 5 Feb 13 15:15 crond.pid
---------- 1 root root 0 Feb 13 15:15 crond.reboot
drwxr-xr-x 2 messagebus messagebus 80 Feb 13 15:15 dbus
-rw-r--r-- 1 root root 5 Feb 13 15:16 dhclient.pid
-rw-r--r-- 1 root root 5 Feb 13 15:15 elogind.pid
prw------- 1 root root 0 Feb 13 15:15 initctl
drwxr-xr-x 2 root root 80 Feb 13 15:15 initramfs
drwx--x--x 3 root root 60 Feb 13 15:15 lightdm
-rw-r--r-- 1 root root 5 Feb 13 15:15 lightdm.pid
drwxrwxrwt 2 root root 60 Feb 13 15:15 lock
drwxr-xr-x 2 root root 80 Feb 13 16:30 mount
drwxr-xr-x 2 root root 100 Feb 13 15:15 network
drwxr-xr-x 8 root root 180 Feb 13 15:15 nosystemd
drwxrwxr-x 14 root root 320 Feb 13 15:15 openrc
drwxr-xr-x 4 root root 80 Feb 13 15:15 pm-utils
-rw-r--r-- 1 root root 4 Feb 13 15:15 rsyslogd.pid
-rw-r--r-- 1 root root 1 Feb 13 15:15 runlevel
drwxr-xr-x 2 root root 60 Feb 13 15:15 sendsigs.omit.d
lrwxrwxrwx 1 root root 8 Feb 13 15:15 shm -> /dev/shm
drwx--x--x 3 root root 60 Feb 13 15:15 sudo
lrwxrwxrwx 1 root root 14 Feb 13 16:27 systemd -> /run/nosystemd
drwxr-xr-x 8 root root 220 Feb 13 16:29 udev
drwx------ 2 root root 40 Feb 13 15:15 udisks2
drwxr-xr-x 3 root root 60 Feb 13 15:15 user
-rw-rw-r-- 1 root utmp 4224 Feb 13 15:15 utmp
test it:
dxrobertson@acer:~$ cat /run/systemd/users/1000
# This is private data. Do not parse.
NAME=dxrobertson
STATE=active
STOPPING=no
RUNTIME=/run/user/1000
DISPLAY=1
REALTIME=1550088940339646
MONOTONIC=25991508
SESSIONS=1
SEATS=seat0
ACTIVE_SESSIONS=1
ONLINE_SESSIONS=1
ACTIVE_SEATS=seat0
ONLINE_SEATS=seat0
I personally am not bothered by this use of /run/systemd. Its just a directory name. If it makes Devuan easier to maintain and less likely to cause potential problems, then thats fine.
]]>root@thinkpad:/run# tree -alp systemd
systemd
├── [srwx------] cgroups-agent
├── [d---------] inaccessible
│ ├── [b---------] blk
│ ├── [c---------] chr
│ ├── [d---------] dir
│ ├── [p---------] fifo
│ ├── [----------] reg
│ └── [s---------] sock
├── [drwxr-xr-x] inhibit
│ ├── [-rw-r--r--] 1
│ └── [prw-------] 1.ref
├── [drwxr-xr-x] machines
├── [drwxr-xr-x] seats
│ └── [-rw-r--r--] seat0
├── [drwxr-xr-x] sessions
│ ├── [-rw-r--r--] 1
│ └── [prw-------] 1.ref
└── [drwxr-xr-x] users
└── [-rw-r--r--] 1000
7 directories, 12 files
root@thinkpad:/run#
# sources.list
# note .. was pkgmster on install
# deb cdrom:[devuan_ascii_2.0.0_amd64_dvd-1]/ ascii main non-free
#deb cdrom:[devuan_ascii_2.0.0_amd64_dvd-1]/ ascii main non-free
deb http://deb.devuan.org/merged ascii main non-free contrib
deb-src http://deb.devuan.org/merged ascii main non-free contrib
deb http://deb.devuan.org/merged ascii-security main non-free contrib
deb-src http://deb.devuan.org/merged ascii-security main non-free contrib
deb http://deb.devuan.org/merged ascii-updates main non-free contrib
deb-src http://deb.devuan.org/merged ascii-updates main non-free contrib
#pinning
/preferences.d/avoid-systemd
Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
Maybe the last unavoidable systemd packages can be renamed to fake-$originalname_*.deb to make clear that they are harmless? Via provides $originalname dependices could be satisfied.
Would that possibly reduce the iterating questions about systemd pieces still present in Devuan?
Sadly, there are just not enough hands on deck to do the repackaging and long term maintainence. Any volunteers out there?
(golinux hears the sound of silence)
]]>Would that possibly reduce the iterating questions about systemd pieces still present in Devuan?
]]>This is probably one of the (quote from KatolaZ from https://dev1galaxy.org/viewtopic.php?id=1925) :
...only because they happen to provide a systemd unit file for
those systems where systemd is used.
root@acer:~# cd /run
root@acer:/run# find systemd
systemd
systemd/inhibit
systemd/inhibit/1
systemd/inhibit/1.ref
systemd/cgroups-agent
systemd/inaccessible
systemd/inaccessible/blk
systemd/inaccessible/chr
systemd/inaccessible/sock
systemd/inaccessible/fifo
systemd/inaccessible/dir
systemd/inaccessible/reg
systemd/machines
systemd/sessions
systemd/sessions/1
systemd/sessions/1.ref
systemd/users
systemd/users/1000
systemd/seats
systemd/seats/seat0
root@acer:/run#
I then removed /run/systemd.
Then went to a console via <CTRL><ALT>F2, and was surprised to find a series of messages displayed, and continuing to display:
[2299.263755 ] elogind-daemond[2150] failed to save user data /run/systemd/users/1000: no such file or directory
There are also similar messages for session, instead of user.
PID 2150 is elogind-daemon.
elogind version:
root@acer:~# apt list --installed elogind
Listing... Done
elogind/testing,now 239.3+20190131-1 amd64 [installed]
Another reference to run/systemd, unrelated, and since its a "not"; probably actually needed. From syslog:
Feb 11 16:30:01 acer CRON[3837]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Yes, I did first thing. That is why I deleted the (other) systemd folders and files; they should not have mattered to the os. However when the systemd folder in /run got recreated on reboot, I got kind of concerned. Moreso, when I could not chattr +i that empty folder to immutable. I know I can just reinstall and pay more attention, but there is little learning in that.
Thanks for all your trouble for me.
Best regards,
Bob
Hi Bob,
can you plase report the list of files you see under /run/systemd/ after boot? Could you please confirm that you are not using any non-Devuan repo?
Thanks
KatolaZ
]]>Yes, I did first thing. That is why I deleted the (other) systemd folders and files; they should not have mattered to the os. However when the systemd folder in /run got recreated on reboot, I got kind of concerned. Moreso, when I could not chattr +i that empty folder to immutable. I know I can just reinstall and pay more attention, but there is little learning in that.
I wish we had a workshop of magic elves to remove those unnecessary systemd files but alas . . .
Thanks for all your trouble for me.
Best regards,
Bob
No problem. No trouble. Really nice to see you back!
]]>Thanks for all your trouble for me.
Best regards,
Bob
Regards,
Bob