systemd vs initscripts?

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
scsijon
Posts: 1596
Joined: Thu 24 May 2007, 03:59
Location: the australian mallee
Contact:

systemd vs initscripts?

#1 Post by scsijon »

Could we have some comments on using systemd rather than initscripts, if anyone has anything of use please.

As a number of others linux's are converting across.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

Puppy doesn't even use 'init', so systemd is basically irrelevant here.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#3 Post by technosaurus »

do any of them support shifting this until after the desktop is up? - pretty sure they all suck at this
how much _really_ needs to be done before X? - turns out not much if you don't believe in using "runlevels" and don't need to be multiuser

here is an example where I use jwm's <StartupCommand> to finish the init process inside rxvt after jumping into Xvesa with rox and jwm

Code: Select all

/*	Copyright 2011 Brad Conroy.  Released to the Public Domain or 
	redistributable under any OSI approved license, or
	any license meeting the OSI definition of open source
	*/
#include <unistd.h> /* for exec */
#include <sys/mount.h> /* for mount */
#include <stdlib.h> /* for putenv */

/* these could be functions but gcc complains less this way */
#define EGGSACK(a)	({if((fork())==0) execvp(a[0],a);})

int main(int argc, char** argv) {
char *Xvesa[]={"Xvesa","-screen","1024x768x24","-nolisten","tcp","-tst",NULL},
	*rox[]={"rox","-p","default",NULL},
	*jwm[]={"jwm","-display",":0",NULL};
/* possibly use getenv(screen) and set it on kernel command line */
EGGSACK(Xvesa);

//Xvesa doesn't need any of this, so run it while X starts up
mount("/proc", "/proc", "proc", MS_MGC_VAL, NULL); /* error if not in kernel */
mount("/sys", "/sys", "sys", MS_MGC_VAL, NULL); /* error if not in kernel */
if (! mount("/dev", "/dev", "devtmpfs", MS_MGC_VAL, NULL)) /* fallback to tmpfs */
	mount("/dev", "/dev", "tmpfs", MS_MGC_VAL, NULL); 
mount( "/dev/pts", "/dev/pts", "devpts", MS_MGC_VAL, NULL ); /* for terminals */

/* setenv uses malloc, larger, but less ram - setenv("PATH","/bin",1); */
putenv("PATH=/bin"); /* using simplified file system */
putenv("HOME=/"); /* will set to /root later */
putenv("TERM=rxvt");
putenv("PS1=# ");
putenv("APP_DIR=/usr/share/ROX-Filer");
putenv("CHOICESPATH=/usr/share");
putenv("SHELL=/bin/sh");
putenv("DISPLAY=:0");

EGGSACK(rox);
/* considered using vfork vs fork to save ~100kb RAM = kernel panic on jwm exit */
EGGSACK(jwm);
/* must keep init running or kernel panic */
while (1) sleep(1);
}
Last edited by technosaurus on Sun 03 Jun 2012, 17:17, edited 1 time in total.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#4 Post by Karl Godt »

I do not agree with amigo in this case ,

Puppy uses " busybox init " which the kernel runs after finally decompressed by running automatically /sbin/init if no " init=/path/to/program (ie init=/bin/bash) kernel parameter . Also the 'S' kernel parameter is interesting .

Puppy comes not with /sbin/init-FULL binary both in main.sfs and devx.sfs additionally .

Basically /sbin/init-FULL runs the shellscript scripts in /etc/rc.$NR_of_RUNLEVEL .

Have not heard about systemd or forgotten about it.

Almost all LInux come with sudo and it is tiring to work with these .

After somehow two years i bought a Linux magazine with several 700MB live distros like xubuntu,mint,grml and was not impressed at all . Could not work with their network-manager's and was not able to mount anything .

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#5 Post by Flash »

I'm sure I don't know what you guys are talking about, but here's my two cents worth anyway :lol: :

One of the most annoying things about Windows to me is that when it boots, it appears to be ready to do something before it has really finished booting. Why Microsoft thinks that's a good idea, I don't know. Maybe they think people expect it to have to warm up for a while after the desktop shows up. I want the computer to be fully booted and ready to go the instant the desktop pops onto the screen. Until then, show the boot messages or a progress bar or something. :!:

User avatar
RSH
Posts: 2397
Joined: Mon 05 Sep 2011, 14:21
Location: Germany

#6 Post by RSH »

Init, Upstart and Systemd are responsible for the boot sequence and the therefor needed services to start.

- Init was the first ever used in linux (as far as i know)
- Upstart was the progression of Init
- Systemd is not a progression of Upstart - it is a new generation

Sytemd is now used f.e. in Fedora 15 Lovelock using the gnome 3 desktop

The new thing on Systemd is that all services are started simultaneously and then they are buffered. This way a service doesn't have to wait if it is dependent on other services.
[b][url=http://lazy-puppy.weebly.com]LazY Puppy[/url][/b]
[b][url=http://rshs-dna.weebly.com]RSH's DNA[/url][/b]
[url=http://murga-linux.com/puppy/viewtopic.php?t=91422][b]SARA B.[/b][/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#7 Post by technosaurus »

RSH wrote: The new thing on Systemd is that all services are started simultaneously and then they are buffered. This way a service doesn't have to wait if it is dependent on other services.
In bash/shell this is accomplished with
command args &
ThisPID=$!
...
wait $ThisPID
dependent_command

In c this is done with fork exec wait (my example uses fork and exec, but I figured out a way to eliminate the delayed wait, so no example of that yet)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#8 Post by Iguleder »

Personally, I'm not impressed with systemd. I like the BusyBox init, it's simple and doesn't do anything fancy.

When I want to start daemons in the background, I just make the init script fork before it executes them, so they start in parallel with X or whatever it is. I get the performance systemd gives, without having to learn something new or write new init scripts.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#9 Post by PaulBx1 »

I've been using arch lately, which is going over to systemd. There are a couple of things here.

1) Makes for a zippy boot. My arch boots way faster than Puppy ever did, on the same machine. However arch booted faster than Puppy with the old sysv init, but now it is going even faster. I spend the most time typing in my lengthy encryption password. There are lots of ways to play with systemd in native mode getting it even faster (systemd is initially set up as a sort of compatibility mode with sysv to ease the transition, but one doesn't harvest much of the speed increases until going over to native mode). The reason Puppy boots so slow is heavy use of shell scripts, according to the systemd author (he didn't mention Puppy directly but just said shell scripts really suck for speed).

(OK, I just realized that Puppy is booting off a (fast) USB flash drive while arch is booting off my SATA SSD drive, so that might have something to do with it, heh...)

2) systemd also goes in the direction of standardization of linux. Every distro used to have its own flavor of doing essentially the same thing, but that will be simplified and streamlined with systemd.

I'm hardly a developer or a geek, but I managed to figure it out pretty well so far. I think it would be worth looking at, integrating it into woof. Puppy runs like a rocket ship, it should boot like one too.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#10 Post by jpeps »

I noticed some early concerns about services not being available (ie, daemons not running) until called, such as when using servers (SSH, apache, etc.), although I'm guessing this has since been worked out if distros such as Fedora have adopted it.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#11 Post by PaulBx1 »

Here is a post that discusses why arch went over to systemd. You can decide for yourself how much it applies to Puppy.

https://bbs.archlinux.org/viewtopic.php ... 0#p1149530

My arch boot times are around 28 seconds including typing in a lengthy password. However boot times are actually kind of a side issue.

Probably the largest cost of going over to systemd is fixing the documentation!

I doubt Barry would ever go over to systemd, because systemd is all about eliminating scripts; and all Puppy is, is scripts. :lol:

User avatar
darkcity
Posts: 2534
Joined: Sun 23 May 2010, 19:16
Location: near here
Contact:

#12 Post by darkcity »

so puppy uses busybox init, I was wondering about this. I'm still confused as to what exactly Puppy does on start up. Is there information that explains this step by step?

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#13 Post by seaside »

darkcity wrote:so puppy uses busybox init, I was wondering about this. I'm still confused as to what exactly Puppy does on start up. Is there information that explains this step by step?
darkcity,
Startup:
When Puppy boots, the order of execution of the
scripts is (except for a full-hd installation and UniPup):

/init (in the initial ramdisk)

switch_root occurs, some content of / relocates to /initrd
and the following scripts then executed:

/etc/rc.d/rc.sysinit
Called from rc.sysinit:
/etc/rc.d/rc.update
/etc/rc.d/rc.network (as a parallel process)
/etc/rc.d/rc.services (as a parallel process)
/etc/rc.d/rc.country
/etc/rc.d/rc.local (created by rc.sysinit if doesn't exist)

/etc/profile
This is from /etc/rc.d/READme.txt

Cheers,
s

User avatar
darkcity
Posts: 2534
Joined: Sun 23 May 2010, 19:16
Location: near here
Contact:

#14 Post by darkcity »

seaside wrote:
darkcity wrote:so puppy uses busybox init, I was wondering about this. I'm still confused as to what exactly Puppy does on start up. Is there information that explains this step by step?
darkcity,
Startup:
When Puppy boots, the order of execution of the
scripts is (except for a full-hd installation and UniPup):

/init (in the initial ramdisk)

switch_root occurs, some content of / relocates to /initrd
and the following scripts then executed:

/etc/rc.d/rc.sysinit
Called from rc.sysinit:
/etc/rc.d/rc.update
/etc/rc.d/rc.network (as a parallel process)
/etc/rc.d/rc.services (as a parallel process)
/etc/rc.d/rc.country
/etc/rc.d/rc.local (created by rc.sysinit if doesn't exist)

/etc/profile
This is from /etc/rc.d/READme.txt

Cheers,
s
thanks, I just needed to look closer 8)

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#15 Post by PaulBx1 »

Here is a guy who thinks systemd, udisks2 et. al. are turning Linux into Windows:

http://igurublog.wordpress.com/2012/03/ ... mment-5851

I have to say I can see his point (although I am far from being a dev). While I like systemd in arch for fast boot times, my logs are full of errors including failure to umount /var on every shutdown. How to fix them? How the hell do I know?! I am reduced to begging help on the arch newbie board and not getting much luck with that. Systemd is well documented and yet I still don't have the big picture, or the ability to debug these issues. Maybe the answer is that multiple hiccups on shutdown are normal and I should stop worrying about them. Just like Windows.

User avatar
darkcity
Posts: 2534
Joined: Sun 23 May 2010, 19:16
Location: near here
Contact:

#16 Post by darkcity »

haha, I love this quote - reminds me of the economy ; -)
. . . cancer grows too. In fact it grows wildly, haphazardly, and selfishly, often causing its host to die in the end – a culmination of all the ‘rapid growth’.

Post Reply