FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 08-15-2012, 12:17 PM
Rémy Oudompheng
 
Default Migration to systemd

On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>>>> 1./ Be a small simple binary
>>>>
>>>> The systemd main binary is not very large (larger than sysvinit's
>>>> /sbin/init, but not by much).
>>>
>>> But that binary alone is useless, and certainly not *simple*.
>>
>> /sbin/init from sysvinit alone is useless. What is your point?
>
> The rest are rather simple scripts (in the case of Arch Linux).
>
> And you are still ignoring the fact that systemd is anything but
> *simple*. How convenient to ignore that argument.

Here are my two cents about that:
* I don't care about having a faster boot if the sequence is incorrect
or buggy (or, worse, leaves me with an unbootable system)
* I don't care about having a simpler boot if it doesn't work
* I don't care about systemd or bash scripts as long as it is
maintained and bug-fixed.

The situation is:
* I hate bash
* I don't think bash scripts are simple at all
* The current initscripts do not do what I expect them to do (being
able to start services, notably when a dependency is not up).
* I don't think we have enough manpower to maintain bash scripts like
Debian folks do
* I don't think we are looking for a replacement to /sbin/init, but we
are definitely looking for a boot sequence that works

I am personnally open to having something else than systemd but I do
not see anyone showing an alternative.

Rémy.
 
Old 08-15-2012, 12:17 PM
John K Pate
 
Default Migration to systemd

> > /sbin/init from sysvinit alone is useless. What is your point?
>
> The rest are rather simple scripts (in the case of Arch Linux).
>
> And you are still ignoring the fact that systemd is anything but
> *simple*. How convenient to ignore that argument.

Those "simple scripts" are written in a Turing complete language for
doing whatever, while unit files are much more constrained in what they
can do and have been engineered to specify boot and daemon
dependencies. It's surprising to see people calling shell scripts
"simple." They are common, not simple. The basic idea behind
systemd, as I understand it, *is* simple: specify only what needs to be
specified about the boot process and daemon start-up and management.

--
John K Pate http://jkpate.net/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
 
Old 08-15-2012, 12:23 PM
Gaetan Bisson
 
Default Migration to systemd

[2012-08-15 13:31:10 +0200] Felipe Contreras:
> If you are making the claim that systemd is
> faster, you should have clear undeniable evidence at hand, where is
> it?

Everywhere:

https://encrypted.google.com/search?q=systemd+boot+time

Stop looking at your belly button for a minute and please realize that
you are the only one trying to push this nonsense of yours...

> here evidence for the contrary in my case (systemd is slower)

Too bad for you. Thank god the rest of the world is fine.

--
Gaetan
 
Old 08-15-2012, 12:26 PM
Gaetan Bisson
 
Default Migration to systemd

[2012-08-15 14:01:16 +0200] Felipe Contreras:
> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> > Am 15.08.2012 13:34, schrieb Felipe Contreras:
> >> No. The "services" (in systemd lingo) should be in an interpreted
> >> language: e.g. shell.
> >
> > Why should they be? As far as I understand, they're human-readable text
> > files. One might say this is an "interpreted language".
>
> No, they are compiled binaries. The code is in C (not interpreted).

Please just shut up when you obviously have no clue what you are talking about.

--
Gaetan
 
Old 08-15-2012, 01:03 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 2:23 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-08-15 13:31:10 +0200] Felipe Contreras:
>> If you are making the claim that systemd is
>> faster, you should have clear undeniable evidence at hand, where is
>> it?
>
> Everywhere:
>
> https://encrypted.google.com/search?q=systemd+boot+time

You call that evidence? Did you even click on that link? Most of those
results are of "fast" boot times, but not "faster" than typical init
scripts.

Do your homework and show me evidence of *before* and *after*.

> Stop looking at your belly button for a minute and please realize that
> you are the only one trying to push this nonsense of yours...

Ad populum fallacy.

--
Felipe Contreras
 
Old 08-15-2012, 01:08 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 2:26 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-08-15 14:01:16 +0200] Felipe Contreras:
>> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> > Am 15.08.2012 13:34, schrieb Felipe Contreras:
>> >> No. The "services" (in systemd lingo) should be in an interpreted
>> >> language: e.g. shell.
>> >
>> > Why should they be? As far as I understand, they're human-readable text
>> > files. One might say this is an "interpreted language".
>>
>> No, they are compiled binaries. The code is in C (not interpreted).
>
> Please just shut up when you obviously have no clue what you are talking about.

http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup-generator.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/fsck/fsck.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/hostname/hostnamed.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/random-seed/random-seed.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-analyze.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-common.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-replay.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/sd-readahead.c
http://cgit.freedesktop.org/systemd/systemd/tree/src/shutdownd/shutdownd.c

Do you need more?

--
Felipe Contreras
 
Old 08-15-2012, 01:11 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng
<remyoudompheng@gmail.com> wrote:
> On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>>>>> 1./ Be a small simple binary
>>>>>
>>>>> The systemd main binary is not very large (larger than sysvinit's
>>>>> /sbin/init, but not by much).
>>>>
>>>> But that binary alone is useless, and certainly not *simple*.
>>>
>>> /sbin/init from sysvinit alone is useless. What is your point?
>>
>> The rest are rather simple scripts (in the case of Arch Linux).
>>
>> And you are still ignoring the fact that systemd is anything but
>> *simple*. How convenient to ignore that argument.
>
> Here are my two cents about that:
> * I don't care about having a faster boot if the sequence is incorrect
> or buggy (or, worse, leaves me with an unbootable system)
> * I don't care about having a simpler boot if it doesn't work
> * I don't care about systemd or bash scripts as long as it is
> maintained and bug-fixed.

Well, systemd is known to cause problems that render the system unbootable:
https://www.google.com/search?q=systemd+unbootable

--
Felipe Contreras
 
Old 08-15-2012, 01:31 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 2:16 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 15.08.2012 14:01, schrieb Felipe Contreras:
>> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>>>>>> 1./ Be a small simple binary
>>>>>
>>>>> The systemd main binary is not very large (larger than sysvinit's
>>>>> /sbin/init, but not by much).
>>>>
>>>> But that binary alone is useless, and certainly not *simple*.
>>>
>>> /sbin/init from sysvinit alone is useless. What is your point?
>>
>> The rest are rather simple scripts (in the case of Arch Linux).
>>
>> And you are still ignoring the fact that systemd is anything but
>> *simple*. How convenient to ignore that argument.
>
> What argument? You _claim_ that it isn't simple, but you do not give any
> proof for that claim.

It is general knowledge that scripting languages are generally simpler
than compiling languages.

But fine, compare a few lines of rc.sysinit:

# mount the API filesystems
# /proc, /sys, /run, /dev, /run/lock, /dev/pts, /dev/shm
mountpoint -q /proc || mount -t proc proc /proc -o nosuid,noexec,nodev
mountpoint -q /sys || mount -t sysfs sys /sys -o nosuid,noexec,nodev
mountpoint -q /run || mount -t tmpfs run /run -o mode=0755,nosuid,nodev
mountpoint -q /dev || mount -t devtmpfs dev /dev -o mode=0755,nosuid
mkdir -p /dev/{pts,shm}
mountpoint -q /dev/pts || mount -t devpts devpts /dev/pts -o
mode=0620,gid=5,nosuid,noexec
mountpoint -q /dev/shm || mount -t tmpfs shm /dev/shm -o mode=1777,nosuid,nodev

To their equivalent in systemd:

---
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <mntent.h>

#include "log.h"
#include "util.h"
#include "path-util.h"
#include "set.h"
#include "mount-setup.h"
#include "exit-status.h"

/* Goes through /etc/fstab and remounts all API file systems, applying
* options that are in /etc/fstab that systemd might not have
* respected */

int main(int argc, char *argv[]) {
int ret = EXIT_FAILURE;
FILE *f = NULL;
struct mntent* me;
Hashmap *pids = NULL;

if (argc > 1) {
log_error("This program takes no argument.");
return EXIT_FAILURE;
}

log_set_target(LOG_TARGET_AUTO);
log_parse_environment();
log_open();

umask(0022);

f = setmntent("/etc/fstab", "r");
if (!f) {
if (errno == ENOENT) {
ret = EXIT_SUCCESS;
goto finish;
}

log_error("Failed to open /etc/fstab: %m");
goto finish;
}

pids = hashmap_new(trivial_hash_func, trivial_compare_func);
if (!pids) {
log_error("Failed to allocate set");
goto finish;
}

ret = EXIT_SUCCESS;

while ((me = getmntent(f))) {
pid_t pid;
int k;
char *s;

/* Remount the root fs, /usr and all API VFS */
if (!mount_point_is_api(me->mnt_dir) &&
!path_equal(me->mnt_dir, "/") &&
!path_equal(me->mnt_dir, "/usr"))
continue;

log_debug("Remounting %s", me->mnt_dir);

pid = fork();
if (pid < 0) {
log_error("Failed to fork: %m");
ret = EXIT_FAILURE;
continue;
}

if (pid == 0) {
const char *arguments[5];
/* Child */

arguments[0] = "/bin/mount";
arguments[1] = me->mnt_dir;
arguments[2] = "-o";
arguments[3] = "remount";
arguments[4] = NULL;

execv("/bin/mount", (char **) arguments);

log_error("Failed to execute /bin/mount: %m");
_exit(EXIT_FAILURE);
}

/* Parent */

s = strdup(me->mnt_dir);
if (!s) {
log_oom();
ret = EXIT_FAILURE;
continue;
}


k = hashmap_put(pids, UINT_TO_PTR(pid), s);
if (k < 0) {
log_error("Failed to add PID to set: %s", strerror(-k));
ret = EXIT_FAILURE;
continue;
}
}

while (!hashmap_isempty(pids)) {
siginfo_t si;
char *s;

zero(si);
if (waitid(P_ALL, 0, &si, WEXITED) < 0) {

if (errno == EINTR)
continue;

log_error("waitid() failed: %m");
ret = EXIT_FAILURE;
break;
}

s = hashmap_remove(pids, UINT_TO_PTR(si.si_pid));
if (s) {
if (!is_clean_exit(si.si_code, si.si_status, NULL)) {
if (si.si_code == CLD_EXITED)
log_error("/bin/mount for %s
exited with exit status %i.", s, si.si_status);
else
log_error("/bin/mount for %s
terminated by signal %s.", s, signal_to_string(si.si_status));

ret = EXIT_FAILURE;
}

free(s);
}
}

finish:

if (pids)
hashmap_free_free(pids);

if (f)
endmntent(f);

return ret;
}
---

If you think the second one is simpler, then I don't you know what
'simple' means.

>>>>>> 2./ Have no dependencies
>>>>>
>>>>> That is pure BS. If something has no dependencies, it has to do
>>>>> everything in the binary itself. You either end up with no features, or
>>>>> potential for tons of bugs.
>>>>>
>>>>> Having NO dependencies also means you have to bypass the C library and
>>>>> implement everything from scratch - that is the worst idea ever.
>>>>
>>>> No need to overreact, the meaning is clear:
>>>>
>>>> 2. Have as few dependencies as possible, preferably dependencies that
>>>> are used widely in most systems and that have few dependencies
>>>> themselves, and are simple themselves
>>>
>>> Okay, where exactly does systemd violate that?
>>
>> d-bus, for starters.
>
> Dependencies that are
> * used widely - check

Not as widely as shell, and libc, and util-linux. Some Arch Linux
users don't use D-Bus, in fact, and it's not by default added to
rc.conf precisely for that reason.

> * in most systems - check

Less than the Arch Linux systems that use initscripts.

> * have few dependencies themselves - check

libx11 is a cheap dependency for you?

> * are simple themselves - ahemm

D-Bus is extremely complicated. It's more than 100k likes of code.

> So, dbus almost qualifies. You said "for starters", what others are there.
>
>>>>>> 3./ Be easy to follow, fix and lockdown, best fit being interpreted
>>>>>> languages.
>>>>>
>>>>> So, init should be a small binary in an interpreted language? Am I the
>>>>> only one who notices you are contradicting yourself.
>>>>
>>>> No. The "services" (in systemd lingo) should be in an interpreted
>>>> language: e.g. shell.
>>>
>>> Why should they be? As far as I understand, they're human-readable text
>>> files. One might say this is an "interpreted language".
>>
>> No, they are compiled binaries. The code is in C (not interpreted).
>
> Ah, you mean those. You do realize that we now used many of those tools
> in our initscripts, and I don't see you complaining about that.

That is dangerous, but not as dangerous as going full systemd.

But anyway, I am merely explaining what #3 means IMO.

> There's probably plenty of reasons why they are in C, I don't know them.
> In any case, I don't see how making something in a scripting language is
> simpler - in contrast, I always find that writing a small C program for
> a task is easier and the result is more robust than a script.

And I find completely the opposite to be the case. Scripts are easier
to write, read, and debug.

> I'll stop discussing with you now, as this will lead nowhere. The fact
> remains that all you do is complain, instead of providing an
> alternative. The decisions are being made by the people who actually
> _maintain_ this stuff inside Arch.

The alternative is simple: stay with initscripts *at least* until the
problems with systemd are sorted out.

I just subscribed to this list, and 80% of the traffic I'm seeing is
problems with systemd. That should tell you something; systemd has
problems.

Cheers.

--
Felipe Contreras
 
Old 08-15-2012, 01:35 PM
Brandon Watkins
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 9:11 AM, Felipe Contreras <
felipe.contreras@gmail.com> wrote:

> On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng
> <remyoudompheng@gmail.com> wrote:
> > On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org>
> wrote:
> >>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
> >>>>>> 1./ Be a small simple binary
> >>>>>
> >>>>> The systemd main binary is not very large (larger than sysvinit's
> >>>>> /sbin/init, but not by much).
> >>>>
> >>>> But that binary alone is useless, and certainly not *simple*.
> >>>
> >>> /sbin/init from sysvinit alone is useless. What is your point?
> >>
> >> The rest are rather simple scripts (in the case of Arch Linux).
> >>
> >> And you are still ignoring the fact that systemd is anything but
> >> *simple*. How convenient to ignore that argument.
> >
> > Here are my two cents about that:
> > * I don't care about having a faster boot if the sequence is incorrect
> > or buggy (or, worse, leaves me with an unbootable system)
> > * I don't care about having a simpler boot if it doesn't work
> > * I don't care about systemd or bash scripts as long as it is
> > maintained and bug-fixed.
>
> Well, systemd is known to cause problems that render the system unbootable:
> https://www.google.com/search?q=systemd+unbootable
>
> --
> Felipe Contreras
>
Are you serious? This post amounts to flame-bait at best. Almost all of the
results from that search are about windows. You can google the same thing
with sysvinit or initscripts and get bug reports too, so what is this
supposed to prove?
 
Old 08-15-2012, 01:48 PM
Felipe Contreras
 
Default Migration to systemd

On Wed, Aug 15, 2012 at 3:35 PM, Brandon Watkins <bwat47@gmail.com> wrote:
> On Wed, Aug 15, 2012 at 9:11 AM, Felipe Contreras <
> felipe.contreras@gmail.com> wrote:
>
>> On Wed, Aug 15, 2012 at 2:17 PM, Rémy Oudompheng
>> <remyoudompheng@gmail.com> wrote:
>> > On 2012/8/15 Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> >> On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler <thomas@archlinux.org>
>> wrote:
>> >>> Am 15.08.2012 13:34, schrieb Felipe Contreras:
>> >>>>>> 1./ Be a small simple binary
>> >>>>>
>> >>>>> The systemd main binary is not very large (larger than sysvinit's
>> >>>>> /sbin/init, but not by much).
>> >>>>
>> >>>> But that binary alone is useless, and certainly not *simple*.
>> >>>
>> >>> /sbin/init from sysvinit alone is useless. What is your point?
>> >>
>> >> The rest are rather simple scripts (in the case of Arch Linux).
>> >>
>> >> And you are still ignoring the fact that systemd is anything but
>> >> *simple*. How convenient to ignore that argument.
>> >
>> > Here are my two cents about that:
>> > * I don't care about having a faster boot if the sequence is incorrect
>> > or buggy (or, worse, leaves me with an unbootable system)
>> > * I don't care about having a simpler boot if it doesn't work
>> > * I don't care about systemd or bash scripts as long as it is
>> > maintained and bug-fixed.
>>
>> Well, systemd is known to cause problems that render the system unbootable:
>> https://www.google.com/search?q=systemd+unbootable
>>
>> --
>> Felipe Contreras
>>
> Are you serious? This post amounts to flame-bait at best. Almost all of the
> results from that search are about windows. You can google the same thing
> with sysvinit or initscripts and get bug reports too, so what is this
> supposed to prove?

Your settings must be screwing the results:

Showing results for system unbootable
Search instead for systemd unbootable <- Click here

*Sigh*

--
Felipe Contreras
 

Thread Tools




All times are GMT. The time now is 04:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org