Why systemd is the way forward: technical arguments

[tomazzi]

There are two main reasons for disabling optimisations with -O0 :
1. For testing the assembler and the compiler itself.
2. Experimental software: coredumps and stack backtrace are obvoiusly different between optimised and non-optimised assembly (and the differences are sometimes really huge).
Since systemd uses ancient ways to handle errors and because it is complex, then often the only way to tell what caused the crash in particular situation is to read the coredump. Non-optimised code dumps core files which are easier to read.

Trapv: In short, it generates SIGABRT on overflows and is a compiler-level version of assert() - which just kills the problematic process. Due to a significant overhead that is produced by additional code injected by the compiler, this option is used mainly in experimental code to quickly discover programming errors. However, in production (tested) code this is normally removed - mainly due to performance issues.

And thus, for me it's obvious that the autors are "recommending" using non-optimised code which is just crashing with coredump on any trivial error, only because they have completely no idea what may happen - because it's just experimental and untested solution.

[twoflowers]

OK, I read that mailing list post and the follow ups. They explain why starting long running programs is not supported by udev and how to do it properly. If anyone still tries it and fails I will not blame it on the developers.
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.

It's a regression, 'cause udev in wheezy supports it. --> bug.

[edbarx]

Memory use with systemd running:

Code: Select all

root@sid-inst:/home/edbarx# free -m
             total       used       free     shared    buffers     cached
Mem:          1940        613       1327         64         18        246
-/+ buffers/cache:        348       1592
Swap:         3071          0       3071
root@sid-inst:/home/edbarx# uptime
 11:16:29 up 20 min,  2 users,  load average: 0.25, 0.22, 0.21

The two users are root and edbarx.

[keithpeter]

Memory use with systemd running:

Code: Select all

root@sid-inst:/home/edbarx# free -m
             total       used       free     shared    buffers     cached
Mem:          1940        613       1327         64         18        246
-/+ buffers/cache:        348       1592
Swap:         3071          0       3071
root@sid-inst:/home/edbarx# uptime
 11:16:29 up 20 min,  2 users,  load average: 0.25, 0.22, 0.21

The two users are root and edbarx.

http://0pointer.de/blog/projects/systemd-pdf.html

Perhaps working through these tutorials might give you a sense of how the author of the systemd project thinks it might work for admins? Seems to be based on progressively different versions of the systemd project but has commands to try out.

[edbarx]

Thanks for the link, it will provide me with very useful information.

[reinob]

^That was definitely not a technical describtion, but this is what I think about the situation.
Want technical? Here it is:

echo "----------------------------------------------------------------"
echo "Initialized build system. For a common configuration please run:"
echo "----------------------------------------------------------------"
echo
echo "./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs --enable-kdbus $args"

-g - include all debugging symbols
-O0 - disable ALL compiler-level optimisations
"trapv" would need a lot more explanations, but the conclusion is:
This is not even Alpha software, this is totally experimental piece of shit. I would never even dare to release a software of which I'm not sure that it can be safely used in non-debug mode. This a joke, this alone is a proove that Debian stabilty has been fucked up...

Where did you find this? I grep'd for "trapv" in systemd-215 source (from jessie). No hits.
Did you find this in a debian-provided package or upstream? (Debian does include a number of patches).

[TobiSGD]

OK, I read that mailing list post and the follow ups. They explain why starting long running programs is not supported by udev and how to do it properly. If anyone still tries it and fails I will not blame it on the developers.
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.

It's a regression, 'cause udev in wheezy supports it. --> bug.

So when someone removes a feature it is automatically a bug? Then GNOME 3 in Wheezy is a regression, since it doesn't support gnome-panel applets, while GNOME 2 in Squeeze did.
Get real, if you use something that is not supported and it fails don't blame the developers.

[edbarx]

Excuse me for posting some fiddling with systemd, but it is new to me... This is SID, the ADHD 'naughty' child!

Code: Select all

edbarx@sid-inst:~$ systemctl status udev.service
● systemd-udevd.service - udev Kernel Device Manager
   Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static)
   Active: active (running) since Wed 2014-11-26 10:56:06 UTC; 3h 31min ago
     Docs: man:systemd-udevd.service(8)
           man:udev(7)
 Main PID: 166 (systemd-udevd)
   CGroup: /system.slice/systemd-udevd.service
           └─166 /lib/systemd/systemd-udevd

I am noticing that with sysvinit, i.e. /sbin/init as PID 1, programs took longer to load, whereas with systemd as PID 1, the same programs are taking far less time to load.

For instance, loading a C code file in medit took about two seconds with sysvinit as PID 1. With systemd as PID 1, the same file loads instantly!

Memory consumption at the time of posting:

Code: Select all

edbarx@sid-inst:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          1940       1080        859         57         68        632
-/+ buffers/cache:        379       1561
Swap:         3071          0       3071

Processor load:

Code: Select all

Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.0 us,  1.5 sy,  0.0 ni, 84.9 id,  0.6 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   1987132 total,  1113604 used,   873528 free,    70620 buffers
KiB Swap:  3145724 total,        0 used,  3145724 free.   651876 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
 4886 edbarx    20   0  792372 265428  61884 S   8.6 13.4   0:29.96 iceweasel   
  465 root      20   0  197584  31712  14904 S   3.0  1.6   7:32.52 Xorg       
 4770 edbarx    20   0  393988  23792  19080 S   2.7  1.2   0:01.38 xfce4-term+
 1515 root      20   0       0      0      0 S   0.3  0.0   0:06.87 kworker/0:0
 4950 edbarx    20   0   23992   2956   2532 R   0.3  0.1   0:00.02 top         
    1 root      20   0   28856   4988   3112 S   0.0  0.3   0:00.90 systemd     
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd   
    3 root      20   0       0      0      0 S   0.0  0.0   0:03.97 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+
    7 root      20   0       0      0      0 S   0.0  0.0   0:04.28 rcu_sched 

[twoflowers]

OK, I read that mailing list post and the follow ups. They explain why starting long running programs is not supported by udev and how to do it properly. If anyone still tries it and fails I will not blame it on the developers.
It would only be a bug if they would support it and it would fail, but not if it is not supported at all.

It's a regression, 'cause udev in wheezy supports it. --> bug.

So when someone removes a feature it is automatically a bug? Then GNOME 3 in Wheezy is a regression, since it doesn't support gnome-panel applets, while GNOME 2 in Squeeze did.
Get real, if you use something that is not supported and it fails don't blame the developers.

"ls" deletes files 'cause it's cool. feature or bug? generally any undocumented change isn behaviour is a bug.

[confuseling]

If it's undocumented sure, it's a bug - possibly in the documentation.

You're not really trying to persuade me that a) no interfaces should ever be deprecated or b) the old way of doing it is better, though.

[TobiSGD]

[

"ls" deletes files 'cause it's cool. feature or bug? generally any undocumented change isn behaviour is a bug.

If ls deletes a file this is clearly a bug, because ls isn't intended in any circumstance to delete files. Just as udev is intended to react to hardware events with making changes to the system, for example with telling the service manager to start the backup service when a certain device is plugged in.
Also, they did not change this behavior "'cause it's cool", this behavior is inherent to how systemd uses cgroups to manage services.
It might have been a bug if this behavior would come up with sysvinit, but systemd is not sysvinit and for systemd this behavior is correct. Expecting systemd to behave exactly as sysvinit is kind of weird, what would be the point of systemd if it would be an exact sysvinit clone?

[reinob]

You're not really trying to persuade me that a) no interfaces should ever be deprecated or b) the old way of doing it is better, though.

One of my complaints about systemd is that its development model doesn't care about maintaining compatibility with previous versions. This may be OK as long as the program is in development, but once it is adopted by a "stable" distribution, then one'd need to make sure that the rest of programs interfacing with the init system (a la update-rc.d, etc.) should continue to work even if the init system is updated.

The Linux kernel, i.e. Linus, has a strict policy where any regression in userspace is treated as a bug in the kernel(-patch). This is something that systemd (or any sane alternative thereof) should also have to adapt in order to be successful.

Look at Windows. It's success comes mainly from maintaining compatibilty with all previous versions, including MS-DOS, which itself was succesful because it was sort-of compatible with CP/M (call 0005h et al).

Sysvinit, in its current Debian form, is IMHO a piece of hacky crap that just happens to barely work. Systemd has gotten a lot of things right, at least in the underlying idea. As long as the distribution maintainers don't have a lot of work to do (patching around API/ABI breaks) nobody will complain and everybody will be happy with it.

Just like the kernel. Distributions patch this or that, but vanilla kernel works just fine and nobody (userspace and users themselves) worries about whatever happens inside the kernel. If the kernel kept breaking compatibility then people (distributions) would perhaps think of moving to BSD or whatever.

[confuseling]

I agree with that. It'd also do a lot to quell the RedHat conspiracy / monolith fears - as soon as its external interfaces stabilise, it's forkable, and if its internal interfaces stabilise too so much the better, because people can cherrypick / reimplement parts of it...

[twoflowers]

Sprry, but "not stabilised" == "alpha".

[confuseling]

Presumably you've got examples of recent problematic changes in its external interfaces then.