I just came across another solution for the /var/run directory for RHEL 7.x or any other system using systemd in this way:
Create a file in /etc/tmpfiles.d like /etc/tmpfiles.d/myapp.conf containing this line: d /var/run/myapp 775 my_user my_user Replacing myapp with the /var/run directory you want to create, and my_user with the user and group that will be using the directory. This directory should be automatically created whenever /run is recreated, and you can do it manually by running: sudo systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf On Fri, Nov 24, 2017 at 9:33 AM, Daniel Mantovani <dma...@gmail.com> wrote: > Hi Dan, thanks for your comments. The problem I run into when tried to > create the /run/myapp or /var/run/myapp directory manually or by a separate > mechanism is that depending on the host system it will be deleted during a > reboot. For instance in RHEL 7.x /var/run (or /run, it is a symlink to it > actually) by design will delete all subdirectories during reboot. > > BR, > Daniel > El viernes, 24 de noviembre de 2017, 1:14:19 (UTC-3), Dan Book escribió: >> >> The best practice IMO in regards to permissions for the run and log >> directories is to make subdirectories of /var/run and /var/log owned by the >> user that will be running hypnotoad, and put the pidfile/logfiles in there. >> >> The other issue though is if you are running hypnotoad to listen on a >> privileged port like 80 or 443, then it needs to start as root or under a >> user with the appropriate capabilities assigned (I'm not sure on the >> details for this option). You can use https://metacpan.org/pod/M >> ojolicious::Plugin::SetUserGroup to drop permissions after starting as >> root. >> >> -Dan >> >> On Thu, Nov 23, 2017 at 7:45 PM, Daniel Mantovani <dma...@gmail.com> >> wrote: >> >>> Hi, >>> >>> Type=forking should work just fine, I am not sure that with Type=simple >>> you will have all the functionallity you can get from systemd. >>> >>> A couple of advices though: >>> >>> 1) to get more confortable with systemd, you probably want to replicate >>> as much as possible the example in Mojolicious::Guides::Cookbook. It just >>> works very well (https://metacpan.org/pod/dist >>> ribution/Mojolicious/lib/Mojolicious/Guides/Cookbook.pod#Hypnotoad) >>> >>> 2) But if you need to have pidfile and log files outside your working >>> directory (like in /run/your_app/hypnotoad.pid and >>> /var/log/your_app/production.log etc...), this simple approach will not >>> work, because you probably don't want to run your application with >>> permissions so high it will be able to write in /run or /var/log >>> directories. Instead you normally use a user with minimal permissions. >>> Besides as far as I know hypnotoad requires to have permission rights in >>> an already created directory for the pid file and also for the log file. >>> >>> If that is the case, what you can do is modify your original service >>> file as follows: >>> >>> (I am supossing here that "/home/mojo_test.pl" is a typo, I guess if >>> your user is "mojo_user" for instance, the path to the app will be >>> something like "/home/mojo_user/mojo_test.pl") >>> >>> mojo_test.service >>> [Unit] >>> Description=My Mojolicious application >>> Requires=network.target >>> After=network.target >>> >>> [Service] >>> Type=forking >>> PIDFile=/run/mojo_test/hypnotoad.pid >>> User=mojo_user >>> Group=mojo_user >>> PermissionsStartOnly=True >>> ExecStartPre=/usr/bin/install -o mojo_user -g mojo_user -d /run/mojo_test >>> ExecStartPre=/usr/bin/install -o mojo_user -g mojo_user -d >>> /var/log/mojo_test >>> ExecStart=/usr/local/bin/hypnotoad /home/mojo_user/mojo_test.pl >>> ExecReload=/usr/local/bin/hypnotoad /home/mojo_user/mojo_test.pl >>> KillMode=process >>> >>> [Install] >>> WantedBy=multi-user.target >>> >>> Please check that in your configuration file you have the pid set as >>> /run/mojo_test/hypnotoad.pid, and that when >>> you define the path for the log file it goes inside /var/log/mojo_test >>> directory, something like >>> >>> sub startup { >>> ... >>> $self->app->log->path('/var/log/mojo_test/production.log'); >>> ... >>> >>> } >>> >>> About the zero downtime hypnotoad feature, with reload it should work >>> without any problems (you can check that in the log file). If you restart >>> instead of course it will kill the process and then start again, and you >>> can check that also in the log file. >>> >>> One last thing, if you happen to have a recent version of systemd or you >>> are allowed to install that (not my case unfortunatelly), you should check >>> RuntimeDirectory= and LogsDirectory= directives. You can check if those are >>> supported in your system with >>> >>> $ man systemd.directives >>> >>> If you have those, you will probably not need the ExecStartPre >>> directives above, because the only thing these do is to create those >>> directories. >>> >>> Hope it helps. >>> BR, >>> Daniel >>> >>> El jueves, 23 de noviembre de 2017, 13:36:10 (UTC-3), Boyd Duffee >>> escribió: >>>> >>>> On 23/11/17 16:14, Dan Book wrote: >>>> > I would not recommend running hypnotoad as a Type=simple service with >>>> -f. >>>> > This will not allow you to use hot-restarts via systemctl reload. >>>> >>>> Naively, I _can_ hot-restart with systemctl reload servicename, but now >>>> you've got me worried. >>>> Any idea why it's not advisable and is Type=forking the proper >>>> solution? >>>> >>>> -- >>>> Boyd Duffee Keele University (01782) 734225 >>>> DevOps - Student Facing Systems >>>> >>>> Some people are born on third base and go through life >>>> thinking they hit a triple - Barry Switzer >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Mojolicious" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to mojolicious...@googlegroups.com. >>> To post to this group, send email to mojol...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/mojolicious. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Mojolicious" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mojolicious+unsubscr...@googlegroups.com. > To post to this group, send email to mojolicious@googlegroups.com. > Visit this group at https://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
