Ошибка systemd sysv generator

ошибки, собственно, нет: в /etc/init.d не должно быть никаких каталогов.

точнее, ошибка присутствует в той программе, которая создала эти файлы и каталоги.

такие скрипты должны располагаться в /etc/rc*.d, а не в /etc/init.d/rc*.d.

если эти скрипты вам действительно нужны, попробуйте переместить их — из /etc/init.d/rc0.d в /etc/rc0.d и так далее, а каталоги /etc/init.d/rc*.d — удалите.

только обратите внимание, что это могут быть не файлы, а мягкие ссылки на файлы (symlinks), и, если пути к файлам в этих ссылках указаны не абсолютные, а относительные, то их надо будет исправить после перемещения.

Источник


0

2

Доброго времени суток!

Исходные данные. Наша организация получила несколько десятков HPшных системных блоков. Вроде бы все работали хорошо, но с недавнего времени перестали загружаться сразу несколько машин с одной и той-же проблемой. Решить проблемы сам не в силах, прошу помощи специалистов разбирающихся в Linux.

Перестала загружается ОС. При включении ранее автоматически загружалось ядро generic, сейчас же на чёрном экране в левом верхнем углу циклично моргает нижнее подчеркивание.
Если загружать ядро hardened, то появляется ошибка: [17.695857] systemd-sysv-generator795: [/etc/init.d/cprocsp:4] PID file not absolute. Ignoring.

Так-же пробовал загружать встроенный режим восстановления, сначала ядро generic — выдает сообщение о том, что учетная запись root заблокирована, после нажатия на Enter зависает на этом, дальше больше ничего не происходит. Потом через hardened так-же выходит сообщение о том, что учетная запись root заблокирована, только отсутствуют 4 строки intel_rapl: Found RAPL domain package, core, uncore, dram.

Прошу Вашей помощи, как решить без переустановки ОС.

Liraz Siri — Sat, 2015/11/28 — 11:06 —
8 comments

systemd sysv init compatibility mode is magical. That is in the sense that it tries to handle compatibility with sysv init scripts while you are distracted looking somewhere else.

When it works it works well, but when things break it makes troubleshooting more difficult. Especially if you don’t understand what’s going on behind the curtain.

The first thing you need to understand is that this probably doesn’t do what you expect:

/etc/init.d/sysv-init-script start

In sysv the script would actually be executed. Under systemd the execution is intercepted by LSB here at this line in the script’s execution:

. /lib/lsb/init-functions

This eventually invokes /lib/lsb/init-functions.d/40-systemd which redirects the execution of the script so that it is invoked by systemd.

So instead of executing the script what’s actually happening is this:

systemctl start sysv-init-script.service

sysv-init-script.service doesn’t actually exist so systemd.service handles that as a special case by sort of pretending it does.

From systemd.service(5):

If a service is requested under a certain name but no unit configuration
file is found, systemd looks for a SysV init script by the same name
(with the .service suffix removed) and dynamically creates a service
unit from that script. This is useful for compatibility with SysV. Note
that this compatibility is quite comprehensive but not 100%. For details
about the incompatibilities, see the Incompatibilities with SysV[1]
document.

Long story short, systemd interprets the standard LSB headers in the sysv init script so it execute the sysv init script in the context of something resembling a real systemd service.

Behind the curtain these wrapper service units are generated by /lib/systemd/system-generators/systemd-sysv-generator and you can find the result at /run/systemd/generator.late/ where the wrapper usually looks something like this:

# Automatically generated by systemd-sysv-generator

[Unit]
SourcePath=/etc/init.d/sysv-init-script
Description=LSB: A sysV init script
After=remote-fs.target systemd-journald-dev-log.socket

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/sysv-init-script start
ExecStop=/etc/init.d/sysv-init-script stop

The problem is that when things break it adds a layer of indirection that makes debugging the sysv init script harder.

To disable systemd redirection do this:

export _SYSTEMCTL_SKIP_REDIRECT=1

Now executing your /etc/init.d/sysv-init-script directly will work, and so will shell debugging tricks I find really useful such as:

  1. set -ex

    This echos everything the script executes to stdout and terminates the script if any command returns an error (I.e., a non-zero exitcode).

  2. inserting an interactive /bin/bash shell somewhere to «inspect» the environment. This works kind of like setting a breakpoint.

Note however that systemd is pretty neat once you get past the learning curve. Usually it will make more sense to reimplement your sysv init script as a systemd service unit. You can eliminate hundreds of line of complicated error prone shell script with a handful of lines of systemd configuration directives that work better than the original.

I’ve been troubleshooting an issue with a sysVinit service not coming online properly at boot within a systemd environment. What I’ve found is that when no service file or overrides are present in /etc/systemd/system/ for the said service, it autostarts properly. In this case, as I understand it, systemd should be dynamically loading the startup script via reading «legacy» sysvinit scripts present on the system, although I’m not 100% clear on that.

What I’m confused about is that as soon as I pass the edit —full option to systemctl for said service, a flat file is generated at /etc/systemd/system/ and said service now fails to autostart at boot. Using the edit option and trying to add any overrides also seems to cause the service to fail to boot.

Examples, if needed, provided below…

Example of the system when it works:

The service, in this example called «ProgramExample» has an init script placed in /etc/init.d/programexample and also /etc/rc.d/init.d/programexample:

[root@centos7-box ~]# ls -l /etc/rc.d/init.d/programexample
-rwxr-xr-x. 1 root root 2264 Mar 29 14:11 /etc/rc.d/init.d/programexample

No service file present at /etc/systemd/system/:

[root@centos7-box ~]# ls -lh /etc/systemd/system/programexample.service
ls: cannot access /etc/systemd/system/programexample.service: No such file or directory

Systemctl status output in this configuration:

[root@centos7-box ~]# systemctl status programexample.service
● programexample.service - LSB: Start Program Example at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; bad; vendor preset: disabled)
   Active: active (exited) since Wed 2017-03-29 15:53:06 CDT; 14min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1297 ExecStart=/etc/rc.d/init.d/programexample start (code=exited, status=0/SUCCESS)

Mar 29 15:53:05 centos7-box systemd[1]: Starting LSB: Start ProgramExample at boot time...
Mar 29 15:53:05 centos7-box su[1307]: (to programexample) root on none
Mar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-box
Mar 29 15:53:06 centos7-box programexample[1297]: instance public base uri set to https://192.168.0.148.programexample.net/programexample/
Mar 29 15:53:06 centos7-box programexample[1297]: instance timezone set to US/Central
Mar 29 15:53:06 centos7-box programexample[1297]: starting java services
Mar 29 15:53:06 centos7-box programexample[1297]: ProgEx server started.
Mar 29 15:53:06 centos7-box systemd[1]: Started LSB: Start ProgramExample at boot time.

With the above configuration, without any files created/placed in /etc/systemd/system/, the ProgramExample service autostarts properly.

Once systemctl edit —full (or just edit) is used:

Once any edits are passed to systemctl, I have observed the following:

  • A flat file or an override directory will be placed in /etc/systemd/system/
  • Said service, in this case ProgramExample, fails to start at boot.
  • I will be unable to «enable» said service using systemctl

Systemctl status output in this configuration (post edit):

[root@centos7-box ~]# systemctl status programexample.service
● programexample.service - LSB: Start ProgramExample at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

This is the service file that is being generated and placed in /etc/systemd/system/ when using the -edit —full option:

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/programexample
Description=LSB: Start ProgramExample at boot time
Before=runlevel2.target
Before=runlevel3.target
Before=runlevel4.target
Before=runlevel5.target
Before=shutdown.target
Before=adsm.service
After=all.target
After=network-online.target
After=postgresql-9.4.service
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/programexample start
ExecStop=/etc/rc.d/init.d/programexample stop
ExecReload=/etc/rc.d/init.d/programexample reload

What is happening here? Am I correct that without the flat service file and/or service override directory in /etc/systemd/system/ that systemd is dynamically reading this information from said service’s init script? I’ve tried numerous iterations of editing the service file at /etc/systemd/system/ and leaving the default file in place and cannot get autostarting to work or the service to go into an «enabled» state.

I believe it would be preferable to have a systemd .service file for systemd configurations instead of relying on systemd to read from init script LSB headers for compatibility and concurrency reasons but the default file systemd is creating is failing to start or enable along with numerous other more simple iterations of the .service file I’ve attempted.

I’ve been troubleshooting an issue with a sysVinit service not coming online properly at boot within a systemd environment. What I’ve found is that when no service file or overrides are present in /etc/systemd/system/ for the said service, it autostarts properly. In this case, as I understand it, systemd should be dynamically loading the startup script via reading «legacy» sysvinit scripts present on the system, although I’m not 100% clear on that.

What I’m confused about is that as soon as I pass the edit —full option to systemctl for said service, a flat file is generated at /etc/systemd/system/ and said service now fails to autostart at boot. Using the edit option and trying to add any overrides also seems to cause the service to fail to boot.

Examples, if needed, provided below…

Example of the system when it works:

The service, in this example called «ProgramExample» has an init script placed in /etc/init.d/programexample and also /etc/rc.d/init.d/programexample:

[root@centos7-box ~]# ls -l /etc/rc.d/init.d/programexample
-rwxr-xr-x. 1 root root 2264 Mar 29 14:11 /etc/rc.d/init.d/programexample

No service file present at /etc/systemd/system/:

[root@centos7-box ~]# ls -lh /etc/systemd/system/programexample.service
ls: cannot access /etc/systemd/system/programexample.service: No such file or directory

Systemctl status output in this configuration:

[root@centos7-box ~]# systemctl status programexample.service
● programexample.service - LSB: Start Program Example at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; bad; vendor preset: disabled)
   Active: active (exited) since Wed 2017-03-29 15:53:06 CDT; 14min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1297 ExecStart=/etc/rc.d/init.d/programexample start (code=exited, status=0/SUCCESS)

Mar 29 15:53:05 centos7-box systemd[1]: Starting LSB: Start ProgramExample at boot time...
Mar 29 15:53:05 centos7-box su[1307]: (to programexample) root on none
Mar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-box
Mar 29 15:53:06 centos7-box programexample[1297]: instance public base uri set to https://192.168.0.148.programexample.net/programexample/
Mar 29 15:53:06 centos7-box programexample[1297]: instance timezone set to US/Central
Mar 29 15:53:06 centos7-box programexample[1297]: starting java services
Mar 29 15:53:06 centos7-box programexample[1297]: ProgEx server started.
Mar 29 15:53:06 centos7-box systemd[1]: Started LSB: Start ProgramExample at boot time.

With the above configuration, without any files created/placed in /etc/systemd/system/, the ProgramExample service autostarts properly.

Once systemctl edit —full (or just edit) is used:

Once any edits are passed to systemctl, I have observed the following:

  • A flat file or an override directory will be placed in /etc/systemd/system/
  • Said service, in this case ProgramExample, fails to start at boot.
  • I will be unable to «enable» said service using systemctl

Systemctl status output in this configuration (post edit):

[root@centos7-box ~]# systemctl status programexample.service
● programexample.service - LSB: Start ProgramExample at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

This is the service file that is being generated and placed in /etc/systemd/system/ when using the -edit —full option:

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/programexample
Description=LSB: Start ProgramExample at boot time
Before=runlevel2.target
Before=runlevel3.target
Before=runlevel4.target
Before=runlevel5.target
Before=shutdown.target
Before=adsm.service
After=all.target
After=network-online.target
After=postgresql-9.4.service
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/programexample start
ExecStop=/etc/rc.d/init.d/programexample stop
ExecReload=/etc/rc.d/init.d/programexample reload

What is happening here? Am I correct that without the flat service file and/or service override directory in /etc/systemd/system/ that systemd is dynamically reading this information from said service’s init script? I’ve tried numerous iterations of editing the service file at /etc/systemd/system/ and leaving the default file in place and cannot get autostarting to work or the service to go into an «enabled» state.

I believe it would be preferable to have a systemd .service file for systemd configurations instead of relying on systemd to read from init script LSB headers for compatibility and concurrency reasons but the default file systemd is creating is failing to start or enable along with numerous other more simple iterations of the .service file I’ve attempted.

So systemd-sysv-generator converts old style init.d files into systemd service files. But it might do this before all mounts have been mounted.

I have some legacy commercial software that lives in /opt which is a separate mount point. It creates a symlink from /etc/init.d/their_service to a file in /opt

So when the server boots, systemd-sysv-generator cant yet read the linked file and fails to create a service and thus fails to start the service.

As the legacy software is managed by another team and they have the power to update it themselves, I don’t want to start copying the file out of /opt and replacing the symlink. Or worse, try rewriting this into a systemd service myself.

Is there any way to have systemd-sysv-generator fire after opt.mount?

asked Feb 10, 2017 at 17:32

Slashterix's user avatar

1

One option might be to create a drop-in for their service, that specifies dependencies/order.

For example:

$ sudo mkdir /etc/systemd/system/their_service.service.d
$ sudo vi /etc/systemd/system/their_service.service.d/50-require_mounts.conf
[Unit]
Wants=network.target remote-fs.target
After=network.target remote-fs.target

However, the SysV script could be adapted to sort this problem (https://www.freedesktop.org/software/systemd/man/systemd.special.html):

remote-fs.target
Similar to local-fs.target, but for remote mount points.

systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the «$remote_fs» facility.

answered Mar 16, 2017 at 9:15

iwaseatenbyagrue's user avatar

1

Thanks to the hint from iwaseatenbyagrue to read https://www.freedesktop.org/software/systemd/man/systemd.special.html I found this section

initrd-fs.target

systemd-fstab-generator(3) automatically adds dependencies of type Before= to sysroot-usr.mount and all mount points found in /etc/fstab that have x-initrd.mount and not have noauto mount options set.

So my fix was to do the following

  1. Edit /etc/fstab to have the x-initrd.mount option for my /opt mount point

/dev/mapper/rootvg-opt /opt ext4 nodev,x-initrd.mount 0 0

  1. Edit /etc/default/grub to list the extra mount point in GRUB_CMDLINE_LINUX

GRUB_CMDLINE_LINUX=»rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rd.lvm.lv=rootvg/usr rd.lvm.lv=rootvg/opt ipv6.disable=1 rhgb quiet»

  1. Rebuild the boot

grub2-mkconfig -o /boot/grub2/grub.conf

dracut -f

These steps combined cause SystemD to correctly mount /opt early in the boot and succeed with systemd-sysv-generator

Community's user avatar

answered Mar 24, 2017 at 23:04

Slashterix's user avatar

SlashterixSlashterix

6121 gold badge5 silver badges19 bronze badges

systemd version the issue has been seen with

239 (+SYSVINIT)

Used distribution

Fedora 29

Expected behaviour you didn’t see

SysV init service of 3rd party RPM (Apache Cassandra) works fine on CentOS 7 but not on latest Fedora.

Unexpected behaviour you saw

Unable to manage specific SysV service on Fedora.

Steps to reproduce the problem

I’ve installed latest Apache Cassandra 3.11.3 RPM from cassandra.apache.org (because it’s the version we use on CentOS and it’s newer than the version in Fedora repos).
Apache Cassandra RPM doesn’t include systemd service as it has only SysV init script. Proper systemd service would resolve this issue but following case might be interesting one for backward compatibility (if it’s cared).

(IMHO probably because) SysV service manages pid file on its own, it colides with the «systemd-sysv-generator» generated pid file (?) and causes:

systemd[1]: Starting LSB: distributed storage system for structured data...
su[20314]: (to cassandra) root on none
su[20314]: pam_unix(su:session): session opened for user cassandra by (uid=0)
su[20314]: pam_unix(su:session): session closed for user cassandra
cassandra[20300]: Starting Cassandra: OK
systemd[1]: cassandra.service: New main PID 20438 does not belong to service, and PID file is not owned by root. Refusing.
systemd[1]: cassandra.service: New main PID 20438 does not belong to service, and PID file is not owned by root. Refusing.
systemd[1]: cassandra.service: Failed with result 'protocol'.
systemd[1]: Failed to start LSB: distributed storage system for structured data.

This prevents me from stopping or viewing status of this service using systemctl, service or even with /etc/rc.d/init.d/cassandra status as all are wrapped by systemd.

SysV service that sets and works with pid_file=/var/run/cassandra/cassandra.pid: https://github.com/apache/cassandra/blob/cassandra-3.11.3/redhat/cassandra

PID:

$ ll /var/run/cassandra/cassandra.pid 
-rw-------. 1 cassandra cassandra 5 21. lis 12.04 /var/run/cassandra/cassandra.pid

Systemd generated service:

$ systemctl cat cassandra
# /run/systemd/generator.late/cassandra.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/cassandra
Description=LSB: distributed storage system for structured data
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
After=nss-lookup.target
After=time-sync.target
After=ntp.service
After=mdadm.service
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=no
PIDFile=/var/run/cassandra/cassandra.pid
SuccessExitStatus=5 6
ExecStart=/etc/rc.d/init.d/cassandra start
ExecStop=/etc/rc.d/init.d/cassandra stop
ExecReload=/etc/rc.d/init.d/cassandra reload

So I am trying to start a service on systemd enabled system. Name of service is ossec-hids-authd which is the authentication engine(agents) in ossec(Intrusion Detection Software). When I go and start the init script then systemctl times out and on getting the status I am seeing this error.

/etc/init.d/ossec-hids-authd status
● ossec-hids-authd.service - LSB: Authentication Daemon for OSSEC-HIDS.
   Loaded: loaded (/etc/rc.d/init.d/ossec-hids-authd; bad; vendor preset: disabled)
   Active: failed (Result: timeout) since Thu 2018-02-22 07:34:28 UTC; 11min ago
     Docs: man:systemd-sysv-generator(8)

Feb 22 07:24:11 ip-10-0-197-117.ec2.internal systemd[1]: Starting LSB: Authentication Daemon for OSSEC-HIDS....
Feb 22 07:24:11 ip-10-0-197-117.ec2.internal ossec-hids-authd[21142]: [39B blob data]
Feb 22 07:24:11 ip-10-0-197-117.ec2.internal systemd[1]: PID file /var/run/ossec-authd.pid not readable (yet?) after start.
Feb 22 07:24:11 ip-10-0-197-117.ec2.internal ossec-hids-authd[21142]: 2018/02/22 07:24:11 ossec-authd: INFO: Started (pid: 21148).
Feb 22 07:34:28 ip-10-0-197-117.ec2.internal systemd[1]: ossec-hids-authd.service start operation timed out. Terminating.
Feb 22 07:34:28 ip-10-0-197-117.ec2.internal systemd[1]: Failed to start LSB: Authentication Daemon for OSSEC-HIDS..
Feb 22 07:34:28 ip-10-0-197-117.ec2.internal systemd[1]: Unit ossec-hids-authd.service entered failed state.
Feb 22 07:34:28 ip-10-0-197-117.ec2.internal systemd[1]: ossec-hids-authd.service failed.
Feb 22 07:40:20 ip-10-0-197-117.ec2.internal ossec-hids-authd[21142]: 2018/02/22 07:40:20 ossec-authd(1225): INFO: SIGNAL [(15)-(Terminated)] Received. Exit Cleaning...

Now in the init script this process is actually making pid file in /var/ossec/var/run instead of /var/run and I checked pid file is actually created there. But somehow systemctl is failing to recognize it.

Is it possible that systemd does not recognize pid files created outside of /var/run and if such is the case how to do that?

Below is the init script 

#!/bin/sh
#
# ossec-authd  Start the OSSEC-HIDS Authentication Daemon
#
# chkconfig: 2345 99 01
# description: Provides key signing for OSSEC Clients
# processname: ossec-authd
# config: /var/ossec/etc/ossec.conf
# pidfile: /var/run/ossec-authd.pid
### BEGIN INIT INFO
# Provides:          ossec-authd
# Required-Start:    $network $local_fs $remote_fs
# Required-Stop:     $network $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Authentication Daemon for OSSEC-HIDS.
# Description:       Provides key signing for OSSEC Clients
### END INIT INFO

# Author: Brad Lhotsky <brad.lhotsky@gmail.com>
NAME=ossec-authd
DAEMON=/var/ossec/bin/ossec-authd
DAEMON_ARGS="-p 1515 2>&1 >> /var/ossec/logs/ossec-authd.log &"
PIDDIR=/var/ossec/var/run
SCRIPTNAME=/etc/init.d/ossec-authd

. /etc/rc.d/init.d/functions

getpid() {
    for filename in $PIDDIR/${NAME}*.pid; do
        pidfile=$(basename $filename)
        pid=$(echo $pidfile |cut -d- -f 3 |cut -d. -f 1)
        kill -0 $pid &> /dev/null
        RETVAL=$?
        if [ $RETVAL -eq 0 ]; then
            PIDFILE=$filename
            PID=$pid
        else
            rm -f $filename
        fi;
    done;
}

start() {
  echo -n $"Starting $NAME: "
  daemon $DAEMON $DAEMON_ARGS
  retval=$?
  if [ $retval -eq 0 ]; then
    echo_success
    echo
  else
    echo_failure
    echo
  fi
  return $retval
}

stop() {
  echo -n $"Stopping $NAME: "
  getpid
  killproc -p $PIDFILE $NAME
  retval=$?
  echo
  return $retval
}

restart() {
  stop
  start
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  status)
    getpid
    if [ -z $PIDFILE ]; then
        status $NAME
    else
        status -p $PIDFILE $NAME
    fi;
    ;;
  restart)
    restart
    ;;
  *)
    echo "Usage: $0 {start|stop|status}"
    exit 2
    ;;
esac

exit $?

asked Feb 22, 2018 at 8:05

shivams's user avatar

systemd parses an init script’s comments to generate temporary .service file at boot or upon daemon-reload command. Change the line

# pidfile: /var/run/ossec-authd.pid

to

# pidfile: /var/ossec/var/run/ossec-authd.pid

and run systemctl daemon-reload

UPD: now I see that pid file name is generated by authd at runtime and init script has to search for $PIDDIR/${NAME}*.pid.

Systemd can not search for pidfile, but can work without it. Sou you may try to remove # pidfile: line completely, or write your own .service file

answered Feb 22, 2018 at 8:39

WhiteWind's user avatar

WhiteWindWhiteWind

3241 silver badge7 bronze badges

0

All of that is totally unnecessary.

The behaviour of systemd-sysv-generator with a van Smoorenburg rc script that has both the old RedHat comment headers and the LSB headers is interesting, but pointless to spend your time on.

Don’t waste your time fixing your van Smoorenburg rc script and trying to get the PID files to work. You do not actually need the rickety and dangerous PID file mechanism in the first place with proper service management. Nor do you need wrappers like ossec-control. Forget about all that and make yourself a systemd service unit.

Two simple template service units for two different categories of OSSEC services, according to whether an -f option is necessary, are in the answers listed as further reading here. Adapt one or both of them.

Further reading

  • https://askubuntu.com/a/624871/43344
  • https://unix.stackexchange.com/a/200365/5132
  • How does systemd use /etc/init.d scripts?

answered Feb 22, 2018 at 18:31

JdeBP's user avatar

JdeBPJdeBP

64.5k12 gold badges155 silver badges332 bronze badges

1

Hello CentOS List,

I have a server that has SysV script supplied by a hardware manufacturer, which is not functioning properly. From my reading, systemd-sysv-generator should handle them (like it did for Dell OpenManage software which supplied SysV init scripts).

/usr/lib/systemd/system-generators/systemd-sysv-generator Takes no or 3 arguments (it tells me), but I didn’t find clear documentation on this binary. And no arguments doesn’t seem to fix the issue.

The particular software in question is LSI MegaRaid SNMP daemon. I retrieved the latest version from LSI’s site which was provided for EL7.

~]# systemctl lsi_mrdsnmpd.service start Unknown operation ‘lsi_mrdsnmpd.service’.

~]# service lsi_mrdsnmpd start Reloading systemd: [ OK ]
Starting lsi_mrdsnmpd (via systemctl): Failed to start lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such file or directory.
[FAILED]

~]# /etc/init.d/lsi_mrdsnmpd start Reloading systemd: [ OK ]
Starting lsi_mrdsnmpd (via systemctl): Failed to start lsi_mrdsnmpd.service: Unit lsi_mrdsnmpd.service failed to load: No such file or directory.
[FAILED]

~]# /etc/init.d/lsi_mrdsnmpd status lsi_mrdsnmpagent is stopped

~]# ls -1 /etc/init.d/
dataeng dsm_om_connsvc dsm_om_shrsvc dsm_sa_ipmi functions instsvcdrv lsi_mrdsnmpd netconsole network racsvc racsvc.sh README

# in /etc/init.d/README
“Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.”

~]# ls -1 /etc/rc.d/init.d/
dataeng dsm_om_connsvc dsm_om_shrsvc dsm_sa_ipmi functions instsvcdrv lsi_mrdsnmpd netconsole network racsvc racsvc.sh README

Thoughts as to why systemd didn’t “implicitly” handle this SysV script (and have it work)?

Suggestions as to where I go from here to properly solve this problem?

Thanks!

Источник


0

2

Доброго времени суток!

Исходные данные. Наша организация получила несколько десятков HPшных системных блоков. Вроде бы все работали хорошо, но с недавнего времени перестали загружаться сразу несколько машин с одной и той-же проблемой. Решить проблемы сам не в силах, прошу помощи специалистов разбирающихся в Linux.

Перестала загружается ОС. При включении ранее автоматически загружалось ядро generic, сейчас же на чёрном экране в левом верхнем углу циклично моргает нижнее подчеркивание.
Если загружать ядро hardened, то появляется ошибка: [17.695857] systemd-sysv-generator795: [/etc/init.d/cprocsp:4] PID file not absolute. Ignoring.

Так-же пробовал загружать встроенный режим восстановления, сначала ядро generic — выдает сообщение о том, что учетная запись root заблокирована, после нажатия на Enter зависает на этом, дальше больше ничего не происходит. Потом через hardened так-же выходит сообщение о том, что учетная запись root заблокирована, только отсутствуют 4 строки intel_rapl: Found RAPL domain package, core, uncore, dram.

Прошу Вашей помощи, как решить без переустановки ОС.

Источник

I’ve been troubleshooting an issue with a sysVinit service not coming online properly at boot within a systemd environment. What I’ve found is that when no service file or overrides are present in /etc/systemd/system/ for the said service, it autostarts properly. In this case, as I understand it, systemd should be dynamically loading the startup script via reading «legacy» sysvinit scripts present on the system, although I’m not 100% clear on that.

What I’m confused about is that as soon as I pass the edit —full option to systemctl for said service, a flat file is generated at /etc/systemd/system/ and said service now fails to autostart at boot. Using the edit option and trying to add any overrides also seems to cause the service to fail to boot.

Examples, if needed, provided below…

Example of the system when it works

The service (on Centos), in this example called «ProgramExample» has an init script placed in /etc/init.d/programexample and also /etc/rc.d/init.d/programexample:

# ls -l /etc/rc.d/init.d/programexample
-rwxr-xr-x. 1 root root 2264 Mar 29 14:11 /etc/rc.d/init.d/programexample

No service file present at /etc/systemd/system/:

# ls -lh /etc/systemd/system/programexample.service
ls: cannot access /etc/systemd/system/programexample.service: No such file or directory

Systemctl status output in this configuration:

# systemctl status programexample.service
● programexample.service - LSB: Start Program Example at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; bad; vendor preset: disabled)
   Active: active (exited) since Wed 2017-03-29 15:53:06 CDT; 14min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1297 ExecStart=/etc/rc.d/init.d/programexample start (code=exited, status=0/SUCCESS)

Mar 29 15:53:05 centos7-box systemd[1]: Starting LSB: Start ProgramExample at boot time...
Mar 29 15:53:05 centos7-box su[1307]: (to programexample) root on none
Mar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-box
Mar 29 15:53:06 centos7-box programexample[1297]: instance public base uri set to https://192.168.0.148.programexample.net/programexample/
Mar 29 15:53:06 centos7-box programexample[1297]: instance timezone set to US/Central
Mar 29 15:53:06 centos7-box programexample[1297]: starting java services
Mar 29 15:53:06 centos7-box programexample[1297]: ProgEx server started.
Mar 29 15:53:06 centos7-box systemd[1]: Started LSB: Start ProgramExample at boot time.

With the above configuration, without any files created/placed in /etc/systemd/system/, the ProgramExample service autostarts properly.

Once systemctl edit --full (or just edit) is used:

Once any edits are passed to systemctl, I have observed the following:

  • A flat file or an override directory will be placed in /etc/systemd/system/
  • Said service, in this case ProgramExample, fails to start at boot.
  • I will be unable to «enable» said service using systemctl

Systemctl status output in this configuration (post edit):

# systemctl status programexample.service
● programexample.service - LSB: Start ProgramExample at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

This is the service file that is being generated and placed in /etc/systemd/system/ when using the edit --full option:

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/programexample
Description=LSB: Start ProgramExample at boot time
Before=runlevel2.target
Before=runlevel3.target
Before=runlevel4.target
Before=runlevel5.target
Before=shutdown.target
Before=adsm.service
After=all.target
After=network-online.target
After=postgresql-9.4.service
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/programexample start
ExecStop=/etc/rc.d/init.d/programexample stop
ExecReload=/etc/rc.d/init.d/programexample reload

What is happening here? Am I correct that without the flat service file and/or service override directory in /etc/systemd/system/ that systemd is dynamically reading this information from said service’s init script? I’ve tried numerous iterations of editing the service file at /etc/systemd/system/ and leaving the default file in place and cannot get autostarting to work or the service to go into an «enabled» state.

I believe it would be preferable to have a systemd .service file for systemd configurations instead of relying on systemd to read from init script LSB headers for compatibility and concurrency reasons but the default file systemd is creating is failing to start or enable along with numerous other more simple iterations of the .service file I’ve attempted.

Источник

When I do «systemctl daemon-reload» I get these lines in my logs:
systemd[1]: Reloading.
systemd-sysv-generator[]: Out of memory.
systemd-sysv-generator[]: Out of memory.

But I can’t really figure out where it’s coming from or why.
This issue has been with me on several of my Debian servers since I upgraded from 10 to 11.
But it’s not there on a fresh install.

Is there any way that I can debug/trace what’s happening when these errors appear to get a more detailed log output on what’s actually failing ?

I doubt this is a bug. It’s just a help request.

Thanks =)

— systemd —version
systemd 247 (247.3-7)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified

— uname -a
Linux 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux

— lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

— free -h
total used free shared buff/cache available
Mem: 3.8Gi 566Mi 124Mi 155Mi 3.2Gi 2.9Gi
Swap: 2.0Gi 73Mi 1.9Gi

Источник

  • Ошибка system86 dll для medal of honor
  • Ошибка system32 hal dll
  • Ошибка system32 gamingtcui dll
  • Ошибка system на телефоне
  • Ошибка system на андроиде как исправить