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