Interesting and technical article above systemd + trolling

[tomazzi]

Hahaha !

This is really funny to see a man who don't understand the meaning of "rootless"...

"Rootless" application which has a direct access to a kernel module, like a graphics driver, don't need to have a root privileges - it already has an access to simply *everything*.

Especially, if it's a closed-src kernel module, then it's very hard to discover and block unwanted actions...

But hey! it's rootless - what a nice word, let's laugh together...

Yet another "success" ... err... dependancy?

Edit:
The post above this have disappeared - unfortunately, I didn't made a quotation - but it was something like: "thanks to systemd we can have a rootless Xorg now (happy, happy)"
/edit.

[Wheelerof4te]

^The post was probably deleted because of inappropriate content.

It's a bad time to mess around posting terrorist flags.

[tomazzi]

^The post was probably deleted because of inappropriate content.
It's a bad time to mess around posting terrorist flags.

I don't know why it was removed, but I'm pretty sure that it was nothing related to terrorism - it was just a stupid text written as a response to the thread...

Therefore, I suppose that it was deleted by the author himself - as he realized that his response was simply stupid...

Regards

[Hralgmir]

This observation related to a problem I found with systemd -
Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise:
"Additionally, systemd does not handle incorrect (Type=forking) services much better than most traditional service managers, though it is commonly
believed to. Such services are inherently flawed in that they daemonize themselves instead of delegating daemonization as is customary in a supervision
suite. There are two methods of recourse in systemd. PIDFile= with all the TOCTTOU that comes from that, or a GuessMainPID= heuristic which fails if
there is more than one daemonized PID inside a cgroup."

$ man daemon (excerpt regarding creating a daemon)
5. Call fork(), to create a background process.
6. In the child, call setsid() to detach from any terminal and create an independent session.
7. In the child, call fork() again, to ensure that the daemon can never re-acquire a terminal again.
8. Call exit() in the first child, so that only the second child (the actual daemon process) stays around. This ensures that the daemon
process is re-parented to init/PID 1, as all daemons should be.

With systemd, if a daemon forks twice as detailed above, but doesn't write a regular PID file then you might try to write a unit file of the form:
[Service]
Type=forking

But what happens is that when the first forked process exits, systemd believes it has completed. Then a sigkill is sent to the second child.
The behaviour of UNIX daemons is carefully detailed in the systemd documentation, but the ability to handle them is not included in the actual code.
It is also wrong to send a sigkill to daemons, they should be sent a sigterm and allowed to clean up on exit and a sigkill should only be sent after
waiting for a suitable time if the daemon is not responding.
A double forking daemon with no pidfile can still be started by systemd though, providing this option is used in the unit file instead:
[Service]
Type=oneshot

This approach loses the monitoring / restarting benefits of systemd though. Another method would be to only fork once as the second fork is often
unnecessary.
Needless to say, sysvinit has none of these problems, write an init script and it fires up the daemon no questions asked!

Incidentally, the problems with "nouveau" mentioned earlier are due to errors in gnome-shell and mutter, both of which are written by RedHat.
The nouveau driver was originally written by MIT, and is now maintained by RedHat. But a large section of it is in the kernel and thus comes under the
watchful eyes of Linus & co. and seems to be working as well as it ever did.
Intel made some changes to libcogl, a graphics rendering library used by desktop code, which required it's users to check for the availability of
graphics features before using them.
But the cogl sections in the RedHat code were updated by someone who apparently had not read the cogl documentation. (Although some of this is in the libcogl source code, and there are errors in the manuals.)
The cogl backend in cairo is not even enabled, some of the cogl functions have the wrong number of arguments. The cogl code in gnome-shell and mutter
does compile but is still wrong and incomplete, which is why it only works on machines that have (or simulate having) every graphics feature available.
If the cogl part of cairo was working it would enable graphics hardware acceleration quite widely, with the XFCE desktop as well.
RedHat also are behind the lack of floppy drive support in Linux, and set firewire transfers to the slowest speed possible in udisks 1.x - I'm not sure if
they still do this in 2.x. I would suspect them of being behind various USB issues too, as it would fall under their field of operation. Incorrect
wireless modules being loaded can be blamed on udev. I think they save their best work for RHEL. There is nothing new or unique for companies
contributing in a limited way to Linux but it pays to be aware of the situation, and be thankful some people are working to provide alternatives to
RedHat code.
Nvidia provide a broken (outdated and unmaintained) closed source driver for older hardware. So while RedHat code has errors and omissions, it is open
source and clearly written, often even with notes pointing to the shortfalls. So they are not exactly evil but they are limited by their business
model, and that fact will never change.
I read somewhere that later editions of systemd drop readahead so for any non - SSD hard drive machines (ie the majority in existence today) it will
become the slowest booting init system. Probably why a lot of distros are moving away from it now.

[Wheelerof4te]

I read somewhere that later editions of systemd drop readahead so for any non - SSD hard drive machines (ie the majority in existence today) it will
become the slowest booting init system. Probably why a lot of distros are moving away from it now.

I'm surprised it will even be able to boot. So no GNU/Linux for me in the future, I guess? It's ironic, that the init system praised for it's fast boot will instead become the slowest

Seems like RedHat is determined to push all older hardware to oblivion, something that is a trait of Microsoft. Or are they just helping Microsoft to curb and cut Linux growing popularity? Funny, because Microsoft Windows 10 has adopted many things from Linux, mainly RedHat distro Fedora, including ''operating system as a service''. In other words, a rolling release OS. Even windows remind me of GNOME or KDE styles. Big corps don't like them free lunches. Because everything must have it's price-tag.

In the future, maybe even the air we breathe. Hell, we are already paying for clean, drinking water.

[Head_on_a_Stick]

A double forking daemon with no pidfile can still be started by systemd though, providing this option is used in the unit file instead:
[Service]
Type=oneshot

This approach loses the monitoring / restarting benefits of systemd though.

This is not true.

In my Debian jessie system I use a custom unit file to start the wireless connection:

Code: Select all

[Unit]
Description=Wireless network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/sbin/ip l set %i up
ExecStart=/sbin/wpa_supplicant -B -i %i -c /etc/wpa_supplicant/wpa_supplicant.conf
ExecStart=/sbin/dhclient %i

ExecStop=/sbin/ip l set %i down

[Install]
WantedBy=multi-user.target

As you can see, it is "Type=oneshot" -- it makes all the usual journal entries and can be stopped and restarted normally with systemctl(1)

[Hralgmir]

Readahead has definitely been removed, Lennart explains here:
https://www.mail-archive.com/systemd-de ... 21693.html
Sadly I have only just heard of this so was unable to offer any assistance.
I can only guess that either they have become tired of the popularity of systemd or are using it to degrade the performance of older hardware as a result of pressure or financial incentives from other sections of the computer industry.
I think that it's possible to argue that systemd is written to dissuade everyone from simply copying so much of Fedora and go off and write their own distro's instead, if you look at it's monolithic entanglement with the rest of the RedHat desktop, paying no regard to existing package boundaries. Whatever their motives I don't see that it would be my first choice in future on my current hardware, although I thought I should give it a try for the moment as it is the default in Debian.
Could the dropping of optimised support for rotating HDD's give a clue that the Linux world is not going to become wholly tied to using systemd in future?
Regarding the restarting I had read that if a process is started as a forking daemon rather than using the one shot approach, if it failed to start or stopped running then systemd would register this fact and automatically try to restart it until a successful result was achieved. This caters for strange glitches that might happen at boot for example. Manually restarting is a different situation. But that is only my understanding from reading the systemd documentation and I could well be wrong as I am quite new to using it. Thank you for clarifying this.

[Head_on_a_Stick]

Yes, I would have to agree with you in respect of readahead, that is unfortunate.

EDIT: Of course, there are third-party alternatives that can replace it.

[oswaldkelso]

I have recently read some quit balanced posts on systemd but noticed that folks are becoming more cautious.

Anyway this sort of drew my attention.

https://ma.ttias.be/whats-new-systemd-2015-edition/

TBH I'm not sure if he is manic, like on speed or something. Maybe just work over-loaded is ill or just on drugs. ?

Maybe I'm just a more relaxed kind of guy

Anyway. This is what raised a few eye-browses.

The next thing is auditing, You know that auditing is this thing that NSA requires if you want to sell something to the NSA. It is a mess, an absolute disaster if you ask me. It has so many security holes it makes your system more insecure when you run it. But auditing in theory actually has nice functionality

...... yadda yadda yadda listen to the rest your self


form the link

auditing: implemented for when your application needs to be NSA approved (that appeared to be the main reason, Lennart himself said he's not a big fan of it). Can log all system calls made to /etc/passwd etc to the audit log. Auditing is integrated with journald, audit-tools to read the logs have been improved.

From my on pov the fad with Docker and containers is scary " I will store my data on the cloud stuff" You know it's safe and trustworthy etc etc

[Head_on_a_Stick]

https://ma.ttias.be/whats-new-systemd-2015-edition/

That sounds amazing o.O

Between all that luverly new functionality and pacman's new hooks, it looks like I may be wiping one of my OpenBSD laptops and moving back to TuxLand.

How's that for irony?

[oswaldkelso]

Ah of course. Arch Linux. The placebo distro of choice.

Saying that, if your going to jump ship again, there are a few interesting Arch styled disrtos. Here's my personal favs where people still cling on desperately to the the original "Arch way" long after that ship has sailed. After such terrible puns I guess I should at least mention Parabola.

http://www.obarun.org/
http://systemd-free.org/

I shall eagerly await the screen-shots

[Head_on_a_Stick]

people still cling on desperately to the the original "Arch way" long after that ship has sailed

*raises eyebrow* Really?

If you maintain that the adoption of systemd by Arch was in some way not consistent with the Arch Way, I would disagree with you.

However, that would appear to be decidedly off-topic so I will leave it at that.

[obarun]

hello,

creator of obarun stuff here

having a choice is difficult for the moment on linux communities, one option is building a linux system from a scratch. But it can be very difficult, not to make it, but to maintain it in the time. Arch offer un very great tools to make what do you want or your system i think about pkgbuild, pacman, makepkg, repo-add... those are beautiful and easy tools to configurate a system.

desperate, not, happy yes because you know it's work and can be much easier rather than building it from scratch

[geekosupremo]

From my on pov the fad with Docker and containers is scary " I will store my data on the cloud stuff" You know it's safe and trustworthy etc etc

From where I stand (which is the noob's corner) the container "fad" is kind of exciting. Consider the rise of Vagrant (and other similar projects/products) it is designed to help devs and designers work on a common code base. Then once complete move that code base as a package to their production system. Since the app/project they're making is contained, it is easy to duplicate it or just the parts of it that need extra bandwidth.

I'm no expert but that sounds really cool.

This seems like it could make life more simple for those that do virus testing or even pen testing. I might also be useful for end users as it will help block off "risky" apps, see the Qubes project. Granted this idea would rely on the systemd being secure, which is yet to be fully proven, but the idea sounds really good.

[Head_on_a_Stick]

see the Qubes project. Granted this idea would rely on the systemd being secure, which is yet to be fully proven, but the idea sounds really good.

Strictly speaking, the security of the Qubes system is dependent on the (Xen) hypervisor

[geekosupremo]

Well put HoaS! To that end the Xen system is currently better tested, as far as I know.

[oswaldkelso]

HOAS you right needs a new thread

Maybe two

[Hralgmir]

I hadn't previously tried using systemd readahead but gave it a try on 25/1/16:
[code$ sudo systemctl enable --system systemd-readahead-collect.service systemd-readahead-replay.service][/code]
I didn't notice the boot getting faster but thought perhaps it needed more configuration for non SSD hardware and left it to see if it gathered more info by itself.
A few boots later, 27/1/16 - the desktop inexplicably started booting to the Gnome Shell version when it was previously the Gnome Flashback.
Disabling readahead returned normal operation:

Code: Select all

$ sudo systemctl disable --system systemd-readahead-collect.service systemd-readahead-replay.service

Strange! It wants to decide what desktop I should use
Gnome is pretty flaky on my hardware so whether this would affect anyone else I don't know.