In search for a inittab entry replacement for systemd

English Install/Boot/Login
#1

DB2 uses this line in /etc/inittab to autostart and monitor DB2 database instances:

fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor Coordinator

This does no longer work with openSUSE standard system with systemd startup because systemd does not use /etc/inittab at all.

Could someone please tell me how to get that functionality with systemd?
I mean, including correct time of first start, respawning, errorhandling with start delays, not starting in runlevel 1, environment, signalhandling, …

I looked at the getty replacement /lib/systemd/system/getty@.service and it looks like a good starting point, But I am lost at the details.
I mean its a long way from

2:2345:respawn:/sbin/mingetty tty2

to

[Unit]
Description=Getty on %I
BindTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target

[Service]
Environment=TERM=linux
ExecStart=-/sbin/agetty %I 38400
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=

# Some login implementations ignore SIGTERM, so we send SIGHUP
# instead, to ensure that login terminates cleanly.
KillSignal=SIGHUP

[Install]
Alias=getty.target.wants/getty@tty1.service
#2

I suggest you look at my blog on systemd and the after.local script. You might get some ideas on what to do there.

systemd and using the after.local script in openSUSE 12.1 - Blogs - openSUSE Forums

Thank You,

#3

On Mon, 21 May 2012 17:16:03 +0000, joba1 wrote:

> Could someone please tell me how to get that functionality with systemd?

As an alternative (or workaround), you could elect to install sysvinit
and use it to start the system.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

#4

Thanks for the suggestions. Not quite what I expected though :slight_smile:

The system currently works just fine with the kernel command init=/sbin/sysvinit
And a one shot after.local isn’t exactly what inittab entries provide.
Good blog post though, should I find out how to generically replace inittab entries I’ll let you know, too.

What I expected was that the authors of systemd or the ones replacing sysvinit with systemd in opensuse have thought about this long ago, written it down somewhere and I am just too stupid to find it - shouldn’t be necessary to reinvent the wheel.

#5

On 2012-05-22 11:46, joba1 wrote:
>
> Thanks for the suggestions. Not quite what I expected though :slight_smile:

Another one: a poster in the mail list solved how to use hylafax, which
also has a line in inittab. The maintainer of hylafax doesn’t think systemd
will ever be supported. (!)

+++····················
Date: Thu, 05 Apr 2012 22:15:07 -0500
From: Steven <>
Cc: opensuse@opensuse.org
Subject: Re: [opensuse] inittab Faxgetty

Figured out a simple cheat fix:

I created a file /etc/systemd/system/faxgetty.service

[Unit]
Description=FaxGetty Start Modem ttyS0
After=getty.target

[Service]
Type=simple
User=root
Group=root
Restart=always
ExecStart=/usr/lib/fax/faxgetty /dev/ttyS0
TimeoutSec=0

[Install]
WantedBy=multi-user.target

Then I setup a cron job at boot it runs systemctl start faxgetty.service

Works perfect
····················+±

> What I expected was that the authors of systemd or the ones replacing
> sysvinit with systemd in opensuse have thought about this long ago,
> written it down somewhere and I am just too stupid to find it -
> shouldn’t be necessary to reinvent the wheel.

Ha! :frowning:

I wrote a bugzilla complaining that the openSUSE official docs do not even
mention systemd, but only systemv. What they did was remove systemv from
the docs.

Chapter 5. Booting and Configuring a Linux System

The systemd maintainer reads the factory mail list, and sometimes
participates. Also the main list. He might answer if you post there.

Also, if DB2 is a package provided by the distro, by all means, put a bugzilla!

Some links I collected:

PaxControlGroups
systemd
tmp-as-tmpfs-for-opensuse

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

#6

Wow Carlos, that is a very good help message. Thank you for nice helpful post.

Thank You,

#7

Ok, problem solved after some fiddling and with the help from the very fast responding and helpful systemd mailinglist people (systemd-devel@lists.freedesktop.org).
And as promised, here is how:

This entry at the end of inittab


fmc:2345:respawn:/opt/ibm/db2/V9.7.4/bin/db2fmcd #DB2 Fault Monitor Coordinator

translates to this systemd service file, given you ignore the unused runlevels 2 and 4 (basically like faxgetty without the default values)

/etc/systemd/system/fmc.service


[Unit]
Description=DB2 Fault Monitor Coordinator
After=getty.target

[Service]
ExecStart=/opt/ibm/db2/V9.7.4/bin/db2fmcd
Restart=always

[Install]
WantedBy=multi-user.target

Now enter this command to activate the service (no cron hack required):


systemctl enable fmc.service

And if you want to get away without reboot, activate it right now (similar to good old telinit q)


systemctl daemon-reload
systemctl start fmc.service

HTH

#8

On 2012-05-23 18:26, joba1 wrote:
>
> Ok, problem solved after some fiddling and with the help from the very
> fast responding and helpful systemd mailinglist people
> (systemd-devel@lists.freedesktop.org).
> And as promised, here is how:

Saved for reference.

> Now enter this command to activate the service (no cron hack required):

The cron hack was used because that line did not work. The service was
activated then, but on next boot the service was dead.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)