You are not logged in.
If you want KDM started at boot then, enable the unit and make sure your default.target links to graphical.target.
# systemctl enable kdm.service
# ln -s /lib/systemd/system/default.target /etc/systemd/system/default.target
systemd will not look at /etc/inittab. While there is some glue to allow generation of native unit files for daemons in /etc/rc.conf (via initscripts-systemd), I don't really recommend using it for anything more than a stop gap solution. We have tons of native unit files available.
Offline
Are those softlinks gonna be how final systemd does it or will there be a proper command for that kind of thing?
D:
Offline
"Systemctl enable anything.service" is the systemd command.
It does the same as "ln -s"
Symlink between files.
lenovo w500 - huawei matebook 14 | archlinux | swaywm | foot | falkon
Offline
ah ok. systemd sounds better and better.
D:
Offline
So, what are the downsides to using systemd here on Arch at the moment? I'm only aware of a few left:
- util-linux is not compiled with --enable-libmount, so if we make /etc/mtab a symlink to /proc/mounts (as systemd wants), it breaks fuse and some mount options
- missing native unit files for many services, such that we end up using legacy rc.d scripts instead
Anything else like this still to watch out for?
Edit: After trying it again, that second one looks like a much bigger problem than I expected. I was under the impression that I could use rc.d scripts directly somehow ("systemctl enable postfix.service" to run /etc/rc.d/postfix) but that doesn't actually work. How are people getting by without the needed units? About half of the things I want to run don't have units written.
Last edited by ataraxia (2011-09-10 03:18:34)
Offline
from the wiki
arch-daemons.target
Parses the DAEMONS array in /etc/rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used; otherwise, the script in /etc/rc.d/ is used to control the unit.
Ah, good taste! What a dreadful thing! Taste is the enemy of creativeness.
Picasso
Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away.
Saint Exupéry
Offline
from the wiki
arch-daemons.target
Parses the DAEMONS array in /etc/rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used; otherwise, the script in /etc/rc.d/ is used to control the unit.
Yes, I've read the wiki, and I understand the contents of initscripts-systemd (which I don't have installed as I don't intend to use it). It's not what I'm looking for. I don't want everything in DAEMONS to be started by systemd in that manner. I want the ability to selectively do so. After all, "systemctl start postfix.service" works, so why shouldn't "systemctl enable postfix.service"?
I'm getting by now with eight hand-written units to fill the gap. Doing that requires paying attention for when something equivalent shows up in systemd-arch-units or the service's own package so I can drop my hacks, so it's not optimal either.
Offline
Ataraxia, I believe /etc/rc.d scripts need to have LSB headers (not present in Arch scripts) to be "systemctl enable"d.
Can someone confirm? Having the need for only a couple of unit files, I chose to just write them rather than try to get them working with existing /etc/rc.d scripts.
Offline
Ataraxia, I believe /etc/rc.d scripts need to have LSB headers (not present in Arch scripts) to be "systemctl enable"d.
That makes sense, given that my previous experience with this working was in Fedora.
Onward with more questions:
- Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?
- When I want to modify a (normal) service unit, I copy it to /etc/systemd/system/multi-user.target.wants/ instead of just symlinking, and change the contents. Why can't I do the same with socket units by copying them to /etc/systemd/system/sockets.target.wants/? If I do that, systemd continues to use the version under /lib/systemd/system/ instead of my modified file (even after reboot). I have to actually rename the socket unit (and the associated service unit) for the contents to be respected.
- How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types. For example, how would I convert http://projects.archlinux.org/svntogit/ … lm_sensors to a service unit? It first runs "/usr/bin/sensors" (in oneshot fashion), and then runs "/usr/sbin/healthd" (which is a forking daemon). Would I split it in two, with one starting "After" the other?
Offline
Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package
Offline
as an example, i suspect
Offline
Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?
Copy modifyed service and socket files to /etc/systemd/system/ and symlink to one of the "wants" directories. eq multi-user.target.wants or sockets.target.wants
Then execute "sudo systemctl daemon-reload" To activate the new settings.
How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types.
http://0pointer.de/public/systemd-man/s … rvice.html
Last edited by ron9 (2011-09-11 09:15:23)
lenovo w500 - huawei matebook 14 | archlinux | swaywm | foot | falkon
Offline
- Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?
I'd very much prefer that units be submitted upstream before they go to systemd-arch-units.
Offline
Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package
If you actually read lm_sensors.service, it doesn't start healthd. Did you follow my link? It does something entirely different from what you seem to be expecting.
Offline
ataraxia wrote:Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?
Copy modifyed service and socket files to /etc/systemd/system/ and symlink to one of the "wants" directories. eq multi-user.target.wants or sockets.target.wants
Then execute "sudo systemctl daemon-reload" To activate the new settings.
And I'm pointing out that this doesn't actually work for socket units, even though it does work fine for service units.
ataraxia wrote:How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types.
Where in that manpage is my question actually answered?
(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
Offline
Where in that manpage is my question actually answered?
(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
If you think they belong in the same .service-file I suppose you have to use the same type for all of it. If you need to exec more than one thing, you can use the following:
ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially. Alternatively, these directives may be specified more than once with the same effect. However, the latter syntax is not recommended for compatibility with parsers suitable for XDG .desktop files. Use of these settings is optional. Specifier and environment variable substitution is supported.
If you need it to be a separate type (like forking), you'd have to create separate .service-files for it, then I suppose you'd use "Requires", "Wants", "Before" or "After" to make it all run in the desired order.
Offline
ataraxia wrote:Where in that manpage is my question actually answered?
(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
If you think they belong in the same .service-file I suppose you have to use the same type for all of it. If you need to exec more than one thing, you can use the following:
ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially. Alternatively, these directives may be specified more than once with the same effect. However, the latter syntax is not recommended for compatibility with parsers suitable for XDG .desktop files. Use of these settings is optional. Specifier and environment variable substitution is supported.If you need it to be a separate type (like forking), you'd have to create separate .service-files for it, then I suppose you'd use "Requires", "Wants", "Before" or "After" to make it all run in the desired order.
Ah, thank you. That looks like just what I need. (Serves me right for complaining that I've already read the docs, and then having it be in there anyway.)
Offline
...People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
Unfortunately (and this is not aimed at you) making that assumption is generally a good first order approximation. Those who do their research bear the burden of being the exception as opposed to the norm. You can mitigate it (somewhat) by declaring that you have done the research up front.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Online
lymphatik wrote:Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package
If you actually read lm_sensors.service, it doesn't start healthd. Did you follow my link? It does something entirely different from what you seem to be expecting.
Well have a look here http://www.lm-sensors.org/browser/lm-se … healthd.sh
healthd is just a script that send email. It is just an example while lm_sensors.service actually launch lm_sensors
And for your information you can launch multiple binaries with execstart
ExecStart=/sbin/ip link set eth0 up ; /sbin/ip addr add 192.168.5.3/24 dev eth0 ; /sbin/ip route add default via 192.168.5.254
And if you had read the manpage you would have found it. man systemd.service line 80.
Last edited by lymphatik (2011-09-11 19:15:04)
Offline
http://0pointer.de/public/systemd-man/s … rvice.html
ataraxia wrote:Where in that manpage is my question actually answered?
Type=
Configures the process start-up type for this service unit. One of simple, forking, oneshot, dbus, notify.
ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially.
If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
.
Last edited by ron9 (2011-09-11 22:16:38)
lenovo w500 - huawei matebook 14 | archlinux | swaywm | foot | falkon
Offline
I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.
Offline
I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.
At least you attempted to find it. If you can't ask questions, then what's the point of understanding?
D:
Offline
ataraxia wrote:I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.
At least you attempted to find it. If you can't ask questions, then what's the point of understanding?
Well, in the same vein of thought, if you can't understand the answers, what's the point of asking questions?
Kudos to ataraxia for the response, though.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
But how do you know you won't understand the answer until you ask the question?
I'm gonna give systemd another go I think. Is there a list of arch packages with systemd units?
D:
Offline
Is there a list of arch packages with systemd units?
On my machine:
% pacman -Ql | grep /lib/systemd/ | awk '{ print $1 }' | uniq
alsa-utils
avahi
bootchart2
consolekit
dbus-core
dnsmasq
initscripts-systemd
libcanberra
lm_sensors
networkmanager
rtkit
systemd
systemd-arch-units
udev
There are plenty of unit files in systemd-arch-units for other packages too. Finally, arch-daemons.target will allow you to start daemons without having unit files (by listing them in DAEMONS in rc.conf).
Offline