Bug 965473

(In reply to Misi Mókus from comment #0)
> After launching the "init 3" command the system closes the (remote)
> connections.

You selected Tumbleweed as product and Leap as hardware - which one is it then?

Tumbleweed is not in the rolldown hardware list.
The distribution is Tumbleweed.

(In reply to Misi Mókus from comment #2)
> Tumbleweed is not in the rolldown hardware list.
You don't have to select this
> The distribution is Tumbleweed.

(In reply to Martin Pluskal from comment #3)
> (In reply to Misi Mókus from comment #2)
> > Tumbleweed is not in the rolldown hardware list.
> You don't have to select this
> > The distribution is Tumbleweed.

Thank you.

probably same as bug 966535

if so, please mark as duplicate

(In reply to Bernhard Wiedemann from comment #5)
> probably same as bug 966535
> 
> if so, please mark as duplicate

I can not decide that clearly.

I do not use Networkmanager (I have no wireless connection) but some applications needed it unfortunately (if I remember well), so I had to install it.
I use wicked and no wpa-supplicant.

In some cases I realize that the system believes that the media in the /media directory is removable... but it it is not obligate at all.

But maybe the firewall closes all connections if there is any port/service collision (for example Xvnc-x11vnc or other).

(In reply to Misi Mókus from comment #6)

The wpa-supplicant should be dynamically drop in. Nevertheless there seems to be a dependency issue which shuts down the network connections (and therefore the remote terminals) and/or the remote connection them self like sshd.

AFAICS the sshd is *ALSO* missed in the presets!

Who is the maintainer of the package systemd-presets-branding-openSUSE?

On the other hand if sshd.service is configured to be used on the system then it has to be enabled by the configuration tool!

Dear Mr. Fink,

firstly I have to emphasize that I am neither a system-architect, designer nor developer. I saw these in the practice. But i have seen some weird, risky and dangerous thing nowadays: I could not order some root command as the shutdown, reboot; the init command is only the last in the line. So I think we would not let to integrate these commands and "weapons" onto the average system workflows.

I think that the Linux based on root and average user ideology.
So I think that it should be FUNDAMENTAL to separate strictly the
- root (whole system setup, hardware and software, yast, server functionality)
- user (user level, login, separate desktops, client functions, program installation) and
- session (one users' different desktops, hardware environment and user program functionality)
levels.

If we build up a mass system and define different security and dependency limits on the different levels and we want the lifting among the levels... it results very risky and dangerous system.

For example:
1. If I the root and order a reboot command I do not want to see any system workflow issues, only the clear shutdown and start. Also I do not want to see ANYTHING which is able to hamper init 3 command. If it is possible at all, this is a system approach problem, I think. I only want to setup, start, stop, etc. the system or its functions without any doubt.
2. If I an average user I want to install some programs in my private environment, choose desktops, install/use clients and build my different user environments, lock the session, relogin and so on.
3. After all, if i want to use the computer, I login, open a session and use browsers, developer tools, games, whatever... I do not want to jump to the level 2 or level 1; just after finishing the session.

I think, it is possible to mix the 3 level in one system, but I think it would be better to define the 3 level separately, its functionality, security and dependencies. I have seen some sign in the Windows also.

In the end: sshd is only a program, it do not know who am I. The SYSTEM could recognize me in every moment.
Naturally it is only my personal practical opinion, sorry for that.

(In reply to Misi Mókus from comment #9)

I never ever had challenged the pratical side of loosing the network and/or remote terminal connection due to a simple runlevel change! I do fully agree with your opinion that the system has to be usable!  Nevertheless even if systemd does its job and is often the Bearer of evil tidings: this bug belongs not to systemd but to those who had ignored simple dependency rules and/or do not had tested out their changes.  Compare with the tool make(1), if there is a broken dependency rule in the Makefile then it is not make which had caused the bug but the writer of the rule.

It is possible. However the complex systems result complex problems. In our case the Linux security terminology, the programming/installing dependencies, parallel program libraries (Mesa vs nvidia) and running (Xvnc vs x11vnc, desktops), the firewall, fail2ban, apparmor, policykit, system workflow restrictions and approach (sorry for that I did not mention) a bit too much for me.

Does a genius exist who sees through the chaos? :) It occurred after a kernel version update (with other programs)...
And then I did not say a word about the kernel and program testing.

(In reply to Dr. Werner Fink from comment #8)
> (In reply to Misi Mókus from comment #6)
> 
> The wpa-supplicant should be dynamically drop in. Nevertheless there seems
> to be a dependency issue which shuts down the network connections (and
> therefore the remote terminals) and/or the remote connection them self like
> sshd.
> 
> AFAICS the sshd is *ALSO* missed in the presets!

No it's not. sshd gets enabled by YaST if requested.

Possibly partly solved?
After last update the behavior is changed.
The ssh closes the connection but the system does not crash; I can relogin immediately as normal user and change to root. The init 5 is also closes the connection after this; maybe is it normal user/root recognition problem?

Nothing new, I can not compile nvidia driver on runlevel 3.

@Misi, could you give a test to systemd located in http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/ and see if it solves your issue ?

Thanks.

1. Revision: nvidia driver can be compiled now without init 3 command.... I do not know why. I compiled it. But the (independent) remote init 3 command causes immediate disconnect without restart yet. The nvidia driver works but it has some other problems... I am tired of it (and will investigate the warning messages).
(kernel: newest)
As I see till now there is no reboot necessary after compilation... good news.

2. @Franck Bui
I made the test above with newest kernel and full update. Please write the test more precise, I do not understand clearly (if the zypper refreshed systemd then it is the newest...).

(In reply to Misi Mókus from comment #16)
> 
> 2. @Franck Bui
> I made the test above with newest kernel and full update. Please write the
> test more precise, I do not understand clearly (if the zypper refreshed
> systemd then it is the newest...).

Try to install systemd from http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/:

 $ zypper ar http://download.opensuse.org/repositories/Base:/System/openSUSE_Tumbleweed/Base:System.repo

 $ zypper dup systemd udev

 $ reboot

And then do your test.

>zypper dup systemd udev

Too many arguments.

(In reply to Misi Mókus from comment #18)
> >zypper dup systemd udev
> 
> Too many arguments.

sorry I meant "zypper up systemd udev".

zypper will probably ask you to do instead: "zypper in  systemd-228-12.1.x86_64 udev-228-12.1.x86_64" or something similar.

(In reply to Franck Bui from comment #19)
> (In reply to Misi Mókus from comment #18)
> > >zypper dup systemd udev
> > 
> > Too many arguments.
> 
> sorry I meant "zypper up systemd udev".
> 
> zypper will probably ask you to do instead: "zypper in 
> systemd-228-12.1.x86_64 udev-228-12.1.x86_64" or something similar.

"Reading installed packages...
There is an update candidate for 'systemd', but it is from a different vendor. Use 'zypper install systemd-228-12.1.x86_64' to install this candidate.
There is an update candidate for 'systemd', but it comes from a repository with a lower priority. Use 'zypper install systemd-228-12.1.x86_64' to install this candidate.
There is an update candidate for 'udev', but it is from a different vendor. Use 'zypper install udev-228-12.1.x86_64' to install this candidate.
There is an update candidate for 'udev', but it comes from a repository with a lower priority. Use 'zypper install udev-228-12.1.x86_64' to install this candidate.
Resolving package dependencies...

Nothing to do."


I have installed manually both of them.

systemd ok. udev not:

"Additional rpm output:
Failed to stop udev-control.socket: Unit udev-control.socket not loaded.
Failed to stop udev-kernel.socket: Unit udev-kernel.socket not loaded.
Additional rpm output:
Failed to stop udev-control.socket: Unit udev-control.socket not loaded.
Failed to stop udev-kernel.socket: Unit udev-kernel.socket not loaded.^COutput of udev-228-12.1.x86_64.rpm %posttrans script:
    Creating initrd: /boot/initrd-4.4.3-1-default
    dracut: Executing: /usr/bin/dracut --logfile /var/log/YaST2/mkinitrd.log --force /boot/initrd-4.4.3-1-default 4.4.3-1-default
    dracut: *** Including module: bash ***
    dracut: *** Including module: systemd ***
    dracut: *** Including module: warpclock ***
    dracut: *** Including module: systemd-initrd ***
    dracut: *** Including module: i18n ***
    dracut: *** Including module: drm ***
    dracut: *** Including module: plymouth ***
    dracut: *** Including module: kernel-modules ***
    Generating  /boot/initrd-4.4.3-1-default targets failed

Warning: udev-228-12.1.x86_64.rpm %posttrans script failed (returned 1)
There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs."

Reboot?

(In reply to Misi Mókus from comment #20)
> 
> Reboot?

yes please

(In reply to Franck Bui from comment #21)
> (In reply to Misi Mókus from comment #20)
> > 
> > Reboot?
> 
> yes please

Init 3 test:

servername:~ # init 3

^C
servername:~ #
servername:~ # init 5
servername:~ # init 3
servername:~ # init 5
servername:~ #

No usual dbus auth messages. NO disconnecting.
I am waiting for your instructions. Or check the driver again?

(In reply to Misi Mókus from comment #22)
> (In reply to Franck Bui from comment #21)
> > (In reply to Misi Mókus from comment #20)
> > > 
> > > Reboot?
> > 
> > yes please
> 
> Init 3 test:
> 
> servername:~ # init 3
> 
> ^C
> servername:~ #
> servername:~ # init 5
> servername:~ # init 3
> servername:~ # init 5
> servername:~ #
> 
> No usual dbus auth messages. NO disconnecting.

So your initial issue you reported in comment #0 is solved ?

(In reply to Franck Bui from comment #23)
> (In reply to Misi Mókus from comment #22)
> > (In reply to Franck Bui from comment #21)
> > > (In reply to Misi Mókus from comment #20)
> > > > 
> > > > Reboot?
> > > 
> > > yes please
> > 
> > Init 3 test:
> > 
> > servername:~ # init 3
> > 
> > ^C
> > servername:~ #
> > servername:~ # init 5
> > servername:~ # init 3
> > servername:~ # init 5
> > servername:~ #
> > 
> > No usual dbus auth messages. NO disconnecting.
> 
> So your initial issue you reported in comment #0 is solved ?

Yes.
Some cosmetics: the first init 3 stuck, I must type ctrl-C. And it would be more comfortable then the command would send a "successful" message... :)
Thanks for your effort.

(In reply to Misi Mókus from comment #24)
> (In reply to Franck Bui from comment #23)
> > So your initial issue you reported in comment #0 is solved ?
> 
> Yes.

Therefore it's a duplicate of bug 966535.

> Some cosmetics: the first init 3 stuck, I must type ctrl-C. And it would be
> more comfortable then the command would send a "successful" message... :)

Agreed.

However I can't see this behavour here.

Is this something reproductible on your side ? after a reboot ?

(In reply to Franck Bui from comment #25)
> (In reply to Misi Mókus from comment #24)
> > (In reply to Franck Bui from comment #23)
> > > So your initial issue you reported in comment #0 is solved ?
> > 
> > Yes.
> 
> Therefore it's a duplicate of bug 966535.
> 
> > Some cosmetics: the first init 3 stuck, I must type ctrl-C. And it would be
> > more comfortable then the command would send a "successful" message... :)
> 
> Agreed.
> 
> However I can't see this behavour here.
> 
> Is this something reproductible on your side ? after a reboot ?

What I wrote that is exactly the same what I have seen on the server, copied.
I did not make driver compilation.
Do you want any other evidence?

duplicate

*** This bug has been marked as a duplicate of bug 966535 ***