Is some part of systemd running in ascii 2 ?

robert-e · 2019-02-13 03:18:34

Yesterday I was poking around looking at config files, to see why wicd was randomly disconnecting from the router. I notice a number of systemd folders/files that I thought should not exist. This is ascii 2, new install shortly after it was released. I made 3 new ext3 partitions and formatted them. /boot, / and swap. I kept the /home partition unformated. I renamed the .config files so as not to screw up with newer packages.
I choose slim and mate desktop and installed. I also pinned systemd in /etc/apt/preferences.d. I use synaptic for updates, seldom apt-get, and occasionally gdebi. Today I have renamed all the found systemd files/folders and all seemed okay. I rebooted and all stayed renamed except for the systemd folder in /run. I deleted it, rebooted and it was recreated. I deleted it again, created a new empty systemd folder and attempted to make it immutable. The os would not allow that. I was under the impression that only libsystemd0 should be in existance. It seems that some aspect of systemd is running on bootup. Before I trash this install, could someone enlighten me to what is going on? As the pretend preacher in "Cat Ballou" says; "All contributions are greatfully received".

Regards,
Bob

golinux · 2019-02-13 04:01:39

Happy to see you made it here! You might want to take a look at this post.

robert-e · 2019-02-13 05:19:50

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

golinux · 2019-02-13 05:24:25

robert-e wrote:

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!

KatolaZ · 2019-02-13 05:42:10

robert-e wrote:

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

dxrobertson · 2019-02-13 11:54:41

I also have systemd files in /run. I believe elogind may have something to do with it. I am running all Beowulf, with LXQt 0.14 from unstable.

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)

Last edited by dxrobertson (2019-02-13 12:08:21)

dxrobertson · 2019-02-13 16:00:06

I looked at elogind code, it seems the /run/systemd and subsequent directories are pretty ingrained in the code.

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.

yeti · 2019-02-13 17:46:52

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?

golinux · 2019-02-13 18:00:20

yeti wrote:

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)

robert-e · 2019-02-13 18:23:37

KatolaZ: here you go .. Note that I am not concerned about the stray (unused) systemd files; only that systemd code should not be running, expecially on boot.

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

dxrobertson · 2019-02-13 21:51:04

I dont know if this is a viable "fix" to propose, but /run/systemd could be changed to a symlink that points to /run/nosystemd (or whatever). A process would have to be written (along with other required processing to make it work) to do this during init process. As something fun to try I just manually made this change and everything seems to be working ok.

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.

KatolaZ · 2019-02-13 22:05:30

It's most probably elogind-related, and it's stuff needed for session management. If you ```apt-get remove --purge elogind```, the folder will disappear (but you will not be able to automount any USB drive as a user, reboot/suspend as a user, and similar stuff). elogind is an alternative to systemd-logind which replaces systemd code (and removes most of the unnecessary stuff).

HTH

KatolaZ

robert-e · 2019-02-13 23:29:29

Ok, it is not a problem. I will pruge elogind and use pmount. I have used it before and it works. Afraid of systemd? Not by a long shot, although I so like to learn. Thanks for your time.

Bob

The officially official Devuan Forum!

#1 2019-02-13 03:18:34

Is some part of systemd running in ascii 2 ?

#2 2019-02-13 04:01:39

Re: Is some part of systemd running in ascii 2 ?

#3 2019-02-13 05:19:50

Re: Is some part of systemd running in ascii 2 ?

#4 2019-02-13 05:24:25

Re: Is some part of systemd running in ascii 2 ?

#5 2019-02-13 05:42:10

Re: Is some part of systemd running in ascii 2 ?

#6 2019-02-13 11:54:41

Re: Is some part of systemd running in ascii 2 ?

#7 2019-02-13 16:00:06

Re: Is some part of systemd running in ascii 2 ?

#8 2019-02-13 17:46:52

Re: Is some part of systemd running in ascii 2 ?

#9 2019-02-13 18:00:20

Re: Is some part of systemd running in ascii 2 ?

#10 2019-02-13 18:23:37

Re: Is some part of systemd running in ascii 2 ?

#11 2019-02-13 21:51:04

Re: Is some part of systemd running in ascii 2 ?

#12 2019-02-13 22:05:30

Re: Is some part of systemd running in ascii 2 ?

#13 2019-02-13 23:29:29

Re: Is some part of systemd running in ascii 2 ?

Board footer