-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVHw8xAAoJEAF3yXsqtyBlieQP/3to6d4gqWZ1HQkTvwKwgSBf Mg3GM6R+10E8skhHEuwAe8uX3ZznbO4F7NOMy3yRBSrL+y/fu6+U8To7T6wLvGKC kFbdCbWradLP31clWzVjJYVVYIUXTVpMC6u59L5IFbYzIB//KShYC7NxDAtQ17qG sbi82BuJRlXgF44cPnkv1LVX8OajUa6d2bppwrpZFNFQyAl3OUa7KY8rqe03kvWm AxAXtHB/E72rHGG7RpdvdwkOJ4FEyxMjh1rzilVBmpuZPLGzfjJhX5ColKvmq34N pABaBSFZeBQw/yk0KRt1eff/CBPR7pMTinxJPKuoVhbUXfJQ9yNcgXcWUg/R23+9 DfJBYwSCAYqvdKwKx7V/1kuQD/INvQiO3NtCc9Ck4cPj1b6udCjsImof07smy7jn xe4q0mh4u7bx76gQQAq/4IQBBp5O8KkjK5oHt4gU2psqFLlSzvRen+fnqsDH2LaN HvjOAWlxS40a5+GAcXkIk9qG9kzAV6lyNvG/lPrSQHyeitjGwClAJTwHBfWI7l0e NuW216klW6VZP6Wm35nEAL7EZV4ADzLH2pqsOxB8dR7KdHAVq1Wwxe5XTi8cWJ8J s4c2vT6uVpthpzGSbdEMoQla/DVp+h56vl2fFeY5Fww2MhODu7CmkUI2P7pvgKXy icO1B4BtoxgV4dEXuHMK =v3W6 -----END PGP SIGNATURE-----
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJVHw8xAAoJEAF3yXsqtyBlieQP/3to6d4gqWZ1HQkTvwKwgSBf
> Mg3GM6R+10E8skhHEuwAe8uX3ZznbO4F7NOMy3yRBSrL+y/fu6+U8To7T6wLvGKC
> kFbdCbWradLP31clWzVjJYVVYIUXTVpMC6u59L5IFbYzIB//KShYC7NxDAtQ17qG
> sbi82BuJRlXgF44cPnkv1LVX8OajUa6d2bppwrpZFNFQyAl3OUa7KY8rqe03kvWm
> AxAXtHB/E72rHGG7RpdvdwkOJ4FEyxMjh1rzilVBmpuZPLGzfjJhX5ColKvmq34N
> pABaBSFZeBQw/yk0KRt1eff/CBPR7pMTinxJPKuoVhbUXfJQ9yNcgXcWUg/R23+9
> DfJBYwSCAYqvdKwKx7V/1kuQD/INvQiO3NtCc9Ck4cPj1b6udCjsImof07smy7jn
> xe4q0mh4u7bx76gQQAq/4IQBBp5O8KkjK5oHt4gU2psqFLlSzvRen+fnqsDH2LaN
> HvjOAWlxS40a5+GAcXkIk9qG9kzAV6lyNvG/lPrSQHyeitjGwClAJTwHBfWI7l0e
> NuW216klW6VZP6Wm35nEAL7EZV4ADzLH2pqsOxB8dR7KdHAVq1Wwxe5XTi8cWJ8J
> s4c2vT6uVpthpzGSbdEMoQla/DVp+h56vl2fFeY5Fww2MhODu7CmkUI2P7pvgKXy
> icO1B4BtoxgV4dEXuHMK
> =v3W6
> -----END PGP SIGNATURE-----
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
-----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-----