-----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@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@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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
>>
> _______________________________________________ CentOS mailing
> list CentOS@xxxxxxxxxx
> 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-----
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
