systemd direcotry in /etc

[Member russellb23]

Hi fellow antiX users,

I have switched to antix recently (6 months). I have been enjoying the stability of debian without the ‘systemd’. Last night, I have found a directory /etc/systemd and from the initial inspection, although systemd is not running, it has directories, namely ‘graphical.target.wants, multi-user.target.wants, timer.target.wants’. I am investigating what it does and why is there on the first place while antix being an non-systemd distribution.

If an experienced antix user could shed some light on this that would be really helpful? I am taking it as something important to look immediately.

• This topic was modified 4 years, 1 month ago by russellb23.

Attachments:

1. 

   etc_systemd.jpg
   

2. 

   etc_systemd-1.jpg
   

entropy

[Anonymous]

Helpful

Up

0

::

snipped from the top websearch result for “/etc/systemd/systemd directory”

freedesktop.org/…/man/systemd.unit.html

A unit file is a plain text ini-style file that encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a watched file system path, a timer controlled and supervised by systemd(1), a resource management slice or a group of externally created processes.

. . .

Load path when running in system mode:

/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system {—- Local configuration
/run/systemd/system {—— Runtime units
/run/systemd/generator
/usr/local/lib/systemd/system {——- Units of installed packages
/usr/lib/systemd/system
/run/systemd/generator.late Generated units with low priority (see late-dir in systemd.generator(7))

Various debian packages will install these in case systemd is used on a system, or with the expectation that systemd will be used. On an antiX system, the config and unit files residing in the /etc/systemd/system directory “do nothing, are not used” by the operating system. However, deleting them is inadvisable b/c some applications test the (expected) presence of their associated unit or config file at each launch & may chirp if those files (placed during installation of the application’s package) are absent.

[Member russellb23]

Helpful

Up

0

::

Thanks for helping. But, have a doubt. If the presence of these files are required for the proper functioning, doesn’t that mean antix requires systemd? Could we do something about the packages that require this condition?

Thanks once again for the response.

entropy

[Anonymous]

Helpful

Up

0

::

I have explained why your concern is unwarranted. Another of my online personas is ‘kriv’, a longstanding contributor toward maintaining the without-systemd.org wiki, so I reckon my explanation is well qualified.

Repackaging and/or carving the source code of individual applications soley with the intent of “weeding out, stamping out service files” (you’ve likely never done so, can’t appreciate how time-intensive the chore can be) represents extensive and needless busywork.

[Anonymous]

Helpful

Up

0

::

.

[Forum Admin dolphin_oracle]

Helpful

Up

0

::

russellb23 wrote:

Thanks for helping. But, have a doubt. If the presence of these files are required for the proper functioning, doesn’t that mean antix requires systemd? Could we do something about the packages that require this condition?

Thanks once again for the response.

You proceed from a false assumption, padawan. The files aren’t always needed. The files in /etc/systemd are analogous to the init.d scripts and runlevels directories that sysVinit uses. On a systemd system, the sysVinit stuff is still installed as well for those particular packages. In effect, the developers of that application try to support both init systems, which is good for us.

So on a systemd system, the sysVinit stuff isn’t needed, and on a sysVinit system, the systemd stuff is ignored.

clarification…systemd will actually try to use sysVinit init scripts for services if those services don’t already have systemd unit configurations. Mostly, sort of.

[Author]

Posts