-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've been trying to get the timidity system running as a daemon. I wrote the following init script:
#!/bin/sh # # timidity # ### BEGIN INIT INFO # Provides: timidity # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Add and remove timidity # Description: ### END INIT INFO
. /etc/rc.d/init.d/functions
RETVAL=0 PROG=timidity EXEC=/bin/$PROG PIDFILE=/var/run/timidity.pid
function start { [[ -x $EXEC ]] || exit 5 echo -n "Starting $PROG: " $EXEC -iAD RETVAL=$? echo return $RETVAL }
function stop { echo -n "Stopping $PROG: " killproc $EXEC -TERM RETVAL=$? echo return $RETVAL }
case "$1" in start) start RETVAL=$? ;; stop) stop RETVAL=$? ;; status) status $PROG RETVAL=$? ;; restart) stop start ;; reload) stop start ;; *) echo $"Usage: $prog {start|stop|status|restart|reload}" exit 1 esac exit $RETVAL
When run through systemctl during startup it fails:
[root@tamar init.d]# systemctl status timidity timidity.service - LSB: Add and remove timidity Loaded: loaded (/etc/rc.d/init.d/timidity) Active: active (exited) since Thu ... Process: 784 ExecStart=/etc/rc.d/init.d/timidity start (code=exited, status=0/SUCCESS)
... Starting LSB: Add and remove timidity... ... Starting timidity: ... jack_client_new: deprecated ... Started LSB: Add and remove timidity. ... Cannot connect to server socket err = No such file or directory ... Cannot connect to server request channel ... jack server is not running or cannot be started ... Couldn't open output device
But when run directly is works fine:
[root@tamar init.d]# ./timidity start Starting timidity: TiMidity starting in ALSA server mode Opening sequencer port: 128:0 128:1 128:2 128:3
If I use # service timidity start it also fails.
I _think_ that what is happening is that systemctl is stripping off the switch. I've spent a couple of hours searching for any links or explanation and got nowhere. I even knocked up a script to try and separate the two parts: #!/bin/sh cd /etc/init.d ./timidity start but to no avail.
If there is a simple fix could someone point me there, if it's complex don't bother, I only need the daemon when running MIDI and can start it by hand.
It might be SELinux. On a standard system; when we run things as a user from the command line SELinux rules do not apply. It would explain why it works manually but not via systemd.
Rather than using an init.d script you might want to try using a systemd service. I haven't tested but something like this should work.
[Unit] Description=timidity daemon
[Service] PIDFile=/var/run/timidity.pid User=someuser Group=someuser WorkingDirectory=/home/someuser ExecStart=/bin/timidity ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID PrivateTmp=true
On 2 April 2015 at 23:07, J Martin Rushton martinrushton56@btinternet.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've been trying to get the timidity system running as a daemon. I wrote the following init script:
#!/bin/sh # # timidity # ### BEGIN INIT INFO # Provides: timidity # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Add and remove timidity # Description: ### END INIT INFO . /etc/rc.d/init.d/functions RETVAL=0 PROG=timidity EXEC=/bin/$PROG PIDFILE=/var/run/timidity.pid function start { [[ -x $EXEC ]] || exit 5 echo -n "Starting $PROG: " $EXEC -iAD RETVAL=$? echo return $RETVAL } function stop { echo -n "Stopping $PROG: " killproc $EXEC -TERM RETVAL=$? echo return $RETVAL } case "$1" in start) start RETVAL=$? ;; stop) stop RETVAL=$? ;; status) status $PROG RETVAL=$? ;; restart) stop start ;; reload) stop start ;; *) echo $"Usage: $prog{start|stop|status|restart|reload}" exit 1 esac exit $RETVAL
When run through systemctl during startup it fails:
[root@tamar init.d]# systemctl status timidity timidity.service - LSB: Add and remove timidity Loaded: loaded (/etc/rc.d/init.d/timidity) Active: active (exited) since Thu ... Process: 784 ExecStart=/etc/rc.d/init.d/timidity start(code=exited, status=0/SUCCESS)
... Starting LSB: Add and remove timidity... ... Starting timidity: ... jack_client_new: deprecated ... Started LSB: Add and remove timidity. ... Cannot connect to server socket err = No such file or directory ... Cannot connect to server request channel ... jack server is not running or cannot be started ... Couldn't open output deviceBut when run directly is works fine:
[root@tamar init.d]# ./timidity start Starting timidity: TiMidity starting in ALSA server mode Opening sequencer port: 128:0 128:1 128:2 128:3If I use # service timidity start it also fails.
I _think_ that what is happening is that systemctl is stripping off the switch. I've spent a couple of hours searching for any links or explanation and got nowhere. I even knocked up a script to try and separate the two parts: #!/bin/sh cd /etc/init.d ./timidity start but to no avail.
If there is a simple fix could someone point me there, if it's complex don't bother, I only need the daemon when running MIDI and can start it by hand. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJVHa+rAAoJEAF3yXsqtyBlKFUP/0olzOxF44xGa0/b1UI9LyKb 8LWLJ6XYXQfwJZvZ7N5v/r9g6WPesIuWf/TugXEz20MhrN0BhoqmUrkD9FjVnpFa B7zQxRQ/DUXs2Z/w2DCfHRs5QWr3o31EGNPw/cZtqMf2bq+Z0LXXlU6A4QozDFe8 Aq/ZYduOr5GG6D8DPRCSV2ggFGvs27I7vvp48bvCNZ4jh2dAjBSlygI42Koug2Ga UcAGllj4Litdm+O5hUpyPtsJC58umfNy4Lq9Y6HBxIpeZrioxNE+trNQHoZuzoP/ clLItDMwj990Hs7ft3eyt1oIihuCTsVQ3HOkn0fjZ0OAWPIudq7ZynzfHctMGtP2 Htx0A3coYxFFZ/fZZfYUkM4FQU6OA6fQ378u9hdxq9+XKayCh4938PZHmKjGHUTH DSu+iZVJ8DEc62pfgeLUWMidEgSu5/n5ROGIHed/wwt4nE6rGv/fz0D33ArMwD3t Ozybkt+FW2u8XK4qkA/ehgf3SBK4AIHMNg9IDWiWSaF4krQlInhKHGoCp1Xi1ISV 2C/Lb7exn2CX/Uohdhqy86HNOhHHbZ6mkOL1k8XTIIazjRWJWQ/+gkt6Bj39q+K8 NDnN03oVYsXgVz2nqFT3eQ001k/pRlkKn11ZYtEZ1fY77nzsOj+J3DD/txn8qTRi yNSvbWmxPj24hEVzSKu3 =CEIq -----END PGP SIGNATURE----- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
SELinux certainly was causing fun and games. I copied your suggestion to /etc/systemd/user/timidity.service (mode 750) but it's still not happy:
[root@tamar user]# systemctl status timidity timidity.service Loaded: not-found (Reason: No such file or directory) Active: failed (Result: exit-code) since Th...
... Starting LSB: Add and remove timidity... ... timidity.service: control process exited, code=exited status=203 ... Failed to start LSB: Add and remove timidity. ... Unit timidity.service entered failed state. ... Stopped timidity.service.
I've wasted way too much time on this, I've put it in my .profile. The weirdness of systemctl will have to wait!
Thanks all
On 02/04/15 22:16, Andrew Holway wrote:
It might be SELinux. On a standard system; when we run things as a user from the command line SELinux rules do not apply. It would explain why it works manually but not via systemd.
Rather than using an init.d script you might want to try using a systemd service. I haven't tested but something like this should work.
[Unit] Description=timidity daemon
[Service] PIDFile=/var/run/timidity.pid User=someuser Group=someuser WorkingDirectory=/home/someuser ExecStart=/bin/timidity ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID PrivateTmp=true
On 2 April 2015 at 23:07, J Martin Rushton martinrushton56@btinternet.com wrote:
I've been trying to get the timidity system running as a daemon. I wrote the following init script:
#!/bin/sh # # timidity # ### BEGIN INIT INFO # Provides: timidity # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Add and remove timidity # Description: ### END INIT INFO
. /etc/rc.d/init.d/functions
RETVAL=0 PROG=timidity EXEC=/bin/$PROG PIDFILE=/var/run/timidity.pid
function start { [[ -x $EXEC ]] || exit 5 echo -n "Starting $PROG: " $EXEC -iAD RETVAL=$? echo return $RETVAL }
function stop { echo -n "Stopping $PROG: " killproc $EXEC -TERM RETVAL=$? echo return $RETVAL }
case "$1" in start) start RETVAL=$? ;; stop) stop RETVAL=$? ;; status) status $PROG RETVAL=$? ;; restart) stop start ;; reload) stop start ;; *) echo $"Usage: $prog {start|stop|status|restart|reload}" exit 1 esac exit $RETVAL
When run through systemctl during startup it fails:
[root@tamar init.d]# systemctl status timidity timidity.service - LSB: Add and remove timidity Loaded: loaded (/etc/rc.d/init.d/timidity) Active: active (exited) since Thu ... Process: 784 ExecStart=/etc/rc.d/init.d/timidity start (code=exited, status=0/SUCCESS)
... Starting LSB: Add and remove timidity... ... Starting timidity: ... jack_client_new: deprecated ... Started LSB: Add and remove timidity. ... Cannot connect to server socket err = No such file or directory ... Cannot connect to server request channel ... jack server is not running or cannot be started ... Couldn't open output device
But when run directly is works fine:
[root@tamar init.d]# ./timidity start Starting timidity: TiMidity starting in ALSA server mode Opening sequencer port: 128:0 128:1 128:2 128:3
If I use # service timidity start it also fails.
I _think_ that what is happening is that systemctl is stripping off the switch. I've spent a couple of hours searching for any links or explanation and got nowhere. I even knocked up a script to try and separate the two parts: #!/bin/sh cd /etc/init.d ./timidity start but to no avail.
If there is a simple fix could someone point me there, if it's complex don't bother, I only need the daemon when running MIDI and can start it by hand.
_______________________________________________ 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
On 2 Apr 2015 23:40, "J Martin Rushton" martinrushton56@btinternet.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
SELinux certainly was causing fun and games. I copied your suggestion to /etc/systemd/user/timidity.service (mode 750) but it's still not happy:
[root@tamar user]# systemctl status timidity timidity.service Loaded: not-found (Reason: No such file or directory) Active: failed (Result: exit-code) since Th... ... Starting LSB: Add and remove timidity... ... timidity.service: control process exited, code=exited
status=203
... Failed to start LSB: Add and remove timidity. ... Unit timidity.service entered failed state. ... Stopped timidity.service.I've wasted way too much time on this, I've put it in my .profile. The weirdness of systemctl will have to wait!
Thanks all
For the record based on your email chain this issue has little to nothing to do with systemd or systemctl but rather a poor script for some reason that I haven't troubleshooted in detail.
Remember you should never call /etc/init.d/script even on el6 as your environment and profile will pollute the scripts environment leading to inconsistent behaviour.
From the above it's clear after putting in place the service unit you did
not do systemctl daemon-reload to pick up the new unit - hence the clear error Not Found.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Inline
On 03/04/15 08:42, James Hogarth wrote:
On 2 Apr 2015 23:40, "J Martin Rushton" martinrushton56@btinternet.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
SELinux certainly was causing fun and games. I copied your suggestion to /etc/systemd/user/timidity.service (mode 750) but it's still not happy:
[root@tamar user]# systemctl status timidity timidity.service Loaded: not-found (Reason: No such file or directory) Active: failed (Result: exit-code) since Th...
... Starting LSB: Add and remove timidity... ... timidity.service: control process exited, code=exited
status=203
... Failed to start LSB: Add and remove timidity. ... Unit timidity.service entered failed state. ... Stopped timidity.service.
I've wasted way too much time on this, I've put it in my .profile. The weirdness of systemctl will have to wait!
Sorry if that sounded more brusque than it should. I've got a filthy cold, it was 20 to midnight and I've been chasing this problem for a couple of days. Frustration is directed at the implementers, not those tying to help.
Thanks all
For the record based on your email chain this issue has little to nothing to do with systemd or systemctl but rather a poor script for some reason that I haven't troubleshooted in detail.
The script was a minor alteration to an existing RH supplied script, probably originally from 5.3. Poor standard noted with amusement!
Remember you should never call /etc/init.d/script even on el6 as your environment and profile will pollute the scripts environment leading to inconsistent behaviour.
I tried using the service mechanism, just as for the last 16 years, but it continued to fail, apparently stripping off the -iAD, which is rather critical; -iA sets up an ALSA interface and the D modifier tells it to daemonise, without them it tries to run in the foreground. directly executing is debugging mode, until it starts to work and then you can look for differences. Mind you, making any significant changes to root's environment and profile would be asking for trouble IMHO.
From the above it's clear after putting in place the service unit you did not do systemctl daemon-reload to pick up the new unit - hence the clear error Not Found.
Nope, wasn't aware that I had to. You don't need to do any such thing with init scripts. :-o
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Anyhow, as I said, thanks for the input, but I moved it to my .profile so that I can get on with something useful. I'm sure in time I'll wade through the manuals and adapt, but I was just trying to be positive and adapt to the new regime. My error!
Since you appear to be a systemd guru, is there any easy way to spin off a system session that could call in simple init-type scripts? Just an ability to execute a simple script at system startup would be helpful. I (and I would guess many others) would find it a useful transition. Don't worry about how to code up the driver, it's trivial.
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Further to my earlier post. I must confess to occasionally getting to be a bit stubborn, and in this case didn't want to be beaten by Poettering. I re-installed your script, modifying some fields in what I hope was the appropriate manner: # ls -l /etc/systemd/user total 4 -rwxr-x---. 1 root root 246 Apr 3 21:21 timidity.service # cat /etc/systemd/user/timidity.service [Unit] Description=timidity daemon
[Service] PIDFile=/var/run/timidity.pid User=jmr Group=users WorkingDirectory=/home/jmr ExecStart=/usr/bin/timidity -iAD ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID PrivateTmp=true
jmr:users is my account, it will do for the moment; at least I know /home/jmr is usable! I changed the ExecStart to use /usr/bin/timidity, that is the output from command -v timidity.
# systemctl daemon-reload # echo $? 0 # systemctl start timidity Failed to issue method call: Unit timidity.service failed to load: No such file or directory. # setenforce 0 # getenforce Permissive # systemctl start timidity Failed to issue method call: Unit timidity.service failed to load: No such file or directory. # systemctl daemon-reload # systemctl start timidity Failed to issue method call: Unit timidity.service failed to load: No such file or directory.
I then rebooted the system: # systemctl status timidity timidity.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
# systemctl daemon-reload # echo $? 0 # systemctl start timidity Failed to issue method call: Unit timidity.service failed to load: No such file or directory.
I checked all logs which had been modified since the reboot and there was no reference to timidity in any of them, which does seem odd if the startup is failing.
Any pointers as to where to go next? I did briefly think of running systemctl with sh -vx, but but as I expected it is an image! Back to square 1.
Fortunately this is my home machine, so I am free to pull it to bits to try and find out what is happening. My next thought is to add dummy services in /etc/systemd/user, possibly pulling one out of the system directory to prove it is working. Poettering has certainly set me an interesting puzzle.
Thanks. Martin
-----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.
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:
-----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 2014dbus-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 timiditytimidity.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 $? 0and 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-xClearly 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@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@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
On Apr 4, 2015 7:55 AM, "J Martin Rushton" martinrushton56@btinternet.com wrote:
-----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)
<snip>
The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file.
If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails.
Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from.
--Pete
On April 4, 2015 12:14:08 PM EDT, Pete Travis lists@petetravis.com wrote:
On Apr 4, 2015 7:55 AM, "J Martin Rushton" martinrushton56@btinternet.com wrote:
-----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)
<snip>
The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file.
If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails.
Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from.
--Pete _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Is $MAINPID defined in your pidfile?
It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined.
On 4 April 2015 at 18:40, Jonathan Billings billings@negate.org wrote:
On April 4, 2015 12:14:08 PM EDT, Pete Travis lists@petetravis.com wrote:
On Apr 4, 2015 7:55 AM, "J Martin Rushton" martinrushton56@btinternet.com wrote:
-----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)
<snip>
The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file.
If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails.
Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from.
--Pete _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Is $MAINPID defined in your pidfile?
It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined.
This would be better served as the following to accomplish the immediate goal:
cat > /etc/systemd/system/timidity.service <<EOF [Unit] Description=timidity daemon
[Service] User=jmr Group=users WorkingDirectory=/home/jmr Type=forking ExecStart=/usr/bin/timidity -iAD EOF
systemctl daemon-reload
systemctl start timidity
You don't need to define an ExecStop and the type of the service should be forking as you are daemonising it - simple if you didn't daemonise it (or skip type which has this as default).
There is also no need to deal with the race condition mess that is a PID file with systemd as well... technically there is no need to mess with MAINPID in this scenario.
This is a quite messy though as you're running a 'system service' in the context of a regular user.... you were better off doing this within the user space as you started with.
The reason that failed for you before is that you were making calls to systemctl without the --user option so it was trying to act in the system context.
However a google of "timidity systemd" has the arch wiki within the first few results that has good information which results in a technically much nicer solution.
https://wiki.archlinux.org/index.php/Timidity#Daemon
Note the --global option which makes it start on a per user basis when the session for that user starts. Also note they don't daemonise it as there is no real reason to with systemd controlling the process state.
If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
<snip>
This would be better served as the following to accomplish the immediate goal:
cat > /etc/systemd/system/timidity.service <<EOF [Unit] Description=timidity daemon
[Service] User=jmr Group=users WorkingDirectory=/home/jmr Type=forking ExecStart=/usr/bin/timidity -iAD EOF
systemctl daemon-reload
systemctl start timidity
You don't need to define an ExecStop and the type of the service should be forking as you are daemonising it - simple if you didn't daemonise it (or skip type which has this as default).
There is also no need to deal with the race condition mess that is a PID file with systemd as well... technically there is no need to mess with MAINPID in this scenario.
Points noted, I just took Andrew's file and changed the bare minimum.
This is a quite messy though as you're running a 'system service' in the context of a regular user.... you were better off doing this within the user space as you started with.
It's getting rather windozy though if proper background system stuff is moved into user space. Multiple definitions of the D: drive anyone? :-(
Running as jmr is purely temporary, ideally I will create a timidity account for it, but for the present I just hacked Andrew's script to ensure the user/group/directory worked.
The reason that failed for you before is that you were making calls to systemctl without the --user option so it was trying to act in the system context.
Right, so user is user added code then. I assumed it was for site-local service files.
However a google of "timidity systemd" has the arch wiki within the first few results that has good information which results in a technically much nicer solution.
Thanks.
Note the --global option which makes it start on a per user basis when the session for that user starts. Also note they don't daemonise it as there is no real reason to with systemd controlling the process state.
It does need to be daemonised for frescobaldi to talk to it. The default (non-daemonised) way plays a file, if it is daemonised then it sets up ports to listen on. Hence the D modifier on the interface switch. I'll be honest though, when scanning for CentOS solutions I would routinely ignore ArchLinix.
If you want to stop/start/restart within the context of the user session you should be doing systemctl --user start/stop/restart timidity
No - I want it to start on boot and sit there like a good little daemon doing what it's told.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Apr 4, 2015, at 4:08 PM, J Martin Rushton martinrushton56@btinternet.com wrote:
This is a quite messy though as you're running a 'system service' in the context of a regular user.... you were better off doing this within the user space as you started with.
It's getting rather windozy though if proper background system stuff is moved into user space. Multiple definitions of the D: drive anyone? :-(
And of course, that's not at all what running systemd user services is about.
Its possible to have systemd start up a separate systemd process for each user, to manage user-based services (such as your example), but run outside of your login session, with all the resource management/cgroups and logging features you get with systemd.
I'm not really thrilled with the service, though. Since it operates outside of user login sessions, anyone who uses homedirs that require network authentication (such as NFS w/ sec=krb5 or OpenAFS) can't use it at all, since it looks in ~user/.config/systemd/ for services.
-- Jonathan Billings billings@negate.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
<snip>
The process exited, so systemd thinks the service has exited. You have a '-D' option, which probably means daemonize, but you haven't set an appropriate Type declaration in the service file.
If the service offers it, the best way to do simple services with systemd is with *foreground* options in ExecStart. Then set Type=simple. STDOUT/STDERR all goes to the journal, making it easier to see what happens if the service legitimately fails.
Take a look at packaged files in /usr/lib/systemd/system - plenty of examples to work from.
--Pete _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Is $MAINPID defined in your pidfile?
It sounds to me like only the 'kill' is exiting with a non-zero exit code because the variable is undefined.
Taking the above in order:
1) Yes the "D" does mean deamonise, as I mentioned previously. However it is not -i -A -D, but -i (interface is) A (Alsa, modified by) D (run as a deamon). Confusingly -D on its own refers to the drum channel.
2) -iA reads a file name as argument 1 and plays that. -iAD sets up sequencer ports to which an external program can write.
3) I've use Type=forking, with some success - see below.
4) pidfile wasn't being created.
When I tried a startup the command hung for several minutes before returning with and error message. Also for the first time I was seeing output from timidity in messages. There was the usual clutch of SELinux messages, and although I am running permissive during test I created the policy modules to stop them. The status showed that systemd could not read the pidfile, then it claimed that timidity had timed out. Next timidity logged its successful startup mesages before systemd claimed to have failed to start it!
Just out of interest I touched the pidfile and chmod'ed it 777. Suddenly it all worked! Systemd is spawning off timidity as user jmr, and timidity was not then able to create a file in /var/run. Failry obvious once you see it.
So: Thanks to all who have helped. The principle lessons learnt seem to be:
1) Irrespective of the README in /etc/init.d, traditional init scripts will not work unless they fit some assumed and undocumented model. Do not waste time trying to use them.
2) /etc/systemd/user is borked in my version of CentOS: systemctl doesn't read files from there.
3) systemd must never be considered a simple replacement for init files, any attempt to use it in the same way is doomed to failure. You need to allow a few man-days to achieve success. Hopefully the time needed will reduce with experience, but I'll certainly not be upgrading any production servers until I'm forced to!
On Apr 4, 2015, at 3:45 PM, J Martin Rushton martinrushton56@btinternet.com wrote:
- /etc/systemd/user is borked in my version of CentOS: systemctl
doesn't read files from there.
It does. If you use systemctl --user. But you're not using the userspace systemd to run this, you're running the system systemd, so there's no reason to ever touch /etc/systemd/user/. It may be possible to do what you want with a 'systemd --user' process, but as you've described in another email, you don't want it running with your user session, you want it as a daemon.
-- Jonathan Billings billings@negate.org
-
Andrew Holway -
J Martin Rushton -
James Hogarth -
Jonathan Billings -
Pete Travis