-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Andrew. One more problem solved, as I discovered last thing yesterday there was a missing "[Install]". Using your copy of the httpd service I cut-and-pasted it onto the end of the service file you'd given me earlier and at last was able to load the service. It wouldn't run, but at least it was some progress. I ran systemctl daemon-reload and rebooted. It is still failing though: # systemctl status timidity timidity.service - timidity daemon Loaded: loaded (/etc/systemd/system/timidity.service; enabled) Active: failed (Result: exit-code) since Sat ... Process: 955 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=1/FAILURE) Process: 790 ExecStart=/usr/bin/timidity -iAD (code=exited, status=0/SUCCESS) Main PID: 790 (code=exited, status=0/SUCCESS) CGroup: /system.slice/timidity.service ...systemd[1]: Started timidity daemon. ...kill[955]: Usage: ...kill[955]: kill [options] <pid|name> [...] (standard help message ommited) ...kill[955]: For more details see kill(1). ...systemd[1]: timidity.service: control process exited, code=exited status=1 ...systemd[1]: Unit timidity.service entered failed state. Again, I'm wondering if systemd is not passing on the options when it execs the daemon. This was, I think, the problem with the original init script. There's certainly something weird going on: Status code from sysctl start 0 (success) Status code from ExecStart 0 (success) Status code from "Main PID" 0 (success) So I assume the daemon is being successfully started. Status code from "Active" failed Status code from systemd[1] control process exited, code=exited status=1 Turning now to the location. I've been working in /etc/systemd/user, and after that failed in /etc/systemd/system. Are you suggesting that site customisations ought to be in /usr/lib/systemd/system? I would normally regards /usr/lib as fairly sacrosanct. I don't have a copy of the LSB to hand but I think that area is meant to normally be off limits to sysadmins. My next line of attack is to beef up the audit tral and see if I can pick up the suspect exec. Any other suggestions welcome! On 04/04/15 09:29, Andrew Holway wrote: > Thats wierd. I've never had any problem with systemctl or systemd > like that. > > Do you have your service file in the right place with the right > permissions. here is the httpd service file as a reference. > > > [centos at ipa ~]$ ls /usr/lib/systemd/system/httpd.service -l > > -rw-r--r--. 1 root root 694 Mar 12 14:57 > /usr/lib/systemd/system/httpd.service > > > [centos at ipa ~]$ cat /usr/lib/systemd/system/httpd.service > > [Unit] > > Description=The Apache HTTP Server > > After=network.target remote-fs.target nss-lookup.target > > > [Service] > > Type=notify > > EnvironmentFile=/etc/sysconfig/httpd > > ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND > > ExecReload=/usr/sbin/httpd $OPTIONS -k graceful > > ExecStop=/bin/kill -WINCH ${MAINPID} > > KillSignal=SIGCONT > > PrivateTmp=true > > > [Install] > > WantedBy=multi-user.target > > > > On 4 April 2015 at 00:07, J Martin Rushton > <martinrushton56 at btinternet.com> wrote: > > Yet more information: > > As a test I moved the link > /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service into > /etc/systemd/user and reran systemctl daemon-reload. I then > rebooted. > > # ls -l /etc/systemd/user total 4 lrwxrwxrwx. 1 root root 41 Jul > 27 2014 dbus-org.fedoraproject.FirewallD1.service -> > /usr/lib/systemd/system/firewalld.service -rwxr-x---. 1 root root > 246 Apr 3 21:21 timidity.service # systemctl status > dbus-org.fedoraproject.FirewallD1.service > dbus-org.fedoraproject.FirewallD1.service Loaded: not-found > (Reason: No such file or directory) Active: inactive (dead) > > # systemctl status timidity timidity.service Loaded: not-found > (Reason: No such file or directory) Active: inactive (dead) > > So it's starting to look like a distro problem. Next I moved both > the Firewall service link and the timidity service file into > /etc/systemd/system: > > # systemctl daemon-reload # echo $? 0 > > and rebooted. > > # systemctl status dbus-org.fedoraproject.FirewallD1.service > firewalld.service - firewalld - dynamic firewall daemon Loaded: > loaded (/usr/lib/systemd/system/firewalld.service; enabled) Active: > active (running) since Fri 2015-04-03 22:50:50 ... Main PID: 785 > (firewalld) CGroup: /system.slice/firewalld.service └─785 > /usr/bin/python -Es /usr/sbin/firewalld ... > > ... Starting firewalld - dynamic firewall daemon... ... Started > firewalld - dynamic firewall daemon. # systemctl status timidity > timidity.service - timidity daemon Loaded: loaded > (/etc/systemd/system/timidity.service; static) Active: inactive > (dead) > > Which is progress, but where to I'm not sure. > > # ls -ld system user drwxr-xr-x. 14 root root 4096 Apr 3 22:48 > system drwxr-xr-x. 2 root root 4096 Apr 3 22:48 user # getfacl > system user # file: system # owner: root # group: root user::rwx > group::r-x other::r-x > > # file: user # owner: root # group: root user::rwx group::r-x > other::r-x > > Clearly there is a problem with my assumption about the default > settings. systemd appears not to read the user directory without > modification. > > Trying to enable it leads to: > > # systemctl enable timidity The unit files have no [Install] > section. They are not meant to be enabled using systemctl. Possible > reasons for having this kind of units are: 1) A unit may be > statically enabled by being symlinked from another unit's .wants/ > or .requires/ directory. 2) A unit's purpose may be to act as a > helper for some other unit which has a requirement dependency on > it. 3) A unit may be started when needed via activation (socket, > path, timer, D-Bus, udev, scripted systemctl call, ...). > > Ah well, bed time. I'll tussle with Poettering's logic in the > morning. >> _______________________________________________ CentOS mailing >> list CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> > _______________________________________________ CentOS mailing > list CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVH+05AAoJEAF3yXsqtyBlDTUQAMJPiZpKiJsDPQ/LXAzBUb8M k2+qnFCuKuBT5JVzttBGbm9YiNzIrn5A0X1TP7mSzZhJMr4DX4LbRJfnuBYP7mm7 vRBixpbCZ+/un6oEudtoVt7EuEvR/MENQYf/CVbZRGarG+9CS0fecjKLNi+G6ltZ ySe4t1wHtvaZ1ujMpN7w30++CbV1DPyF0yGNQvaf8yI6uGZSTSRDd0mQ/aRkLTw1 peYW1pGBtagvltIbY3vjTneFJ5UB4yQymnvZuCCrujlsc0ccMaWCbgLEuxxxLWoQ Lx//TegR1OTdDjb2yk8VWMQuUQzh5hBssrH2q2dTp+mBql8Ws8zNHwe/WdczM6Ti llPpafWpe1ZUKNevnY3Fe2Tem3W5w3S4KumFeR9Xu6tBLlDRXoTssbN59EfVS4wg J03z4xfKsCqP2BrlHgi0C5qWdZGC+aU6oFrMCetCForhP10zhdkoQLGJy4UTWYMS ja29I0LHTjLAtaRdD7N8bsCf9bY3t29v5nqlmXtC5mWHwwDyv7MLftDw1X9aJElv I/rcKEGcKBGlSH3IafgzbcriVZwK90NcskcpJX366qJTMb0/pMjkgV2Iu3Ki7/Ex DKg5o5/NxxqiJQz2etAKvP9Xgkn5svlQCj2n3filwgC3l1ePpGoG+056396PI1dj FxEhkVUZgUnrioH6g6ds =4Q/J -----END PGP SIGNATURE-----