On Thu, 29 Mar 2018 12:57:12 +0200, Newdo wrote:

> Am 29.03.2018 um 00:33 schrieb Andrew Gabriel:
>> Not a good enough description of the problem, but maybe start with
>
> Ok,
>
> the refine the question:
>
> Where can information about the complete boot process be found?
>
> What i am searching for is the sequence of initialisation, staring of
> services and other things being performed before any login occurs and
> -finally- when a user islogging in.
>
> I try to find out where and how to place my own basic services for
> background processing. Some of them rely on other prerequisites such as
> mounted ramdisks etc.
>
> Which logs are written by whom at which part of the boot process is also
> very interesting.
>
Have you looked at the Debian Reference documentation,

http://www.debian.org/doc/manuals/debian-reference/

If you need to know about stuff that happens after the Linux kernel is
booted and controlling the startup process, this would be as as good a
starting point as any, especially when combined with the systemd
documentation. About the best documentation set I've found is here:

https://www.freedesktop.org/wiki/Software/systemd/

The main problems with systemd are that Poettering and his crew seem
unable to stop mucking around with it and are fairly careless about code
quality, testing and documentation. However, that's old news which became
obvious way back when they bollixed up Gnome 2 before getting bored and
starting to work on Gnome 3 without tidying up unfinished business on
Gnome 2.

Much more recently they managed to stuff up the logging daemon, which is
now, apparently, part of systemd. A version got put live on the Fedora
distro that screwed up mail system logging levels for Postfix and spamd:
24 hours after a reboot the log levels changed so that all message
related mail info-level logging just stopped. Fortunately somebody kicked
their goolies good and hard over that, because fixes appeared, but not in
a very timely fashion.

I don't like this approach: the best part of the UNIX philosophy is that
each program should do one thing and do it well, which also makes
maintenance easier. We already have one giant all seeing, all dancing
monolithic mishmash, the kernel, and don't need another.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05