-----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 at 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 at 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 at 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 at 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 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) iQIcBAEBAgAGBQJVHcVWAAoJEAF3yXsqtyBlHDcP/2VULTDUzhuWefhRm1pqhMpi S/bOjeNIuhhmpnyPhnCg4xm5jYXFa1ix6q4RCxv70HAGXkv/dZpFOZ63/ni+nKnD 5xyjez0TLpvlYGg3sGJhbtatenwYMlCy4KdZt+JnuWNce/9cgPy8/oALxSOQfmp/ Comfk2d3BN/g7TxpNs1zPetFEW2fytbzh0IMjF7pOe5OtOPe+FMI8Y8wZSbkzd73 6I/5bmL6nWEHelI65dB4KaXDsWfGoc9ZkVbXJ2lHrx70avbuyKu9o+jD9MVYxa83 AgGUGlt7oZuuYGVLy4oR+T6c6O+LdLXgSuI79RsSBwwdwSkTLGOIT5ljDV53krum 2g93QtJyGtPL2+oCNqvcqKhkO8RVJ/i9B9huHvRYT0s9TcJ6+54nrCbv54y6zXc2 eonvwyuFtGkRPG2spOotK342dx63cus1T+vQU+d4ohBTANvSkh6NVFb0nbAbADJy FLRx3IdFRbe05Ehsb6hTTEnTZMTLNXx1EruvPJdTpA4c6j2eU35LwF/vEeOC+5Kq XESUSr6kSSgFHmZB40rt03lPcMameqIpWBVBgQln7KTkxxVY5yb/zjm7Cz9HdsUm TK96Gf+Xxf/iV6E/fZAsBLQmqbHL/6WeteF0t8qa7YcET1Y68xkJ/8Rbn1/Ers/C /DE83/mqV3dz2SQO6Di+ =iFvP -----END PGP SIGNATURE-----
On 2 Apr 2015 23:40, "J Martin Rushton" <martinrushton56 at 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 at 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=exitedstatus=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 didnot 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 at 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 at 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 at 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 SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVHshmAAoJEAF3yXsqtyBl/PUQAL5vatG0mcKH710DpitH/+lU THV9MQ37rluNhldkRtb2XGYzbBRDKDyvefKiJbklvoJL27BMwahCdCKziHlR40Tl 3hgbSQAhCkVONcpTq5jNvmN4scU0++0d4MPdeFv87I/Z4GWTkk9gsjcwijWCgOKZ fC/5reWHd5JRC1rq0F5QvGV5aufk2vRyUDCnrtTJooNUHfW6IOaoZOs+zLCN5AzC IVUrfegb4NYggbIXx+NIUtYuRl37Cm9D66HCMF1REPhyOC9iqvQHnHxly8W/tpeL pTeIdU9xkRnggoIZIrmPqkcfqnjh4IOSli3J+w5Utd/zxoTqU/T73KEvHf+ykL16 ggRgSX7EO7Hp+nscV7nkN4oqOys9FOvLElrrr1z1vtGtgWPVHH4x4aw9wCulLq7+ Dsu1W6sQjP53WyERANNqvJbJwx2AcfONL3cDuu9BYvwMiksW96h8GdKIHj3xHhvi YPvEPqSBKsSux9IZVWTA1E2NjzhnZ1tIRK6mK2K/PLorCq8E+v5k1jPGYdRzFLhX y1muWd7vnoa2PX2IDkEND2WuFoqwsJvPbs+r2Ow67hP7sJeJkGwZYGVsFQPGWd38 R/gUnCXeuf1gGEI+MwirHm8tZRETTiRBD0DlcLv6ZEZFpAkXYiXuTNqlUyay2egH 3bV55Ydh+AsE+heA1GFJ =O6v/ -----END PGP SIGNATURE-----
-----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 SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVHwLeAAoJEAF3yXsqtyBluEQQALrnK98R7puNN0uSTOrRILGw HX9bnBWGV9UpgL5dOTj+o+GGt3PZIcBws0DsOqnSDt33ZJ/Xq9mMeQaSlDmgeWb6 TnnZYirEJf1bDuozrKi9kaN4s4hmZU3oZhShdb2Ovem4iKCR7b36yDK0/Zq6yusJ eq1UikWGNkMw+RuUYPLSY4txoPjab9W94fET5X6rzGy5FALg7dgP02YXZGqUxGYb X5K8ehpqWr0Za3US9SZTVAT0HtDFqhrv6lBbzAD4KKP2z9G2P1PicOHW892JmGWC kzCJhc04GHrFba4aOxqnR0Qqd/TwtXve0rVYLc6c0entqdsMfaOQS7YnBUXtR77a rgl63GV90NSVs0Jejub59n+KdEqWxXBpahmOTEJQ8/G4e0omNgxevqnRk8X2VZkV rlUePRtxWVWYqKqeZfIOzu9fl9CSlczfzGvgkSRq6u4kCtf1a3zPhVeQwRc+Tsyo gOcwoM7h8txmgLHDchJXFspKvgLLq9GyQp4P3vRh7pON2gxBVdzyHyKr8KoVU8SD 9rsRbyypR1iCMTIL/yaax4/8LmwkC0lRfh/+v+Fom9iPcKNCZVRL2azO7LqUW2Fr /l7RrZfXEFZta93fe9tVld4IS3HrE6ZZoYraFv11XqUy90wqEHKd21ZocAlPbpC5 i51UkKJ7eSYciZMMh80H =jJAn -----END PGP SIGNATURE-----
-----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-----