OpenSnitch is causing the same problem!?!

This problem doesn’t make a big difference between VM and real hardware (your laptop), because Plasma login function is on the higher level “Applications” of OS, but not directly in Kernel.

If you don’t want to post your log and info here, you can compare two identical Plasmas with your same themes, apps and configurations in a new VM and your laptop to see if both reproduce the same issue. This would help you to track the issue and let us know.


Edit://

My guess is Deepin needs internet connection before login. If OpenSnitch blocks internet request from Deepin, the Deepin login would not work properly.

This is my guess without practical proof. You can find out for yourself why you installed OpenSnitch, why Deepin needs an internet connection when login? Does it work in Offline mode without OpenSnitch? Is Deepin malware?

I too have plasma with automatic login, and opensnitch had no problems. So definitely something to do with your setup.

You could do the classical troubleshooting step of creating a new user in plasma, and see if you can log in to that. This tells you if the problem is with system or user configurations.

And even before this, disable automatic login and see if explicit login cures the crash you see 2 seconds after what was supposed to be automatic login.

2 Likes

Deepin is not proven to be. There is no evidence that anything malicious happens under the hood.

1 Like

I actually disabled auto-login to see if I was going to have the same problem. It didn’t help! I still have the same problem.

And how…!!!

You hit the nail (that’s been sticking out above the rest) right on the head. Do you think this may be one of the areas that can be worked on and improved upon to eliminate this problem, considering the fact that anything man-made has a room for improvement?

You see an app and you think, “Hmm, I can really use that! That would be perfect for what I need!” Then you install it, not realizing that the very app you just installed has gnome or deepin dependencies, which get installed in your system. Some time later at some point, you scratch your head and wonder how the heck in the world you end up with

deepin-control-center
deepin-daemon
deepin-api
deepin-appearance
deepin-session
deepin-session-ui 
gnome-session
gnome-settings-daemon

in your system.

When you try to or want to uninstall a single “deepin” package, then it branches out to other 50 packages, which pamac cannot seem to remove (for a good reason, I guess!?). That’s when pacman comes handy to remove them all just to see your system is crippled the next time you restart it.

Maybe try to replace with original plasma packages?

bash <(curl -s https://gitlab.com/cscs/mapare/-/raw/main/mapare) -IA

(write kde at the prompt`)

Note: Since this will try to reinstall pretty much everything that would have been on the ISO … you may have extra packages you wish to remove afterwards.

By sheer coincidence, here is what I figured out!

Disabling auto-login into Plasma (X11) desktop theme (which is my native desktop theme) did not help fix the problem. We already know that!

Then I decided to disable autostart on OpenSnitch when Manjaro booted up, to see if it would start or if I would have the same problem (kicking me back out to the login screen). After the normal system boot-up to Plasma (X11) desktop theme, when I manually launched OpenSnitch, it worked perfectly fine without any problem!!! I was like, “What the heck!?!”

Then I thought the problem might be related to “Autostart” feature in “System Settings” of Manjaro. Then I decided to create a script to automatically start OpenSnitch. The script I created didn’t help, either! I still had the very same problem. I got kicked out of the natively installed Plasma (X11) desktop theme.

Just to recap, as long as OpenSnitch is not on “Autostart” when the system starts (it doesn’t matter if Manjaro is on auto or manual log-in), it is okay. OpenSnitch works fine as long as it is not auto-started!

I don’t know if anybody can make any sense out of this, but if you do, please let me know! I’m all ears for you!

Maybe related to something like

systemd-networkd-wait-online.service

IE - If its autostarted too early it wont allow some early handshake to occur without user approval, but user cannot approve before logged in, blah blah.

Autologin is rarely a good idea. Make sure to revert that.

@linux-aarhus

Would autostarting OpenSnitch as a systemd unit be of any possible benefit, considering the OP’s recent revelation:

1 Like

That would be the first thing you do after installation.

systemctl enable --now opensnitchd

The autostart feature is only the ui - the daemon itself must be running for opensnitch to function.

OpenSnitch defaults to an aggressive monitoring of outgoing connections which can be pretty annoying - so I suggest diving into the available documentation at Home · evilsocket/opensnitch Wiki · GitHub

Desktop Environment does not boot up

The related issue

Portmaster as second option

Portmaster is in the repo portmaster-stub

The firewall provides extra features if you have need of support or access to SPN (Safing Privacy Network)

please disregard the ranting and whining comments in this topic

2 Likes

Very interesting!?!

First I executed the command below in terminal

systemctl enable --now opensnitchd

Then I created the script below with 1 second delay and named it “OpenSnitch_Script” and made it executable (sudo chmod +x OpenSnitch_Script) and auto-started the script I created and it worked without any problem. It did work!!! I’m beside myself. :smiley:

#!/bin/bash
sleep 1 && opensnitch-ui

Wonderful. Now, both of you, give @linux-aarhus a little tick (under his post).

So it was related to a service … the opensnitch service … not being started. :sweat_smile:

Well, not exactly!

Right after I read your comment, I went ahead and completely removed the delay from the executable script I created, just to see what would happen without the “1 second” delay. It did not work again! I could not log in to Plasma (X11) desktop theme. Well, it would be “incorrect” to say, “I could not log in”. I was able to log in, but within 2 seconds after the login, I got kicked back out to the login screen again, which was exactly the very same problem I had, all along!

To be honest with you, I really don’t know what “1 second” delay does or what it triggers because (let’s face it!?!) 1 second delay is not much of anything to make any difference in terms of Manjaro doing what it needs to do under the hood, if you will…

It appears to me, correct me if I’m wrong!, that rather than amount of time it needs, it is just the “interruption” that the delay provides that fixes the issue that I’m having. I hope I was articulate enough to explain it properly.

Now that the service is starting correctly, your script is no longer needed. Don’t forget to remove it. :wink:

Excuse my grammar, but if it “ain’t” a malware or meant to be one, I’m sure as hell the malware coders must be envious of what “deepin” is capable of doing…!?! :wink:

Pssst… Here’s something real to be concerned about:
3 Malicious PyPI Packages Found Targeting Linux with Crypto Miners.

:stuck_out_tongue_winking_eye: That ain’t nothing for Linux, compared to Micro$oft mining the world for mone$ and more importantly…, the personal data. Linux will chew this up and and spit it out in no time! :wink:

It’s good to be a "MAN-of-JARRO" Linux-er! :grin:

1 Like

Since my Manjaro is abducted by aliens, it doesn’t operate like a normal one. :wink: Meaning, if I remove the script I created, (if I don’t trigger an autostart for the script), OpenSnitch does not automatically start when Manjaro boots up to desktop theme.

Here is the output of systemctl status opensnitchd

● opensnitchd.service - Application firewall OpenSnitch
Loaded: loaded (/usr/lib/systemd/system/opensnitchd.service; enabled; preset: disabled)
Active: active (running) since Tue 2024-01-09 20:07:05 EST; 1h 17min ago
Docs: Home · evilsocket/opensnitch Wiki · GitHub
Main PID: 4368 (opensnitchd)
Tasks: 30 (limit: 38132)
Memory: 152.3M
CPU: 1min 3.303s
CGroup: /system.slice/opensnitchd.service
└─4368 /usr/bin/opensnitchd -rules-path /etc/opensnitchd/rules

I understood that you had previously made a custom script instead of opensnitchd.service, and that opensnitchd wasn’t initially enabled by the usual opensnitchd.service script.

Of course, this entire thread has been a big bag full of confusion, so, Aliens are as good an explanation as any, I suppose. :wink:

Have fun.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.