watchdog: file oberservation during mount at startu & more

You made that sound just like a course work question.

Google on how to setup a service under systemd.

Not a good enough description of the problem, but maybe start with man fstab

Am 29.03.2018 um 00:33 schrieb Andrew Gabriel:

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.

Thanks - Udo

Am 29.03.2018 um 00:33 schrieb Andrew Gabriel:

Ok,

to 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.

Thanks - Udo

On Thu, 29 Mar 2018 12:57:45 +0200, Newdo declaimed the following:

Do you mean:

between application of power and the transfer of control to Linux kernel

or

between the start of the kernel and the production of a login prompt on the system console

or between the start of the kernel and the production of a login prompt on a graphical environment

For the First, you may have to pay Broadcom -- as I recall, Broadcom provides a black-box blob to the R-Pi foundation which is loaded by the graphics processor, and which then sets up the hardware and loads the Linux kernel image into RAM before allowing the ARM processor to start execution. {Many other boards use a customized version of U-Boot which runs on the main processor and gets loaded by code in a small ROM in place of the initial load going to the graphics processor). Don't know if searching the ARM site would reveal generic documentation for configuring a processor boot system (remember: ARM sells processor /designs/, it is up to the chip designer to wrap the processor core with peripherals to provide booting capability).

Second and Third: Study Linux kernel configuration, device tree definitions, and whatever run-level control scheme is in use. Debian based OS have transitioned from Sys-V INIT to systemd (sys-V made sense to me; I glanced at some systemd stuff and was immediately lost -- it was as cryptic as the device tree). The main difference between 2 & 3 is that 2 stops with processes waiting for input on text consoles, while 3 has to load an X-Window environment and start the desktop login process waiting (if it isn't configured to automatically login as a default user).

As somebody mentioned in the grubby subthread below, have a look into /etc/rc.local

Check the meaning of '&' at the end of a command in some command shells.

Have you looked at the Debian Reference documentation,

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:

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:

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.