I have just installed systemd and I have a failing service, proc-sys-fs-binfmt_misc.automount
I've seen here it's a part of systemd:
https://github.com/systemd/systemd/blob/master/units/proc-sys-fs-binfmt_misc.automount
Is this file important ? How do I solve the activation issue ?
Below my systemctl status
Last login: Mon Apr 13 23:13:19 2015 from nor75-18-82-241-236-193.fbx.proxad.net
svassaux#vps127101:~$ systemctl status
proc-sys-fs-binfmt_misc.automount -> '/org/freedesktop/systemd1/unit/proc_2dsys_ 2dfs_2dbinfmt_5fmisc_2eautomount'
proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File Syste m Automount Point
Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.automount; static )
Active: failed (Result: resources)
Where: /proc/sys/fs/binfmt_misc
Docs: https://www.kernel.org/doc/Documentation/binfmt_misc.txt
http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
For those who want to disable proc-sys-fs-binfmt_misc.automount (if you’re in, say, a containerized environment where autofs is not available), note that systemctl disable won’t work, but
systemctl mask proc-sys-fs-binfmt_misc.automount
does.
For using .automount unit of systemd, systemd tries to open /dev/autofs. In case autofs file system is not available on your system, all .automount unit files fails to start.
So first ensure your system does have auto file system support.
Related
I want to run NodeJS code as service, but whenever I add output to log files I get error with syntax.
● bot.service - simple NodeJS bot
Loaded: bad-setting (Reason: Unit bot.service has a bad unit file setting.)
Active: inactive (dead)
Dec 21 17:33:36 ubuntu systemd[1]: /etc/systemd/system/bot.service:9: Failed to resolve unit specifiers in /var/bot/error-$(date+%Y_%m_%d_%I_%M_%p).log: Invalid slot
Dec 21 17:33:36 ubuntu systemd[1]: bot.service: Unit configuration has fatal error, unit will not be started.
bot.service:
[Unit]
Description=simple NodeJS bot
After=network-online.target
[Service]
Restart=on-failure
SyslogIdentifier=bot
WorkingDirectory=/home/ubuntu/bot
ExecStart=/home/ubuntu/.nvm/versions/node/v16.6.2/bin/node /home/ubuntu/bot/out/index.js >> /var/bot/bot.log 2> /var/bot/"error-$(date+%Y_%m_%d_%I_%M_%p).log"
# limit CPU and RAM quota for our service
# Not necessary, but i am running other servers, so i need it
CPUAccounting=true
MemoryAccounting=true
SyslogIdentifier=bot
[Install]
WantedBy=multi-user.target
The problem comes from the % sign. You need to escape it (%%) if you want the command to be accepted by systemd
Background
I have an application that requires that I start several RViz windows in a headless ROS environment. The system is required to send image files to some locally networked dumb terminals which can barely but adequately show image files (.jpg). Therefore, I simply take screen snapshots of the RViz displays and send those. This works well, however, I need to run the RViz windows on startup.
Implementation
The ROS noetic system is running on Ubuntu 20.04. I used robot_upstart to give me a working skeleton for a systemd service and then modified the core service file to allow display_manager access
This is my working system.d service file called 'test.service'
[Unit]
Description="bringup test"
After=network.target
After=display_manager.service
Wants=display_manager.service
[Service]
Type=simple
Environment="XAUTHORITY=/run/user/1000/gdm/Xauthority"
Environment="DISPLAY=:0"
Environment="XDG_RUNTIME_DIR=/home/<my_username/catkin_ws/tmp"
Environment="/home/<my_username>" # THIS FIXED THE ISSUE
ExecStart=/usr/sbin/test-start
[Install]
WantedBy=multi-user.target
This almost works. journalctl -f -u test.service lists an error:
Jun 06 21:10:22 aoede test-start[10209]: /opt/ros/noetic/lib/rviz/rviz: line 1: 10220 Aborted (core dumped) $0 $#
Jun 06 21:10:25 aoede dbus-daemon[10259]: [session uid=1000 pid=10257] AppArmor D-Bus mediation is enabled
Jun 06 21:10:28 aoede test-start[10237]: terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
Jun 06 21:10:28 aoede test-start[10237]: what(): boost::filesystem::create_directory: Permission denied: "/.rviz"
Jun 06 21:10:28 aoede test-start[10218]: Aborted (core dumped)
It is trying to write to a directory /.rviz . When I create this directory myself with relaxed permissions it then works correctly and the RViz windows all start. This directory seems to be filled with persistence files for the RViz instances.
I have tried setting XDG_RUNTIME_DIR as above but it had no effect. What environment variable should I set, or other way, so that RViz is looking in a more rational place? Also, would appreciate any recommendations on better practices than above.
The required environment variable is $HOME
This was being set after the service was run and was therefore not available.
Environment="/home/<my_username>"
Fixed the issue
I've created my own Service with systemd. It is supposed to run a python script once at boot time. It sends an Email with the IP-Address and the Teamviewer id, this is why i have an delay in it, otherwise i get an error that the domain of the Mailserver cant be resolved. The Script should run in the background because of the 30 seconds delay.
The script is located in /usr/bin/glatv.py and is ecexuteable, the script run without an problem. The construct is runnning on an Raspberry Pi4 with Raspian Buster 2020-02-13
The Service is in /etc/systemd/system/ located, is executeable and enabled:
[Unit]
Description=My Own Service
[Service]
Type=oneshot
ExecStart=/usr/bin/glatv.py &
[Install]
WantedBy=reboot.target
But
systemctl start myservice
is working without a Problem
● glatvd.service - My Own Service
Loaded: loaded (/etc/systemd/system/glatvd.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Apr 02 12:52:31 raspberrypi systemd[1]: Starting My Own Service...
Apr 02 12:53:02 raspberrypi systemd[1]: glatvd.service: Succeeded.
Apr 02 12:53:02 raspberrypi systemd[1]: Started My Own service.
after a reboot there is no call or log
Instead of having an arbitrary 30-second delay, add this to your service file:
After=network-online.target
Wants=network-online.target
You should try run this command to make your service enable to run after restart
systemctl enable myservice
and for log, I believe you must put this parameters into your service's config file
StandardOutput=/path/to/info/log/info_log.log
StandardError=/path/to/error/log/error_log.log
Anything I got this reference: How to redirect output of systemd service to a file
I have two problems running freeswitch from systemd :
EDIT 2 - I have moved the slow start up question to here (Freeswitch pauses on check_ip at boot on centos 7.1) as although they may be related it's probably good as a standalone.
EDIT - I have noticed something else. Look at these next lines captured from the terminal output when running it from there. The gap is 4 minutes but it has been around 10 minutes before. I noticed it because I was trying to find out why port 8021 was taking several minutes to accept the fs_cli connection. Why does this happen? Never happened to me before and I've installed loads of FS boxes. This does the same thing on both 1.7 & todays 1.6.
2015-10-23 12:57:35.280984 [DEBUG] switch_scheduler.c:249 Added task 1 heartbeat (core) to run at 1445601455
2015-10-23 12:57:35.281046 [DEBUG] switch_scheduler.c:249 Added task 2 check_ip (core) to run at 1445601455
2015-10-23 13:01:31.100892 [NOTICE] switch_core.c:1386 Created ip list rfc6598.auto default (deny)
I sometimes get double processes started. Here is my status line after such an occurrence :
# systemctl status freeswitch -l
freeswitch.service - freeswitch
Loaded: loaded (/etc/systemd/system/multi-user.target.wants/freeswitch.service)
Active: activating (start) since Fri 2015-10-23 01:31:53 BST; 18s ago
Main PID: 2571 (code=exited, status=0/SUCCESS); : 2742 (freeswitch)
CGroup: /system.slice/freeswitch.service
├─usr/bin/freeswitch -ncwait -core -db /dev/shm -log /usr/local/freeswitch/log -conf /usr/local/freeswitch/conf -run /usr/local/freeswitch/run
└─usr/bin/freeswitch -ncwait -core -db /dev/shm -log /usr/local/freeswitch/log -conf /usr/local/freeswitch/conf -run /usr/local/freeswitch/run
Oct 23 01:31:53 fswitch-1 systemd[1]: Starting freeswitch...
Oct 23 01:31:53 fswitch-1 freeswitch[2742]: 2743 Backgrounding.
and there are two processes running.
The PID file is sometimes not written fast enough for the systemd process to pick it up, but by the time I see this (no matter how fast I run the command) it's always there by the time I do :
Oct 23 02:00:26 arribacom-sbc-1 systemd[1]: PID file
/usr/local/freeswitch/run/freeswitch.pid not readable (yet?) after
start.
Now, in (2) everything seems to work ok, and I can shut down the freeswitch process using
systemctl stop freeswitch
without any issues, but in (1) it just doesn't seem to do anything.
I'm wondering if the two are related, and that freeswitch is reporting back to systemd that the program is running before it actually is. Then systemd is either starting up another process or (sometimes) not.
Can anyone offer any pointers? I have tried to mail the freeswitch users list but despite being registered I simply cannot get any emails to appear on the list (but that's another problem).
* Update *
If I remove the -ncwait it seems to improve the double process starting but I still get the can't read PID warning, so I'm still sure there's an issue present, possibly around timing(?).
I'm on Centos 7.1, & my freeswitch version is
FreeSWITCH Version 1.7.0+git~20151021T165609Z~9fee9bc613~64bit (git
9fee9bc 2015-10-21 16:56:09Z 64bit)
and here's my freeswitch.service file (some things have been commented out until I understand what they are doing and any side effects they may have) :
[Unit]
Description=freeswitch
After=syslog.target network.target
#
[Service]
Type=forking
PIDFile=/usr/local/freeswitch/run/freeswitch.pid
PermissionsStartOnly=true
ExecStart=/usr/bin/freeswitch -nc -core -db /dev/shm -log /usr/local/freeswitch/log -conf /u
ExecReload=/usr/bin/kill -HUP $MAINPID
#ExecStop=/usr/bin/freeswitch -stop
TimeoutSec=120s
#
WorkingDirectory=/usr/bin
User=freeswitch
Group=freeswitch
LimitCORE=infinity
LimitNOFILE=999999
LimitNPROC=60000
LimitSTACK=245760
LimitRTPRIO=infinity
LimitRTTIME=7000000
#IOSchedulingClass=realtime
#IOSchedulingPriority=2
#CPUSchedulingPolicy=rr
#CPUSchedulingPriority=89
#UMask=0007
#
[Install]
WantedBy=multi-user.target
In the current master branch, take the two files from debian/ directory:
freeswitch-systemd.freeswitch.service -- should go as /lib/systemd/system/freeswitch.service
freeswitch-systemd.freeswitch.tmpfile -- should go as /usr/lib/tmpfiles.d/freeswitch.conf
You probably need to adapt the paths, or build FreeSWITCH to use standard Debian paths.
I am trying to set up Postgresql 9.3 server on Centos 7 (installation via yum) inside a custom directory, which in my case is an encrypted partition (/custom_container/database) that is mounted on startup. For a certain reason Postgresql does not behave like it should in the manual and makes an error on service startup.
Note: It does not want to accept the PGDATA environment variable which I set, and when running
su - postgres -c '/usr/pgsql-9.3/bin/initdb'
(given that the PGDATA directory is owned by postgres:postgres) the cluster gets initialized inside the default directory /var/lib/pgsql/9.3/data/
The only way to change that is using
su - postgres -c '/usr/pgsql-9.3/bin/initdb --pgdata=$PGDATA'
Which initializes the directory inside the custom container I am using. This is something I could not figure out, as the docs say that PGDATA variable is taken on default.
Problem: When running
service postgresql-9.3 start
I get an error with the log
postgresql-9.3.service - PostgreSQL 9.3 database server
Loaded: loaded (/usr/lib/systemd/system/postgresql-9.3.service; disabled)
Active: failed (Result: exit-code) since Mon 2014-11-10 15:24:15 CET; 1s ago
Process: 2785 ExecStartPre=/usr/pgsql-9.3/bin/postgresql93-check-db-dir ${PGDATA} (code=exited, status=1/FAILURE)
Nov 10 15:24:15 CentOS-70-64-minimal systemd[1]: Starting PostgreSQL 9.3 database server...
Nov 10 15:24:15 CentOS-70-64-minimal postgresql93-check-db-dir[2785]: "/var/lib/pgsql/9.3/data/" is missing or empty.
Nov 10 15:24:15 CentOS-70-64-minimal postgresql93-check-db-dir[2785]: Use "/usr/pgsql-9.3/bin/postgresql93-setup initdb" to initialize t...ster.
Nov 10 15:24:15 CentOS-70-64-minimal postgresql93-check-db-dir[2785]: See %{_pkgdocdir}/README.rpm-dist for more information.
Nov 10 15:24:15 CentOS-70-64-minimal systemd[1]: postgresql-9.3.service: control process exited, code=exited status=1
Nov 10 15:24:15 CentOS-70-64-minimal systemd[1]: Failed to start PostgreSQL 9.3 database server.
Nov 10 15:24:15 CentOS-70-64-minimal systemd[1]: Unit postgresql-9.3.service entered failed state.
Which means that Postgresql, even though the cluster is initialized in the new $PGDATA directory (/custom_container/database) still looks for the cluster in /var/lib/pgsql/9.3/data/
Did anyone experience this Postgresql behavior before? Could it be that I forgot certain configuration options or that the problem comes from Postgresql installation?
Thank you in advance!
It appears the real problem was setting the environment variables, which I got working in the following thread:
Centos 7 environment variables for Postgres service
The issue is the PGDATA variable set inside the custom /etc/systemd/system/postgresql-9.3.service which should be created from the contents of /usr/lib/systemd/system/postgresql-9.3.service which uses the default PGDATA var.
You need to create a custom postgresql.service file in /etc/systemd/system/, which overrides the default PGDATA environment variable. Your custom service file can .include the default postgresql service file, so you only need to add what you want to change. That way, upgrades can still modify/improve? stuff in the default service file, while your change is preserved.
This is how I just did it in Centos 7:
cat <<END >/etc/systemd/system/postgresql.service
.include /lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/mnt/postgres/data ## <== SET THIS TO YOUR WANTED $PGDATA
END
systemctl daemon-reload
systemctl restart postgresql.service
Verify :
ps -ax | grep [p]ostgres
Update:
Rather than manually creating the file and adding the .include line, you can also use the systemd built-in way:
systemctl edit postgresql.service
This will open your default editor and save your changes to /etc/systemd/system/postgresql.service.d/override.conf
try this:
## Login with postgres user
su - postgres
export PGDATA=/your_path/data
pg_ctl -D $PGDATA start &
I think the most "CentOS 7 way" to do it is to copy the service file:
sudo cp /usr/lib/systemd/system/postgresql-9.6.service /etc/systemd/system/postgresql-9.6.service
Then edit the file /etc/systemd/system/postgresql-9.6.service:
# Location of database directory
Environment=PGDATA=/mnt/volume/var/lib/pgsql/9.6/data/
Then start it sudo systemctl start postgresql-9.6 and verify:
# sudo ps -ax | grep postmaster
32100 ? Ss 0:00 /usr/pgsql-9.6/bin/postmaster -D /mnt/volume/var/lib/pgsql/9.6/data/
Try to edit file /etc/init.d/postgresql-9.3:
PGDATA=/your/custom/path