Removing Systemd

[seppalta]

What should I expect if I replace systemd with sysvinit in Sparky_Base?  See http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation.  Has anyone experience here?  What happens when dist-upgrading?

[way12go]

Here is your answer...

Code Select Expand

https://devuan.org/

Code Select Expand

http://without-systemd.org/wiki/index.php/Main_Page

[pavroo]

Looks like the revolution has started

[GeneC]

Personally I have no issue with systemd.. :P  I dont see what all the fuss is about.  It boots considerably faster than sysv init.

But, it seems easy enough to convert back.

From way12go's link...

http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

(I haven't tried it, so cant comment on its effectiveness --Use at your own risk)... ;)

How to remove systemd from a Debian jessie/sid installation
First install the SysV init packages

Code Select Expand

# apt-get install sysvinit-core sysvinit sysvinit-utils
Then reboot your machine and remove all of the systemd packages

Code Select Expand

# apt-get remove --purge --auto-remove systemd
Prevent apt from installing systemd packages in the future.

Code Select Expand

# echo -e "Package: systemd\nPin: origin ""\nPin-Priority: -1" > /etc/apt/preferences.d/systemd

[MoroS]

Personally I have no issue with systemd.. :P  I dont see what all the fuss is about.  It boots considerably faster than sysv init.

Politics? Philosophy? I guess... There are some many points where systemd breaks the basic UNIX philosophy, that practically created GNU. The logs are binary and not that easy to recover when the system goes down. The other thing is that systemd is taking the Microsoft approach: "monolitic everything". This goes agains Linux, which by definition should me "modular everything". Some people don't have a problem with it. Other do. I myself was wondering if there should be an attempt to modernize sysinitv, to make use of modern coding techniques and standards.

[GeneC]

Now that you mention logs. I notice there is no 'journal' (/var/log/journal/) folder and file generated in Sparky.?  That must be by design, as I find them in my Manjaro and Arch (both also systemd) installs. 

Edit:
Spelling... :-[

[MoroS]

Now that you mention longs. I notice there is no 'journal' (/var/log/journal/) folder and file generated in Sparky.?  That must be by design, as I find them in my Manjaro and Arch (both also systemd) installs.

If it's by design, then it's by Debian design. As far as I know we didn't modify anything regarging systemd.

[way12go]

I'm not sure but this thing /var/log/journal/ keeps in growing in size? It's good not to have it?

[GeneC]

^
Doesn't hurt anything, just can take up a LOT of space..  You can limit its size, though...

https://wiki.archlinux.org/index.php/systemd#Journal_size_limit

Journal size limit
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. For example, with /var/log/journal located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by SystemMaxUse in /etc/systemd/journald.conf, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:

Code Select Expand

SystemMaxUse=50M
Refer to man journald.conf for more info.

I set mine in Arch to 10M.
Dont have one in Sparky..?

gene@sparky:~$ journalctl -b
No journal files were found.

============================

[gene@arch ~]$ journalctl -b
-- Logs begin at Tue 2014-12-02 07:17:01 EST, end at Tue 2014-12-02 07:17:36 EST. --
Dec 02 07:17:01 arch systemd-journal[156]: Runtime journal is using 8.0M (max allowed 601.0M, trying to l
Dec 02 07:17:01 arch systemd-journal[156]: Permanent journal is using 4.0M (max allowed 8.0M, trying to l
Dec 02 07:17:01 arch systemd-journal[156]: Time spent on flushing to /var is 696us for 2 entries.
Dec 02 07:17:01 arch kernel: Initializing cgroup subsys cpuset
Dec 02 07:17:01 arch kernel: Initializing cgroup subsys cpu
Dec 02 07:17:01 arch kernel: Initializing cgroup subsys cpuacct
Dec 02 07:17:01 arch kernel: Linux version 3.17.4-1-ARCH (builduser@tobias) (gcc version 4.9.2 (GCC) ) #1
Dec 02 07:17:01 arch kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=3efe1772-526e-4f9d-89
Dec 02 07:17:01 arch kernel: tseg: 0000000000
Dec 02 07:17:01 arch kernel: e820: BIOS-provided physical RAM map:
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x00000000000e2000-0x00000000000fffff] reserved
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cff6ffff] usable
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x00000000cff70000-0x00000000cff87fff] ACPI data
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x00000000cff88000-0x00000000cffcffff] ACPI NVS
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x00000000ffa00000-0x00000000ffffffff] reserved
Dec 02 07:17:01 arch kernel: BIOS-e820: [mem 0x0000000100000000-0x000000032fffffff] usable
Dec 02 07:17:01 arch kernel: NX (Execute Disable) protection: active
[...]

[py-thon]

According to https://denibertovic.com/posts/setting-up-systemd-on-debian-in-10-minutes/ the default setting for Debian is for non-persistent logging to /run.

I dont see what all the fuss is about.  It boots considerably faster than sysv init.

That's funny. My system does not boot any faster than LMDE with sysvinit I used before. But shutdown is considerably faster (maybe 3 seconds using Sparky and systemd vs. 20 seconds using LMDE with sysvinit).
I don't see what the fuss is about either, but I am no programmer, so maybe I lack the insight  :)

[GeneC]

Hi py-thon

Thanks for the link, interesting reading..

One last thing with Debian is to set up peristent logging with systemd's logging component called journal. By default journal will log to /run which is ephemeral meaning the logs will disappear after reboot. The process of making the logs persistent (if you choose to do so) is documented here: /usr/share/doc/systemd/README.Debian
..............
It's worth noting that you don't have to use journal if you don't want to, it's designed to co-exist with syslog, that's already running on your system, so you can continue to use that. I personally find journal awesome and would recommend that you at least check it out and see what it brings to the table.

That explains why no journal log for me on Sparky..  I don't miss it.  The other 'syslogs' are actually more helpful.  As for boot times, et.  I believe a lot depends on individual hardware and configs.

And YES, it does appear that internal debian politics account for a lot of the fuss.... ;)

[dhinds]

The commentary on DistroWatch generally opposes systemd for the reasons mentioned:  A loss of modularity and therefore, control.

I upgraded an openSUSE xfce installation from 13.1 to 13.2 via zypper dup last night and that installed systemd.  On rebooting the process was noticeably faster but someone else posted that the opposite was true, on his machine.

The question here is whether a Debuan version of Sparky is contemplated?  The only way to know for sure is to try them both.

[way12go]

Code Select Expand

http://sourceforge.net/projects/antix-linux/files/Testing/antiX-14R/

Uploaded 12 October 2014

antiX-14-a3 series

Includes full and core-libre versions for both 32 and 64 bit.

R=rolling

V=sysVinit

D=systemD