Finally solved the problem - I tried launching both scripts from the command line (tomcat-sysd with hacks to set up environment variables and dtomcat) both as user tomcat, and found that Tomcat started ok with both scripts, but OLAT deployed only when I used dtomcat. Same launch environment, same user, so the difference had to be in the scripts. I eventually traced it to one line in tomcat-sysd, a cd to CATALINA_BASE. Replacing this with /usr/bin made everything work! Replacing it with a literal /usr/share/tomcat caused the same OLAT deployment failure. /usr/share/tomcat contains mostly symlinks - in particular the work subdir is symlinked. I changed the cd to cd to /var/cache/tomcat to avoid the sysmlinks, and everything works fine - OLAT deployed correctly when tomcat was launched with systemd. I don't know why - I suspect that OLAT didn't like the symlinks in /usr/share/tomcat... Two comments (hopefully constructive): It would be useful for debugging if systemctl had an option to show output on the screen, rather than dumping it in a journal which you then have to search through. This should be a command-line option, because you would normally use it only for debugging, not for a normal boot. Secondly, the man page for systemd-journalctl mentions that you can filter journal contents using FIELD=value, but (except for one example) it doesn't indicate where the field identifiers are defined. It would make the journal a lot more usable if it was clear where to find this information. I'm pretty much agnostic on the issue of whether systemd is the best thing since sliced bread or the worst thing since Windows 98, but lack of clarity in the documentation and lack of simple debugging options left me feeling that I had less control than I wanted over the system. For example, when you run some scripts (such as /etc/init.d/tomcat) from the command line, you get a message that they are being "redirected", and systemd runs some other script (in this case tomcat-sysd). This happens even if you rename the corresponding service file to something else. So what sets up this redirection, and how would I prevent it if for some reason (such as debugging) I wanted to? This is what I mean by lack of clarity in the docs - when some program does something in normal operation then the docs ought at least to mention this. It is possible that they do, and I just don't know where to look! But if so, it isn't obvious - and, yes, I have waded through some of the material on freedesktop.org. It might be argued that the level of control I would like over a basic system component is potentially dangerous. Of course - but one of the things I have always appreciated about Linux (probably applies for other *NIX too) is that it has the attitude - "Your system, do what you want, if you break it it's your responsibility" compared with the typical Windows attitude of "You can do only those things that we think are sensible". In any case, anyone mucking about on the command line either knows what he is doing or shouldn't be there - the place for handholding is in the GUI, which naturally lends itself to limiting user options and guiding user choices. So, thanks for all your help. John Connor -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org