You are not logged in.
Pages: 1
In my (now non-existant) /etc/rc.local I had the following entries:
# Map Caps_lock to Escape in console
echo keycode 58 = Escape | loadkeys -
# Set correct res for framebuffer
external=$(</sys/class/drm/card0-HDMI-A-2/status)
[ "$external" = "connected" ] && fbset -g 1920 1080 1920 1080 32
Rather than have a .service file for rc.local (which seems sort of perverse), I have created a couple of service files for each of these functions; loadkeys.service and fbres.service respectively. Currently, they are just pointers to scripts that contain said functions. They work fine.
However, I have been trying to understand better service files and how they work. I have read the relevant man page and browsed through Lennart's series of posts so I understand that the syntax for these files is not necessarily bash compatible.
My question is, both in these examples, and also conceptually, what is the correct way to write these files?
For example, my first effort with loadkeys.service failed:
[Unit]
Description=Map Caps to Escape in Console
[Service]
ExecStart=/usr/bin/loadkeys <(echo keycode 58 = Escape)
[Install]
WantedBy=multi-user.target
Is the approach I have eventually adopted the right one™ (ie., just drop scripts in your $PATH), or can these types of small functions be written directly into .service files?
Offline
I don't know the answer to the conceptual part, but I think your loadkeys.service failed because it needed to have
Type=oneshot
in the Service section. I haven't seen it stated anywhere but always assumed that the default type was "simple" so systemd will expect your process to continue running.
I'm just learning this though, so I could be wrong.
Note, for my rc.local entry (I had the one) I used a script and called that script from my service file and made it oneshot and it worked.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
My understanding from here is that while you can use environmental variables, ExecStart is not executed directly by Bash, so what you wanted to do with redirection would not be possible from the service definition itself.
I have written several systemd service files that just point to scripts, which I think is The Right Way.
Offline
In my (now non-existant) /etc/rc.local I had the following entries:
# Map Caps_lock to Escape in console echo keycode 58 = Escape | loadkeys - # Set correct res for framebuffer external=$(</sys/class/drm/card0-HDMI-A-2/status) [ "$external" = "connected" ] && fbset -g 1920 1080 1920 1080 32
Rather than have a .service file for rc.local (which seems sort of perverse), I have created a couple of service files for each of these functions; loadkeys.service and fbres.service respectively. Currently, they are just pointers to scripts that contain said functions. They work fine.
However, I have been trying to understand better service files and how they work. I have read the relevant man page and browsed through Lennart's series of posts so I understand that the syntax for these files is not necessarily bash compatible.
My question is, both in these examples, and also conceptually, what is the correct way to write these files?
For example, my first effort with loadkeys.service failed:
[Unit] Description=Map Caps to Escape in Console [Service] ExecStart=/usr/bin/loadkeys <(echo keycode 58 = Escape) [Install] WantedBy=multi-user.target
Is the approach I have eventually adopted the right one™ (ie., just drop scripts in your $PATH), or can these types of small functions be written directly into .service files?
Use dumpkeys to create your own keymap after modifying whatever the base is. Load that via /etc/vconsole.conf.
The fbset deal seems like a udev rule waiting to be written.
Offline
Use dumpkeys to create your own keymap after modifying whatever the base is. Load that via /etc/vconsole.conf.
The fbset deal seems like a udev rule waiting to be written.
Thanks falconindy: the dumpkeys approach makes perfect sense.*
udev rule written and working. It was surprisingly painless...
Thanks skanky and josh for the pointers.
My overall curiosity about the conceptual approach remains, should anyone else want to share their thoughts/links...
---------
* Worked as well. Is there a more appropriate place for the custom keymap file than just floating in /etc/?
Offline
Pages: 1