Thanks Matt, you were correct, I needed to install the java-devel packages. Maven then ran fine, kinda scary actually watching it run! That is a LOT of code being downloaded and processed! I will table the systemd issue for now and just concentrate on getting James running. I like your idea of using crontab to work around it for now...
Any wise, I installed the new version of James 3.4 and got closer to getting it up and running. I set it up with one domain and one user (myself) and I can now send and receive email to/from myself on it. But I cannot send an outgoing email to anywhere else! I am using Thunderbird to test it with and when I try to send an outgoing email to some other domain, something weird is happening. It acts as if it sent it OK, but it is showing up in the sent folder, in Thunderbird, twice! I tried to send an email from my account on James to a GMail account I have and it never showed up, so something is failing still. Going in the other direction, if I send an email from an outside server to my account on James, I do receive it OK. BTW this latest version of James did not fix the log file problems I reported earlier. Marc.. On 02/18/2019 11:12 AM, cryptearth wrote: > Well, for me, I just added "@reboot /path/to/james/bin/james start" to > my root crontab - no need for init.d/systemd. > As the issue arised after you let systemctl create files - seems > something went wrong there. > > As for your maven issue: do you have java-devel installed? > > Matt > > Am 18.02.2019 um 03:40 schrieb Benoit Tellier: >> I am not sure you can use "james script" directly like this as a initd >> script. >> >> What we do use in docker (and thus is maintained) is >> >> ./bin/wrapper-linux-x86-64 conf/wrapper.conf wrapper.syslog.ident=james >> wrapper.pidfile=var/james.pid wrapper.daemonize=FALSE >> >> Cheers, >> >> Benoit >> >> On 2/18/19 7:39 a ²M, Marc Chamberlin wrote: >>> Hi Matt, thanks for responding! It appears to me that "classpath" is >>> actually defined in the startup scripts. There are two different >>> scripts >>> used to start the james server, either "james" or "run.sh". I do not >>> believe "classpath" is defined in any of the config files themselves. I >>> am not using "run.sh" to start the james server, instead I noted that >>> the james script is configured with the classic init.d entry points - >>> start, stop, restart, etc. I modified the "james" script slightly so >>> that I could run james as a systemd service instead (see below). At >>> this >>> point I strongly suspect that the definition of environment variables, >>> using the james startup script, is failing, so I am pursuing this to >>> see what is going on. However, running james as a systemd service does >>> not seem to be the problem, even if I just run the james startup script >>> by itself, not as a service, I am still getting the same failure with >>> the "classpath" variable. >>> >>> If anyone has ported james to run as a systemd service I would much >>> appreciate knowing how you did it. What I have done was to add the >>> init.d initialization comments to the beginning of the james shell >>> script then let systemd take it from there to create the actual >>> .service >>> files - >>> added to beginning of the james startup script to define init.d >>> runlevels - >>> >>> ### BEGIN INIT INFO >>> # Provides: james >>> # Required-Start: $network $syslog $time >>> # Required-Stop: $network $syslog $time >>> # Default-Start: 2 3 4 5 >>> # Default-Stop: 0 1 6 >>> # Description: Initscript for Apache James Mail Server >>> ### END INIT INFO >>> >>> and FYI these are the steps I then took to set up the init.d services >>> and then convert them to systemd services on OpenSuSE Leap 15.0 - >>> >>> First I created a soft link from /etc/init.d to the james startup >>> script - >>> >>> ln -s /mail/apache-james-3.2/james-server-app-3.2.0/bin/james >>> /etc/init.d/james >>> >>> Next install in james script into the various init.d runlevels >>> >>> cd /etc/init.d >>> insserv james >>> >>> Next set up the systemd files from the new init.d configuration files >>> and start the service. >>> >>> systemctl daemon-reload >>> systemctl start james.service >>> >>> The james service does start up OK and will report that it is running >>> when checking on it's status. It is just not working properly in >>> accepting connections or doing the various tasks that the service >>> should >>> be doing and my goal at this point is to resolve any and all exceptions >>> that are occurring such as this one. >>> >>> Marc... >>> >>> >>> >>> On 02/17/2019 06:01 AM, cryptearth wrote: >>>> Hey Marc, Matt here. >>>> >>>> The provided stack only says that you given "classpath" to some >>>> parameter wich expectes a url in some config file. So I guess it could >>>> help if you also show the config where you set "classpath" so one can >>>> figure out, if "classpath" is a legal input for the setting you set >>>> it. >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >> For additional commands, e-mail: server-user-h...@james.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > -- Linux Counter
