You are not logged in.
Hello:
... it is needed for some systemd-less reason (elogind?) ...
Yes, not exactly but closely related to systemd.
Elogind is the systemd project's "logind", extracted out to be a standalone daemon. It integrates with PAM to know the set of users that are logged in to a system and whether they are logged in graphically, on the console, or remotely.
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.
... elogind literally just sleeps 99% of the time.
It's a daemon.
Nothing harmful.
I think this thread can be marked as solved.
Best,
A.
Hello:
... appears to be something to do with seatd and or wayland.
I would not be surprised if it was related to wayland.
Why does mouse driven logout take forever.
Why does ctrl_alt_bksp not action immediately.
I don't use (or want/need to use) wayland, my box runs on X.
logout and/or ctrl_alt_bksp are practically instantaneous.
No delays at all.
The only thing that will cause a delay (quite obviously) in my box is a backintime process running.
I'd purge wayland and see what happens.
Best,
A.
Hello:
For example ...
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-agentMy 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.
Hello:
Depending what iso you start from ...
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.
you can set a kernel variable to ignore / orphaned process.
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.
Hello:
Nice work ...
Thanks.
Best,
A.
Hello:
Send them to this page . . .
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.
Hello:
Perhaps someone from the Devuan Team ...
Not on any Devuan team, not a dev/maintainer/packager either.
Nevertheless, I sent the people at Distrowatch an email.
--- snip ---
... Devuan does *not* use systemd as its init software in *any* of its versions/releases.
Devuan is Debian *without* systemd.
You may want to consider fixing that as it can lead to confusion.
Thanks in advance
--- snip ---
Here's their reply:
---
Devuan does not ship systemd as the _default_ init system. It still
includes the package in its repositories, which is what we show in our
package table.
---
Right ...
Then I wrote back with a link to the Devuan Package Information page with a query* for the systemd package and an email** address where they could write and ask for confirmation to what I was saying, I got this (interesting) reply:
---
The systemd packages are not only in the repositories, you can see them
on the Devuan package query page here:
https://pkginfo.devuan.org/cgi-bin/poli … *&x=submit
As you can see, our information is correct and systemd is in the main
Devuan repositories.
---
* https://pkginfo.devuan.org/cgi-bin/poli … d&x=submit
** freedom at devuan.org
I was about to write back with an explanation about the difference between the systemd package and all those files/packages named abc-systemd, systemd-xyz, abc-systemd-xyz (and so on) but decided that it was really not worth the effort.
But that's on me, I've never suffered fools lightly and too old to start now.
That said, I have not seen/found which page of the Repology site says anything about Devuan and systemd so I did not address the matter with them.
Best,
A.
Hello:
Distrowatch is a site that many, including myself, consult ...
There must be something wrong with whatever generates that list.
There's no systemd package in devuan.
I think that settles the matter, right?
A.
Hello:
I see that both Unstable and Testing have OpenRC, runit, SysV under "Feature" -> "Init Software".
systemd is not a listed option.
That said, I also see it is listed as in the "Package" column but systemd is not an available package in the Devuan repositories.
There would seem to be a discrepancy in the Distrowatch page.
Either that or, being Testing/Unstable releases, the package is there as a place holder and not used.
Not a dev/maintainer so I cannot say much more.
Have you tried setting up "Testing" or "Unstable" to check is systemd is effectively used?
Best,
A.
Hello:
... article link and a bit of information...
Yes, sorry about that.
Posted in a hurry.
Too much eye candy = fisher price ugliness.
I'd say needless eye candy+associated bloat = lack of Linux sense.
There's plenty of MS stuff for that.
A.
Hello:
Just a heads-up.
Found this at The Register this morning:
Researcher bags two-for-one deal on Linux bugs while probing GNOME component
One-click exploit could potentially affect most major distros.
Wouldn't ever use Gnome but some people do.
libcue2 is present in the Devuan repositories and in my box because of audacious-plugins.
~$ apt list | grep libcue
libcue-dev/oldoldstable 2.2.1-2 amd64
libcue-dev/oldoldstable 2.2.1-2 i386
libcue2/oldoldstable,now 2.2.1-2 amd64 [installed,automatic]
libcue2/oldoldstable 2.2.1-2 i386
~$ Should get fixed soon.
Best,
A.
Hello:
... both Unstable and Testing are working on systemd, according to Distrowatch ...
... what is going on?
Could you please provide a link to the page where Distrowatch published that?
I cannot find it.
Thanks in advance.
A.
Hello:
... data on separate partitions, even on another ssd.
... mounted through fstab in /home/$USER/local/ ...
I've thought about something similar.
But decided it was a better option to make back-ups via backintime and then back those up via rsync to a recovered WD-MBLive running on OpenWRT.
Worked quite well till it didn't and stopped using it.
Fortunately, files were not lost but I now have to see how to avoid it happening again.
... a bit chatty today...
Not at all, thanks for your input.
Best,
A.
... updatedb ran when the filesystem was not mounted ...
Right.
Which is why the files ended up hiding when updatedb ran with the usually unmounted FS and showed up again if/when when I happened to run updatedb whith the FS mounted.
Hmm ...
I have come to think that Murphy works in mysterious ways ... 8^°'
Thanks for your input.
Best,
A.
Hello:
One way ...
... would be to rsync /DATA to /media/storage/ when nothing is mounted at /media/storage.
... when you do mount something there, it will hide /media/storage/DATA.
I see.
That could have easily happened.
... 'locate' shows you what it found the last time updatedb ...
Yes.
But the locate result came up repeatedly, seems that it could find the hidden files.
Which is the reason I set out to see where they were.
Thanks for your input.
Best,
A.
Hello:
Thank you for the prompt reply.
Much appreciated.
... what fstab says may be a red herring.
I see.
... the mount point is a directory in your root filesystem, and some files and directories have been moved into there when the /media/storage filesystem is not mounted.
Hmm ...
So fstab was not working properly?
... I suggest:
Done.
I then copied everything back to where it should have been ie: /media/storage/DATA and after checking everything was in place, deleted /media/storage2.
I was in a very ugly mood for the longest while when I "lost" all those files, so many thanks for this.
I've had to get at data buried under a mount point ...
But why did this happen?
It was (undoubtedly) of my own doing but I cannot imagine what I did.
I would like to avoid going through this again.
Thanks in advance.
Best,
A.
Hello:
I have come across something I am at odds with and don't understand.
I have a drive where I store data and has this fstab entry:
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in 300Gb SAS s/n JHX71JDC
# was LABEL=storage /media ext4 defaults,auto 0 2
UUID=74649bbb-7fb9-46bc-990a-d3d96dd92dd9 /media/storage ext4 nouser,noauto 0 2
#
# -------------------------------------------------------------------------------------
Early on, I went from defaults,auto 0 2 to nouser,noauto 0 2 so that is would not be mounted at all times, only when I needed to access it.
The thing is that if I want to mount it, I get the usual "Authenticate" pop-up asking for my password and once entered, I see what I think is the content.
ie:
/media/storage -> 9 folders + 9 files
Total count: 8817 files
Size on disk: 14.2Gib
Some time ago, I lost a great deal of files to a misconfigured rsync ... ... or so I thought.
Today I accidentally stumbled (via locate) on one of those files, stored in /media/storage/DATA, one of the folders I thought was long gone along with its content.
So I fired up PCMan, had a look but it was nowhere to be seen.
ie: it was not one of the 9 folders under /media/storage.
I entered /media/storage/DATA in the PCMan address bar only to get a pop-up which informed me that it was not a valid directory.
On a hunch, I unmounted the /media/storage volume in PCMan, entered /media/storage/DATA in the address bar and there it was.
Not only that: all the files I thought I had lost were there.
I think there is some sort of permission problem at hand, no idea how this happened.
When I select all the files ie: /media/storage -> 9 folders + 9 files and select properties, the Owner and Group fields are blank.
In Access Control, view content is blank and Change content reads Only owner.
In /media/storage/DATA the Owner and Group fields read root (grayed out).
In Access Control, view content is reads Anyone Change content reads Only owner.
I don't understand what is going on.
I always thought that if fstab read nouser,noauto that was it.
ie: access did not depend on the ownership of the files it contained, just on being admin/root.
What am I missing?
Most importantly, how can I fix this?
Thanks in advance.
Best,
A.
Hello:
... already released through the security repos a day before the article.
See?
No time at all. 8^P
Cheers,
A.
Hello:
This appeared on The Register tonight:
-----------------------------------------------------------------------------------------------------
Make-me-root 'Looney Tunables' security hole on Linux needs your attention
By Thomas Claburn - Wed 4 Oct 2023 // 21:27 UTC
https://www.theregister.com/2023/10/04/ … ables_bug/
-----------------------------------------------------------------------------------------------------
... a security hole that can be fairly easily exploited by rogue users, intruders, and malicious software to gain root access ...
... a buffer overflow vulnerability in the GNU C Library's handling of an environmental variable ...
... arises from the GNU C Library's dynamic loader (ld.so) mishandling of the GLIBC_TUNABLES environmental variable.
As usual. we'll see a patch/fix in no time at all.
Best,
A.
Hello:
Just got this in my inbox.
Good to see that things 'X11' are rolling along steadily.
Best,
A.
***********************************************************************************
X.Org Security Advisory: October 3, 2023
Issues in libX11 prior to 1.8.7 & libXpm prior to 3.5.17
========================================================
Multiple issues have been found in the libX11 & libXpm libraries published
by X.Org for which we are releasing security fixes in libX11 1.8.7 &
libXpm 3.5.17.
The first issue (CVE-2023-43785) can be triggered by connecting to an
X server that sends specially crafted replies to X11 protocol requests.
The other 4 issues can be triggered by opening specially crafted XPM format
image files via libXpm. Two of the four issues have root causes in the
libX11 library and are fixed there, but patches have also been applied
to libXpm to avoid passing the invalid data to libX11 in the first place.
----------------------------------------------------------------------------
1) CVE-2023-43785 libX11: out-of-bounds memory access in _XkbReadKeySyms()
Introduced in: X11R6.1 [released March 1996]
Fixed in: libX11 1.8.7
Found by: Gregory James DUCK
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When libX11 is processing the reply from the X server to the XkbGetMap
request, if it detected the number of symbols in the new map was less
than the size of the buffer it had allocated, it always added room for
128 more symbols, instead of the actual size needed. While the
_XkbReadBufferCopyKeySyms() helper function returned an error if asked
to copy more keysyms into the buffer than there was space allocated for,
the caller never checked for an error and assumed the full set of keysyms
was copied into the buffer and could then try to read out of bounds when
accessing the buffer. libX11 1.8.7 has been patched to both fix the size
allocated and check for error returns from _XkbReadBufferCopyKeySyms().
Fix:
https://gitlab.freedesktop.org/xorg/lib … 78a3358a7f
2) CVE-2023-43786 libX11: stack exhaustion from infinite recursion
in PutSubImage()
Introduced in: X11R2 [released Feb. 1988]
Fixed in: libX11 1.8.7
Found by: Yair Mizrahi of the JFrog Vulnerability Research team
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When splitting a single line of pixels into chunks that fit in a single
request (not using the BIG-REQUESTS extension) to send to the X server,
the code did not take into account the number of bits per pixel, so would
just loop forever finding it needed to send more pixels than fit in the
given request size and not breaking them down into a small enough chunk to
fit. An XPM file was provided that triggered this bug when loaded via
libXpm's XpmReadFileToPixmap() function, which in turn calls XPutImage()
and hit this bug.
Further hardening to prevent similar bugs was done in libX11 by making
XPutImage() clip images to the maximum X protocol pixmap size (limited
by the use of unsigned 16-bit integers for height & width) when writing
to X pixmaps, and by making XCreatePixmap() generate X errors if a
height or width was specified that did not fit into an unsigned 16-bit
integer. In libXpm, hardening was done to return error codes for any
call that would have passed out-of-bounds width or height values to
XCreatePixmap().
Fix:
https://gitlab.freedesktop.org/xorg/lib … 536e863a86
Hardening:
https://gitlab.freedesktop.org/xorg/lib … 0f442ddf4a
https://gitlab.freedesktop.org/xorg/lib … 0b9b48784b
https://gitlab.freedesktop.org/xorg/lib … c31a50701c
3) CVE-2023-43787 libX11: integer overflow in XCreateImage() leading to
a heap overflow
Introduced in: X11R2 [released Feb. 1988]
Fixed in: libX11 1.8.7
Found by: Yair Mizrahi of the JFrog Vulnerability Research team
Fixed by: Yair Mizrahi of the JFrog Vulnerability Research team
When creating an image, there was no validation that the multiplication
of the caller-provided width by the visual's bits_per_pixel did not
overflow and thus result in the allocation of a buffer too small to hold
the data that would be copied into it. An XPM file was provided that
triggered this bug when loaded via libXpm's XpmReadFileToPixmap() function,
which in turn calls XCreateImage() and hit this bug.
Further hardening to prevent similar bugs was done in libXpm to return
error codes for any call to XCreateImage() that would have resulted in
this calculation overflowing.
Fix:
https://gitlab.freedesktop.org/xorg/lib … 9907aea6a0
Hardening:
https://gitlab.freedesktop.org/xorg/lib … 6da02e911e
4) CVE-2023-43788 libXpm: out of bounds read in XpmCreateXpmImageFromBuffer()
Introduced in: unknown - prior to xpm-3.4k [released 1998]
Fixed in: libXpm 3.5.17
Found by: Alan Coopersmith of Oracle Solaris Engineering
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When the test case for CVE-2022-46285 (fixed in libXpm 3.5.15) was run
with the Address Sanitizer enabled, it found an out-of-bounds read in
ParseComment() when reading from a memory buffer instead of a file, as
it continued to look for the closing comment marker past the end of the
buffer.
Fix:
https://gitlab.freedesktop.org/xorg/lib … f139ed67e0
5) CVE-2023-43789 libXpm: out of bounds read on XPM with corrupted colormap
Introduced in: unknown - prior to xpm-3.4k [released 1998]
Fixed in: libXpm 3.5.17
Found by: Alan Coopersmith of Oracle Solaris Engineering
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
Fuzzing with clang's -fsanitize/libfuzzer generated an XPM file with a
corrupted colormap section which caused libXpm to read out of bounds.
Fix:
https://gitlab.freedesktop.org/xorg/lib … bc3fcd8f51
----------------------------------------------------------------------------
X.Org thanks all of those who reported and fixed these issues, and those
who helped with the review and release of this advisory and these fixes.
The X.Org security team would like to take this opportunity to remind X client
authors that current best practices suggest separating code that requires
privileges from the GUI, to reduce the risk of issues like CVE-2023-43785.
--
-Alan Coopersmith- alan.coopersmith@oracle.com
X.Org Security Response Team - xorg-security@lists.x.org
--
-Alan Coopersmith- alan.coopersmith@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Hello:
... su to root ...
From Chimaera Release notes:
https://files.devuan.org/devuan_chimaer … _notes.txt
su
The behaviour of su changed in Devuan 3 Beowulf. These changes persist
in Devuan 4 Chimaera. Use su - to get root's path or use the full path
to commands if you use only su. See the following for more information:https://www.debian.org/releases/buster/ … -variables -
https://wiki.debian.org/NewInBuster -
https://bugs.debian.org/905564
A.
Hello:
Thanks ...
You're welcome.
... look into the the kernel log and the only keyboard related stuff I found was
Ubuntu 22.04-1 (Linux version 5.15.0-43-generic) [ 0.740658] kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 23.149199] systemd[1]: Starting Set the console keyboard layout... [ 25.390693] kernel: input: Ideapad extra buttons as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:01/input/input8 Devuan 4 (Linux version 5.10.0-23-amd6) [ 2.366659] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [ 5.505134] input: Ideapad extra buttons as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/VPC2004:01/input/input6
Right.
We can see that both installs 'see' and 'identify' both the keyboard and the Ideapad extra buttons.
... must be some additional software configuration that makes them work.
Could be.
Note the process in each boot.
Ubuntu 22.04 is Starting Set the console keyboard layout... while Devuan 4 is not.
... where else to look or what to look for, as I don't recall having any keyboard related issues ...
Something (module? package?) in being loaded by Ubuntu but not by Devuan.
In Ubuntu, the infamous systemd is taking care of that.
Just in case, check dmesg for errors:
~$ sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal\|not"I recall that the issue with my 1000HE was related to a file/package (eeepc-wmi?) not loading due to some change in the kernel.
Best,
A.
Hello:
... using the daedalus version.
I do not know if these dependencies are suitable ...
Is that package in the Debian repositories?
I cannot find it.
Devuan is Debian albeit without systemd so if a package is not in the Debian repositories you won't find it in the Devuan repositories.
Now, if it is in the Debian repositories but requires systemd to run, then you won't find it in the Devuan repositories.
As a Devuan user you should know that by now. (!)
That and that installing applications from foreign repositories is really not a good idea.
That said, from the information you have posted it is quite obvious that the package you are attempting to install requires systemd to be present.
Devuan does not and will not ever use systemd.
If you really (really) need to have an appimage launcher, you will need to find a Linux distribution that uses it.
There's no way around that.
Best,
A.
Hello:
... laptops where the function keys have special action assigned to them.
My Asus 1000HE had/has a similar issue which was never fixed by Debian.
Check the Ubuntu dmesg printout against the Devuan dmesg printout and see if there's any mention of that.
There's probably some driver or module you need loaded, present in the Ubuntu distribution and not in the Debian based ones.
Best,
A.
Hello:
... ideas are appreciated!
I cannot find that package in any of the Devuan repositories.
I cannot find it in the Debian repositories either.
At this time, Devuan is Debian albeit without systemd so if a package is not in the Debian repositories you won't find it in the Devuan repositories.
Where did you get it from?
How did you install it?
Best,
A.