Hello:

zapper wrote:

... kidding obviously.

Of course.  8^D

A.

Sarcasm is entirely too much fun for me sometimes I admit.

You're welcome.

To say the least.

I meant solved for the OP who (because of Distrowatch) thought Unstable and Testing used systemd.
That was cleared up and ceased to be an issue for him.

On the other hand, what was not cleared up and you seem to have cracked, is the why Distrowatch has the wrong data or at the very least, misinterprets the available data, something which was beyond my intent.

And therein lies the lack of basic common sense / bad attitude from the chap at Distrowatch.

Devuan (let's accept that it was Devuan, just for argument's sake) is explaining that Unstable and Testing do not have/use systemd, that all those files are shims to be able to use some packages from the Debian repositories.

But no, they dig in deeper, wriggling their way out the argument and insisting.

Wouldn't it have been much more reasonable for them to have sent an email to the address I provided and simply ask?
Our dedicated Devuan devs would have asked about the source of their data and promptly cleared up the problem for them.

But no, no - can - do - that.

Not a problem, to me Distrowatch was never a place to go for distribution information.
It is just a long list of names.

Thank you for your input.

Best,

A.

Not on any Devuan team, not a dev/maintainer/packager either.
Nevertheless, I sent the people at Distrowatch an email.

Thanks for taking the time with all that - a disappointing attitude from DistroWatch. :(

I think it was noted in a thread about a German news/blog article - actually, it looks like it occurred in that thread golinux linked.

-

I don't, because it isn't (yet).

Despite their poor attitude, I doubt the DistroWatch team would deliberately do something different for testing/unstable, yet there is clearly a difference which causes systemd version numbers to appear in those columns and not for the released versions.

So they are getting 254.5 from somewhere, and checking the search results, there is one package in ceres/excalibur that is not in daedalus or earlier:
https://pkginfo.devuan.org/cgi-bin/pack … ev=254.5-1
https://packages.debian.org/sid/systemd-dev

I suspect if systemd-dev gets added to Amprolla's banned package list, the next DistoWatch update would return to showing hyphens for all columns.

Is it possible for Amprolla to automatically blacklist anything matching ^systemd- and/or with Source: systemd, and require a manual override for the rare situations in which such a package is necessary?

(I'm not entirely convinced there is actually any such situation; seems to me libsystemd0 could be replaced with a dummy/stub from a Devuan-controlled package, but that's probably a separate topic.)

Of course.  8^D

A.

Best,

A."

Aww that's no fun, we should keep this thread perpetually going till it goes off the rails and turns into a nonsense thread about nothing.

I am only kidding obviously.

xD

Yes, not exactly but closely related to systemd.

Xorg uses elogind to keep it from running as root.
Something which has always (rightly so) been a source of stern criticism.

See this post at the Artix forum for a quick explanation.

I think this thread can be marked as solved.

Best,

A.

The only reference to cgroups I have in /run/systemd is cgroups-agent, a Unix socket.

Location: /run/systemd
File type: socket
Total size of files: 0 bytes
Size on disk: 0 bytes

And then there's /lib/elogind/elogind-cgroups-agent which is a shared library.
I don't use Network Manager, my system uses Wicd.

From what I understand from the netstat-an printout, cgroups-agent is an active UNIX domain type socket with two attached processes, no 'Flags' data,  used in DGRAM (connectionless) state.
ie: not waiting for a connect request, connected or listening

Proto    unix
RefCnt   2     <-- attached processes
Flags    [  ]  <-- no flags - not waiting for a connect request   
Type     DGRAM <-- connectionless
State          <-- empty - not connected to another socket
I-Node   15845
Path     /run/systemd/cgroups-agent

My guess is that it is needed for some systemd-less reason (elogind?), otherwise it would not be there, but that's all I can say.
It is all rather over my head.

That said,a couple of questions pop-up:

- what does/would it take for the cgroups-agent socket lose its connectionless mode/state?
- what can be done to avoid that from ever happening? ie: some way to block/blacklist it

Thanks in advance.

Best,

A.

/run/systemd/inhibit/1
# This is private data. Do not parse.
WHAT=sleep
MODE=delay
UID=0
PID=1217
WHO=NetworkManager
WHY=NetworkManager needs to turn off networks
FIFO=/run/systemd/inhibit/1.ref

This is probably how it should be.
This is Daedalus, which, according to distrowatch.com, does not have  systemd.

I run Devuan Beowulf on a backported kernel ...

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ 

... and I get this:

~$ netstat -an | grep systemd
unix  2      [ ]         DGRAM                    15854    /run/systemd/cgroups-agent
~$ 

I recall having seen it once or twice before but did not pay attention to it.

Q1: why do I have this?  What starts it?
Q2: is it doing anyhting? It does not seem to be listening or connected
Q3: how do I get rid of it? (kernel variable?)

Thanks in advance.

Best.

A.

There must be something wrong with whatever generates that list. There's no systemd package in devuan.

root@ceres:/# apt policy systemd
systemd:
  Installed: (none)
  Candidate: (none)
  Version table:

Same as the rest of the banned packages.
https://pkgmaster.devuan.org/bannedpackages.txt

Depending what iso you start from some of the live iso's boot with an orphan systemd/ cgroup/agent.
output of

netstat -an

you can set a kernel variable to ignore / orphaned process.

Thanks.

Best,

A.

Against my better judgement (if I've ever had such a thing) with today being both Friday 13th. and a local bank holiday, I decided to insist with Distrowatch.
I'm posting it here so you can ...

No idea, just for the chuckles.
Make what you will of it.

My email:

--- snip ---

... not *one* of those files contain an init system.

They are standalone files to either handle systemd unit files in
non-systemd distributions or be used at compile time by other
packages.

This enables Debian packages which have 'Build-Depends: systemd' to
be built on Devuan systems ensuring a non-systemd systemctl emulation
is installed.

They are *shims* (if you will) that allow most Debian packages (for
the time being) to run without issues in Devuan.

--- snip ---

---

Their reply:

---

--- snip ---

Nobody said they do. As you can clearly see on our Devuan page, we list
the three init Software packages Devuan supports (runit, OpenRC, and
SysV), we do not list systemd.

--- snip ---

You seem to be the only one confused by this. systemd packages are
available in Devuan, it offers systemd libraries and packages. We
therefore list systemd as being in the repositories, because it's there.
Nowhere do we claim Devuan uses systemd init.

---

As anyone can see, systemd (254.5) is listed as an available package in both Unstable and Testing in their Devuan page.

So much for that then.
No sense flogging a dead horse, is there?

A.

# apt install systemd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package systemd is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  systemd-standalone-tmpfiles systemd-standalone-sysusers systemd-oomd systemd-boot-efi systemd-boot
  ifupdown

E: Package 'systemd' has no installation candidate

None of the available packages listed contains an init system.
Their descriptions are below. Note the part that says for use in non-systemd systems

Description: standalone tmpfiles binary for use in non-systemd systems
Description: standalone sysusers binary for use in non-systemd systems
Description: userspace out-of-memory (OOM) killer
Description: simple UEFI boot manager - EFI binaries
Description: simple UEFI boot manager - tools and services