The future with Systemd

Here you can discuss every aspect of Debian. Note: not for support requests!
Message
Author
User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: The future with Systemd

#61 Post by golinux »

This posted on the debian-user list under the subject "embrace, extend, extinguish". The future looks bleak . . .
May the FORK be with you!

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#62 Post by keithpeter »

golinux wrote:This posted on the debian-user list under the subject "embrace, extend, extinguish". The future looks bleak . . .
The article was discussed on HN as well. The HNers were not terribly impressed :twisted:

https://news.ycombinator.com/item?id=8251288

Don't worry about The Future, it has a way of sorting itself out. Work out Jessie then start working what options are available on the Sid after Jessie.

adenukolnis
Posts: 459
Joined: 2012-02-24 18:36

Re: The future with Systemd

#63 Post by adenukolnis »

edbarx wrote:...one must find a way to emulate systemd
you would need to emulate systemd if running software that requires systemd and you are not wanting to use systemd


whereas if you currently use software that doesnt require systemd, and it doesnt require it in the future, that software should continue to be usable with sysv init


and in those cases apt-get should work to do the switcheroo assuming sysv is packaged in the future and I suspect it will be for a while

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#64 Post by edbarx »

adenukolnis wrote:
edbarx wrote:...one must find a way to emulate systemd
you would need to emulate systemd if running software that requires systemd and you are not wanting to use systemd
My post makes sense only when one considers the fact that programs are essentially a collection of interelated subroutines. These need not reside in the same executable module. Therefore, considering a program requiring systemd subroutine X, that program must somehow interface with that routine, meaning it must somehow find it somewhere. The latter is the reason for emulation. However, emulation wouldn't go as far as replacing the init system. It would only impose an additional layer to act as an interface for init to appear like systemd.

While I am all ears to listen to all valid criticism about this, I think, it avoids having to modify all software that uses systemd.

Since this is a discussion forum, I am not posting how I will get rid of systemd, but I am proposing ideas as to how it can be done. Yes, I am ready to offer my time developing an interface, but that is a task not to be done by one person alone and it needs more expertise than I currently have. I wrote C++ code in the near past and it was assessed by a university academic as excellent. So, hopefully, I can offer a hand, and definitely, it will be a pleasure to pay back for the good service GNU/Linux software has given to me.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

adenukolnis
Posts: 459
Joined: 2012-02-24 18:36

Re: The future with Systemd

#65 Post by adenukolnis »

edbarx wrote:It would only impose an additional layer to act as an interface for init to appear like systemd.
Yea its called a shim - https://packages.debian.org/jessie/systemd-shim

I am not posting how I will get rid of systemd,
I did, I will avoid any software that requires systemd and should the base system include it I will use apt-get to replace it with sysv.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#66 Post by edbarx »

adenukolnis wrote:
edbarx wrote:I am not posting how I will get rid of systemd,
I did, I will avoid any software that requires systemd and should the base system include it I will use apt-get to replace it with sysv.
Anyone can continue to use apt-get, my preferred package manager, to get rid of systemd at present and until Jessie goes Old Stable, but it is not guaranteed by the Debian DDs that such a possibility will continue to exist beyond that point.

If you found a way that is escaping us, please share.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#67 Post by keithpeter »

edbarx wrote:Anyone can continue to use apt-get, my preferred package manager, to get rid of systemd at present...
Well, here is the result of my first try at doing just that this morning on a fresh install of Jessie from CD-1 of the beta 1 installer (http://cdimage.debian.org/cdimage/jessi ... 86/iso-cd/). As I enabled wifi during install, updated packages were installed. I ended up with an XFCE4 desktop (default during testing, will no doubt get reverted to Gnome for release like it did in Wheezy).

I then did these commands from a root prompt

Code: Select all

apt-get install sysvinit systemd-
apt-get install systemd-shim
Lots of error messages, package removal including network-manager-gnome. Some googling (on a wired connection, which remains unmanaged thankfully) later, I installed

Code: Select all

apt-get install sysvinit-core
apt-get install network-manager-gnome
which resulted in a functioning system where pstree shows init...

Code: Select all

keith@teacup:~$ pstree
init─┬─NetworkManager─┬─dhclient
     │                ├─{NetworkManager}
     │                ├─{gdbus}
     │                └─{gmain}
     ├─acpid
     ├─applet.py───{gmain}
     ├─at-spi-bus-laun─┬─dbus-daemon
     │                 ├─{dconf worker}
     │                 ├─{gdbus}
     │                 └─{gmain}
     ├─at-spi2-registr───{gdbus}
     ├─atd
     ├─avahi-daemon───avahi-daemon
     ├─bluetoothd
     ├─cgmanager
     ├─cron
     ├─cups-browsed
     ├─cupsd
     ├─4*[dbus-daemon]
     ├─3*[dbus-launch]
     ├─dconf-service─┬─{gdbus}
     │               └─{gmain}
     ├─exim4
     ├─2*[gconfd-2]
     ├─6*[getty]
     ├─2*[gnome-keyring-d─┬─{dconf worker}]
     │                    ├─{gdbus}]
     │                    ├─{gnome-keyring-d}]
     │                    └─{timer}]
     ├─2*[gpg-agent]
     ├─lightdm─┬─Xorg
     │         ├─lightdm─┬─x-session-manag─┬─Thunar
     │         │         │                 ├─ssh-agent
     │         │         │                 ├─xfce4-panel─┬─mousepad───{gmain}
     │         │         │                 │             ├─panel-2-actions
     │         │         │                 │             ├─panel-6-systray
     │         │         │                 │             └─{gmain}
     │         │         │                 ├─xfdesktop───{gmain}
     │         │         │                 ├─xfwm4
     │         │         │                 ├─{gdbus}
     │         │         │                 └─{gmain}
     │         │         ├─{gdbus}
     │         │         └─{gmain}
     │         ├─{gdbus}
     │         └─{gmain}
     ├─nm-applet─┬─{dconf worker}
     │           └─{gdbus}
     ├─polkitd─┬─{gdbus}
     │         └─{gmain}
     ├─rpc.idmapd
     ├─rpc.statd
     ├─rpcbind
     ├─rsyslogd─┬─{in:imklog}
     │          ├─{in:imuxsock}
     │          └─{rs:main Q:Reg}
     ├─su───bash───nm-applet─┬─{dconf worker}
     │                       ├─{gdbus}
     │                       ├─{gmain}
     │                       └─{pool}
     ├─systemd-logind
     ├─systemd-shim───{gdbus}
     ├─udevd
     ├─upowerd─┬─{gdbus}
     │         └─{gmain}
     ├─wpa_supplicant
     ├─x-www-browser─┬─2*[{Analysis Helper}]
     │               ├─{Cache I/O}
     │               ├─{Cache2 I/O}
     │               ├─{Cert Verify}
     │               ├─3*[{DOM Worker}]
     │               ├─{Gecko_IOThread}
     │               ├─{HTML5 Parser}
     │               ├─{Hang Monitor}
     │               ├─{Image Scaler}
     │               ├─{JS GC Helper}
     │               ├─{JS Watchdog}
     │               ├─{MediaManager}
     │               ├─{Network Seer}
     │               ├─{Proxy R~olution}
     │               ├─{Socket Thread}
     │               ├─{Timer}
     │               ├─{URL Classifier}
     │               ├─{dconf worker}
     │               ├─{gdbus}
     │               ├─{gmain}
     │               ├─{localStorage DB}
     │               ├─{mozStorage #1}
     │               ├─{mozStorage #2}
     │               ├─{mozStorage #3}
     │               ├─{mozStorage #4}
     │               ├─{mozStorage #5}
     │               ├─{mozStorage #6}
     │               ├─{mozStorage #7}
     │               └─{mozStorage #8}
     ├─xfce4-notifyd
     ├─xfce4-power-man───{gdbus}
     ├─xfce4-terminal─┬─bash───su───bash
     │                ├─bash───pstree
     │                ├─gnome-pty-helpe
     │                ├─{gdbus}
     │                └─{gmain}
     ├─xfce4-volumed─┬─{gdbus}
     │               ├─{task0}
     │               └─{task1}
     ├─2*[xfconfd]
     ├─xfsettingsd───{gmain}
     └─xscreensaver
The system works but I have a desktop that can't close down or connect to wifi because of permissions issues. I have to use reboot and nm-applet from a root prompt. I also have a lot of packages marked for autoremove (see below). I suspect that has occured because of my first omission of sysvinit-core and the consequent removal of packages and will reinstall and try again now I know what to expect.

Packages that apt-get wants to remove

Code: Select all

root@teacup:/home/keith# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... The following packages were automatically installed and are no longer required:
  colord-data gdebi-core gdisk gvfs-common gvfs-libs hplip-data libart-2.0-2
  libcolorhug2 libelfg0 libglib2.0-bin libgusb2 libsane-hpaio libudisks2-0
  packagekit-backend-aptcc python-imaging python-pexpect python-renderpm
  python-reportlab python-reportlab-accel python3-apt python3-chardet
  python3-dbus python3-debian python3-gi python3-packagekit
  python3-pkg-resources python3-six
Use 'apt-get autoremove' to remove them.
Done
The following packages have been kept back:
  base-passwd
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
I remember the colord daemon being uninstalled when I did the first apt-get command. I'll post back when I try a second installation with more considered commands.

adenukolnis
Posts: 459
Joined: 2012-02-24 18:36

Re: The future with Systemd

#68 Post by adenukolnis »

edbarx wrote:... but it is not guaranteed by the Debian DDs that such a possibility will continue to exist beyond that point.
nor is it written that sysv shall be removed from the repo as soon as jessie goes oldstable

Systemd was chosen as default, it doesnt mean that all other choices are going to disappear.

The choices exist and I suspect will still exist until we are all dead and gone

Debian packages do not magically disappear from the repos. As long as sysv is maintained there is no reason for it to be removed. Even if it was to be removed I suspect a 3rd party repo would quickly appear.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#69 Post by edbarx »

Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd. The only problem I found was with udev complaining about legacy wireless drivers I don't use. It pauses the booting sequence for a few second but then it continues normally. Jessie is now using init. :shock: :mrgreen:
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
golinux
Posts: 1575
Joined: 2010-12-09 00:56
Location: not a 'buntard!

Re: The future with Systemd

#70 Post by golinux »

Another good analysis of the systemd takeover from the debian-user list. Why doesn't Linus DO something?!
May the FORK be with you!

ratcheer
Posts: 143
Joined: 2012-09-10 20:40

Re: The future with Systemd

#71 Post by ratcheer »

Poettering's view of the future of Linux:
http://0pointer.net/blog/revisiting-how ... stems.html

Tim

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#72 Post by edbarx »

The invasion of systemd of GNULand is similar to what happened in WWII. Back in those times, many politicians with the exception of Winston Churchill didn't realise that Hitler's Germany was dangerously arming itself. When the war started, it was too late for no lives to be lost and around 60 million people died.

In my analogy above, I am saying that it will be painful to get away from systemd and its claws but it will happen. As long as there is open source and a liberal license, there is hope.

Added Later:
People who want a stable system, nowadays do not need to go away from MS Windows as the latter is stable and reliable for most purposes. The type of Linux users who will be attracted by systemd's similarity to MS Windows are clueless newbies who will ultimately realise that their new choice is nothing new at all. This dissatisfaction will make them search for more freedom as it did to many of us who use GNU/Linux and who are worried about the unjustified grip systemd is having on other seemingly unrelated packages.

Liberty aware GNU/Linux users, whether they happen to be newbies or ripe, will ultimately face the reality of systemd and will despise it for raping GNU/Linux stealing its verginity. GNU/Linux was created with the value of total freedom as its central value rejecting any attempt at manipulative packages that impose too many restrictions. This hidden agenda will sometime surface and will be despised for the manipulations it is attempted to accomplish.
Last edited by edbarx on 2014-09-02 17:17, edited 1 time in total.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#73 Post by keithpeter »

edbarx wrote:Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd.
Care to share the actual commands you used? And the pstree output? And which desktop env/WM?

I'm having an interesting time with permissions for network manager and the desktop on my second test install of Jessie, this time using a base install, sysvinit install and then adding the desktop.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#74 Post by edbarx »

keithpeter wrote:
edbarx wrote:Learning that init will continue to be supported, at least until Jessie is Old Stable, I first installed init and removed systemd.
Care to share the actual commands you used? And the pstree output? And which desktop env/WM?

I'm having an interesting time with permissions for network manager and the desktop on my second test install of Jessie, this time using a base install, sysvinit install and then adding the desktop.
With pleasure! :)

This is the sequence I used:
Note that Jessie was always booted up in single user maintenance mode.

Code: Select all

  417  apt-get update
  418  apt-get upgrade
  419  apt-get install sysvinit
  420  top  //to confirm the presence of systemd running
  422  apt-get install systemd-shim
  430  apt-get install sysvinit-core
  433  apt-get remove systemd
  434  locate init
  440  apt-get -f install
  441  reboot
Make sure /sbin/init exists after you remove systemd. Also note that some programs may misbehave expecting the presence of systemd after you remove it. Reboot to pacify them.

Due to two critical bugs sysvinit-core may not be installed properly. To make sure everything is properly done, I executed the following command after booting with init.

Code: Select all

apt-get install --reinstall sysvinit sysvinit-core systemd-shim
Desktop/Window Manager: XFCE4

Code: Select all

init-+-acpi_fakekeyd
     |-acpid
     |-at-spi-bus-laun-+-{dconf worker}
     |                 `-{gdbus}
     |-cgmanager
     |-console-kit-dae-+-62*[{console-kit-dae}]
     |                 |-{gdbus}
     |                 `-{gmain}
     |-cron
     |-2*[dbus-daemon]
     |-dbus-launch
     |-2*[dhclient]
     |-6*[getty]
     |-privoxy
     |-rsyslogd-+-{in:imklog}
     |          |-{in:imuxsock}
     |          `-{rs:main Q:Reg}
     |-slim-+-Xorg
     |      `-x-session-manag-+-Thunar-+-{gdbus}
     |                        |        `-{gmain}
     |                        |-xfce4-panel-+-iceweasel-+-{Cache I/O}
     |                        |             |           |-{Cert Verify}
     |                        |             |           |-{DNS Resolver #6}
     |                        |             |           |-{DOM Worker}
     |                        |             |           |-{Gecko_IOThread}
     |                        |             |           |-{HTML5 Parser}
     |                        |             |           |-{Hang Monitor}
     |                        |             |           |-2*[{JS GC Helper}]
     |                        |             |           |-2*[{JS Sour~ Thread}]
     |                        |             |           |-{JS Watchdog}
     |                        |             |           |-{Socket Thread}
     |                        |             |           |-{Timer}
     |                        |             |           |-{URL Classifier}
     |                        |             |           |-{XPCOM CC}
     |                        |             |           |-{gmain}
     |                        |             |           |-{mozStorage #1}
     |                        |             |           |-{mozStorage #2}
     |                        |             |           |-{mozStorage #3}
     |                        |             |           |-{mozStorage #4}
     |                        |             |           |-{mozStorage #5}
     |                        |             |           |-{mozStorage #6}
     |                        |             |           |-{mozStorage #7}
     |                        |             |           `-{mozStorage #8}
     |                        |             |-panel-6-systray
     |                        |             |-panel-8-mixer---{task0}
     |                        |             `-{gmain}
     |                        |-xfdesktop---{gmain}
     |                        |-xfwm4
     |                        `-{gmain}
     |-syndaemon
     |-udevd
     |-upowerd-+-{gdbus}
     |         `-{gmain}
     |-wpa_supplicant
     |-xfce4-power-man---{gdbus}
     |-xfce4-power-man
     |-xfce4-terminal-+-bash---pstree
     |                |-gnome-pty-helpe
     |                |-{gdbus}
     |                `-{gmain}
     |-xfce4-volumed-+-{gdbus}
     |               `-{task0}
     |-xfconfd
     |-xfsettingsd---{gmain}
     `-xscreensaver
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#75 Post by keithpeter »

edbarx wrote: This is the sequence I used:
Note that Jessie was always booted up in single user maintenance mode.

Code: Select all

  417  apt-get update
  418  apt-get upgrade
  419  apt-get install sysvinit
  420  top  //to confirm the presence of systemd running
  422  apt-get install systemd-shim
  430  apt-get install sysvinit-core
  433  apt-get remove systemd
  434  locate init
  440  apt-get -f install
  441  reboot
Make sure /sbin/init exists after you remove systemd.
Thanks for posting this chunk of the history file!

Same result as before I'm afraid. The apt-get remove systemd step results in a dpkg error as it decides it can't remove a running init system. The locate init step failed because I had not installed the command :oops: . The apt-get -f install step completes aspects of the installation of console kit and a few other bits and pieces that I recognise. Rebooting (Ctrl-Alt-Del as the 'reboot' command no longer works at that stage) results in a functioning desktop session that can't run anything needing root permissions, e.g. network manager or shutting down from the XFCE4 menus. Lightdm, slim makes no difference (using slim at present).

My user is in netdev and plugdev

More googling later in the week as time allows! It could just be that Jessie is in an inconsistent state at present, perhaps policy kit type default files not being set up or something.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#76 Post by edbarx »

Don't be discouraged. The trick lies in either pulling in the installation of init with other packages as I did or explicitly installing init as in apt-get install init. Once you have init together with its other two or three dependencies, you can try to force a boot with init. You have to look that up, but I am sure, you should then be able to remove systemd as it wouldn't be loaded.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#77 Post by keithpeter »

edbarx wrote:Don't be discouraged. The trick lies in either pulling in the installation of init with other packages as I did or explicitly installing init as in apt-get install init. Once you have init together with its other two or three dependencies, you can try to force a boot with init. You have to look that up, but I am sure, you should then be able to remove systemd as it wouldn't be loaded.
Discouraged? Me? Nope.

Init is definitely installed and running the show, unless pstree is telling lies. The apt-get -f install step did report the removal of systemd (27Mb or so), so I think it has gone. More research as time allows.

The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal. Something somewhere has either changed the permissions that xfce4 programs and lightdm/slim run under or removed permissions previously granted and failed to re-grant them.

PS: if you build your systemd emulator for future releases, you do realise that you will gain very detailed and thorough knowledge of the systemd api and mode of operation? Far more than most practicing sysadmins will ever need. Loving the irony of the whole situation.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#78 Post by edbarx »

keithpeter wrote:The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal.
Oops, I didn't remember correctly. That issue is described in this thread:
http://forums.debian.net/viewtopic.php?f=5&t=114412

It can be corrected by downgrading the mentioned three packages.
Last edited by edbarx on 2014-09-02 20:48, edited 1 time in total.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

User avatar
keithpeter
Posts: 502
Joined: 2009-06-14 08:06
Location: 5230n 0155w

Re: The future with Systemd

#79 Post by keithpeter »

edbarx wrote:
keithpeter wrote:The problem is one of the desktop itself running with reduced permissions. The functions affected (nm-applet, 'reboot' and 'shutdown' commands &c) all run from a *root* terminal.
You are on the wrong track with that. Those reduced permissions are not a symptom of reinstalling init but of systemd itself. I remember I had those exact issues when I was still running systemd and I am still having them. But I am satisfied of ridding myself of the loathed monster.
Today, all the initial installations of Jessie with systemd have shown expected behavior, e.g. being able to use nm-applet from the toolbar to connect to wifi and being able to use the XFCE4 menu to shutdown and restart. It is when I replace systemd with init that I see the unexpected behaviour. It could be that the (always expected in testing) bugs are fixed in systemd but not yet in systemd-shim or other dependencies.

Which is a good reason for giving this a rest for a day or two to see what the updates bring, and to research a little more on those critical bugs and the patch timeline.

Thanks for replies, I am learning a lot from all this.

PS: as a general comment, I think we should perhaps present this issue in bug reports and in arenas where developers will actually read what is said as a purely technical one: e.g. monitoring and preserving the sysvinit functionality while the packages remain in Debian and raising bugs as needed. Anything else is playing into the hands of some very sophisticated corporate operators.
Last edited by keithpeter on 2014-09-02 20:56, edited 1 time in total.

User avatar
edbarx
Posts: 5410
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: The future with Systemd

#80 Post by edbarx »

Please see my previous post again as the previous one was incorrect. That behaviour is due to three packages, downgrading them may solve the issue.

P.S.
However, downgrading these three important packages would be mixing Stable with Testing and is definitely asking for trouble. I think it is better to configure sudo to allow a normal use to execute the required commands.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.

Post Reply