How to debug old initd script under systemd?

Question

I have an older initd script to start my application. It worked fine under older versions of SuSE, but fails on Open SuSE 12.3.

The strange thing is

cd /etc/init.d ; ./script start

works fine.

/etc/init.d/script start

shows a redirection to systemctl, but doesn't start my application (and also doesn't show any output from the initd script).

I don't see any log entries showing me what goes wrong. The only entry I see is in /var/log/messages saying the application was started.

How do I debug this ?

check this out http://0pointer.de/blog/projects/systemd-for-admins-3.html — Alex, Oct 28 '13 at 14:20

score 2 · Answer 1 · answered Oct 04 '16 at 17:16

A couple of things.

Run the command with a clean environment:

env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin /etc/init.d/SCRIPT start

Second, turn on shell debugging. One simple way to do this is with:
```
bash -x SCRIPT start
```

combining the two, you get:

    env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin bash -x /etc/init.d/SCRIPT start

Disable systemd's compatibility mode with:
```
SYSTEMCTL_SKIP_REDIRECT=true
```

The name of this variable might vary. Your init script probably includes something like

    . /etc/sysconfig/functions

That file will check on the above environment variable. (Suse is a bit different than it's RedHat based cousins, so YMMV).

Combining all the above:

env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin SYSTEMCTL_SKIP_REDIRECT=true  \
bash -x /etc/init.d/SCRIPT start

Finally, since the output will be voluminous, append the following:

2>&1 | less -r +F

The less program will buffer the output allowing you to scroll back the entire history. Hit CTRL-C to exit it's "follow" mode do be able to scroll back, etc.

score 1 · Accepted Answer · answered Oct 28 '13 at 17:27

The reason why the script has this behaviour is that OpenSuse 12.3 has replaced the old sysvinit with systemd, a system management daemn which controls the whole boot process.

The format of script describing services to be started by systemd differs from that of sysvinit, so it is little wonder that your script fails. Once the script is properly set up, its operation via systemctl is trivial:

sudo systemctl enable/disable your-service

enables or disables it, and typically

sudo systemctl start/stop/status your-service

starts it, stops it, inquiries after its status.

A typical custom service script is located in the folder /etc/systemd/system, ends with the suffix .service, and has this format:

 [Unit]
 Description=sdbarker.com Chiliproject
 Requires=mysqld.service nginx.service
 Wants=mysqld.service nginx.service

 [Service]
 User=www-data
 WorkingDirectory=/path/to/chiliproject/install
 ExecStart=/usr/bin/bundle 
 PIDFile=/path/to/chiliproject/install/tmp/pids/server.pid

 [Install]
 WantedBy=multi-user.target

As you can see, most entries are self-explanatory. Without knowing more about your script I cannot provide further assistance, but you will find in this Arch Linux Wiki page the info you need to write a proper custom service script.

score 0 · Answer 3 · answered Oct 28 '13 at 15:36

0

Most probably there is a relative path inside /etc/init.d/script that it's not relevant outside /etc/init.d/. You could put the contents of the script here (unless is really huge).

Make sure that any arguments you send to your application do not contain relative paths, since the application's working dir is the one where it is started.

answered Oct 28 '13 at 15:36

Mihai

156
6

Its not a relavive paths. It has to do with the fact that its a shell script thats being started that conatins a never ending loop. – Gene Vincent Oct 28 '13 at 16:12

How to debug old initd script under systemd?

3 Answers3