Opened 3 years ago
Closed 3 years ago
#16277 closed defect (fixed)
NetworkManager should be stopped in init 2 (sysvinit)
Reported by: | Joe Locash | Owned by: | blfs-book |
---|---|---|---|
Priority: | normal | Milestone: | 11.2 |
Component: | BOOK | Version: | git |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
blfs-bootscripts installs a start symlink for NetworkManager in rc2.d when it should be a kill symlink. From the output of make install-networkmanager:
ln -sf ../init.d/networkmanager /etc/rc.d/rc2.d/S33networkmanager
When using NetworkManager this can cause connections to get established in run-level 2 when they shouldn't be, and the connections won't be shutdown when they should if switching back to run-level 2.
rc2.d/S33networkmanager should be rc2.d/K28networkmanager
Change History (13)
comment:2 by , 3 years ago
To me the LFS run levels are:
0 halt 1 single user mode without networking 2 single user mode with networking 3 normal/full multiuser 4 reserved for local use, default is normal/full multiuser 5 multiuser with a display manager or equivalent 6 reboot
Both run levels 1 and 2 are strictly for testing/debugging by the administrator.
comment:3 by , 3 years ago
The LFS book states:
0: halt the computer 1: single-user mode 2: multi-user mode without networking 3: multi-user mode with networking 4: reserved for customization, otherwise does the same as 3 5: same as 4, it is usually used for GUI login (like X's xdm or KDE's kdm) 6: reboot the computer
comment:4 by , 3 years ago
Ok, I think any policy is good once we have chosen one. If we stick to the one proposed by Bruce in comment:2, NetworkManager should be started in runlevel 2, but inittab has to be modified to either:
- run sulogin in runlevel 2, and no agetty at all in that runlevel
- run agetty only in one virtual terminal and not in the others
ATM, 6 agetty are started in runlevel 2, so it seems closer to that is stated in the LFS book according to comment:3. But in this case, NetworkManager shouldn't be started...
follow-up: 6 comment:5 by , 3 years ago
Note that "multi-user without networking" seems a little weird in the sense that only users connected through a serial terminal can be added to the one on the console (no sshd, no vnc). Even multi-user without exporting network service is weird in that sense...
comment:6 by , 3 years ago
Replying to pierre:
Note that "multi-user without networking" seems a little weird in the sense that only users connected through a serial terminal can be added to the one on the console (no sshd, no vnc). Even multi-user without exporting network service is weird in that sense...
Left over from the 1980s. Let's assume that there are no serial terminals connected. That's why I suggested 'single user mode with networking' for run level 2.
comment:7 by , 3 years ago
Can we agree on the runlevel policy proposed by Bruce in comment:2? If so, I propose to close this ticket in favor of LFS ticket #5027, which is about general problems with the boot scripts.
I think I will endeavor to do an overhaul of those bootscripts, starting with LFS, and doing BLFS afterwards. So the actual issue reported in this ticket might not be fixed (for whatever definition of "fixed") before some while...
comment:8 by , 3 years ago
While I agree with Bruce's proposal for run level 2, I'm not sure if it would conform to the LSB. Pierre, you should have quoted the entire line from the LSB:
Conforming implementations are not required to provide these exact run levels or give them the meanings described here, and may map any level described here to a different level which provides the equivalent functionality.
I don't like the wording of the above statement but I think the requirement to map the levels in the LSB to a different one would break LSB compliance if run level 2 were changed and not mapped to a different level.
As for the way the LSB documents run level 2, I think it depends on how one interprets "no network services exported". One could argue that bringing up network interfaces but not starting network daemons would comply, but I could argue that bringing the interface up and configuring it would constitute exporting a service because the interface would respond to a ping, thus providing a service.
follow-ups: 10 12 comment:9 by , 3 years ago
Do we have to conform to LSB? It has been obsoleted by all big distros. Debian still provides some compatibility scripts, I think, but not all of them...
Non systemd distros use other init systems, that have a very different notion of runlevels (and they do not use LSB headers at all).
LSB can be used as a guide, maybe, but when it obviously wants to use left overs from the 80's, I think we can and we should depart!
comment:10 by , 3 years ago
Replying to pierre:
Do we have to conform to LSB? It has been obsoleted by all big distros. Debian still provides some compatibility scripts, I think, but not all of them...
Non systemd distros use other init systems, that have a very different notion of runlevels (and they do not use LSB headers at all).
LSB can be used as a guide, maybe, but when it obviously wants to use left overs from the 80's, I think we can and we should depart!
Agree!
comment:11 by , 3 years ago
Let me add that the reason I strongly want to continue to use the bootscripts fundamentally as they are is because they are simple. The user can look at /etc/rc.d/rcS.d and follow every step fairly easily. The same can be said for rc3.d, etc.
The only 'tricky' part is the K vs S links in rc0.d and rc6.d, but that can be changes with some changes in the Makefile when it creates the symlinks.
comment:12 by , 3 years ago
Replying to pierre:
Do we have to conform to LSB?
I'm also in agreement with Bruce on this one. The LSB is outdated. I only quoted the LSB because LFS states that it complies with LSB 5.0.
comment:13 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Redefined run level 2 to be the same as run level 4. (reserved for customization).
Marking as fixed. There are no code changes for this ticket.
See commit 7ebcd28ac325d6d80625c603beb259ddcab3b949
According to LSB, the runlevels are:
So to me, this means runlevel 2 does not run daemons that answer requests coming from the network, but it does not prevent the users on the computer to use the network, so NetworkManager should be started...
But it is also stated:
So we have some freedom for LFS/BLFS. It seems to me that runlevel 2, 3, and 4 are synonymous in our bootscripts (but I have not checked all of them), while runlevel 1 is really restricted to a single root user, and runlevel 5 only adds the display manager.
Not sure we want to change that policy...