This is more for tracking purposes as I have already talked about this with mgorny. We need a way to run commands at start/stop when booting using systemd. There seems to be some options: - Upstream looks to support it via --with-rc-local-script-path-* and its rc-local-generator -> the problem is that it looks to rely in sysvinit compatibility, that mgorny prefers to get disabled - Lxnay's way -> https://github.com/Sabayon/systemd-love/tree/master/sys-apps/systemd -> It provides a service file running a custom script equivalent to /etc/init.d/local (not needing sysvinit support then) Thanks a lot! Reproducible: Always
(In reply to Pacho Ramos from comment #0) > This is more for tracking purposes as I have already talked about this with > mgorny. We need a way to run commands at start/stop when booting using > systemd. There seems to be some options: > - Upstream looks to support it via --with-rc-local-script-path-* and its > rc-local-generator -> the problem is that it looks to rely in sysvinit > compatibility, that mgorny prefers to get disabled What are you seeing that seems to say this relies on sysvinit compatibility?
As far as I can see, we have three options here: 1. Invent custom, OpenRC-compatible local thingie. I don't like this since it's providing a bit of OpenRC compat while the general idea is not to provide OpenRC compat at all... 2. Enable SysV compat in systemd and use that for rc.local. That one sounds even worse to me, to be honest since it's basically a regression to ancient Fedora init. 3. Invent a new, custom, systemd-specific local replacement. Not good idea either, since it's basically making new things that aren't consistent with the whole systemd idea and asking users to convert their systems to that. Or we just let users write local .service files for those properly. It's not that hard, really. And it at least is guaranteed to work properly all the time.
systemd appears to support by default extra start and stop scripts, located at /etc/rc.local and /usr/sbin/halt.local respectively, and this seems to be valid whether or not sysvinit compatibility is set. I can attempt to write scripts that would be installed in these locations if the openrc use flag is on in systemd and test them.
As far as sys-apps/systemd is concerned, I think enabling upstream's SysV compat is the only option that makes sense. If we don't want to do that (and I agree that we probably don't), we should not add a custom solution to the sys-apps/systemd ebuild. That said, I have no objection to implementing a custom solution (like lxnay's) in a separate ebuild/package.
@pacho: After looking further, you are correct, the extra start/stop scripts require sysv compatibility. @mgorny: I agree that on a pure systemd system, we probably don't want to turn on the sysv compatibility. However, why not turn it on if they have openrc in their use flags for systemd?
@pacho: On the other hand, I do remember speaking with you, and you stated to me that sysv compatibility is left on in other distros. Which ones? @mgorny: If this is the case and doesn't cause trouble for them, What's the benefit of forcing it off? I think it would be more beneficial for us to leave this on if possible.
(In reply to Mike Gilbert from comment #4) > That said, I have no objection to implementing a custom solution (like > lxnay's) in a separate ebuild/package. That looks interesting :O About why I dislike the idea of having to manually create a rule for each command, looks for example to the start commands I have even needed to run on one of the systems I am maintaining: (I already shown mgorny two commands I am currently running on my laptop just not -> one for proper sound in et (that could, indeed, be replaced by et-sdl-sound stuff that I still need to try), the other for tweaking tuxonice (that can also occur when people wants to tweak many other things in /sys or /proc) echo 1024 > /sys/class/rtc/rtc0/max_user_freq setkeycodes e005 129 (due a symbol not being properly shown in consoles) ethtool -s enp0s4 speed 100 duplex full (due a buggy driver that finally got fixed in recent kernels after years :S) From my point of view, forcing people to create a .service file for each one would be overkill :| (In reply to William Hubbs from comment #6) > @pacho: > On the other hand, I do remember speaking with you, and you stated to me > that sysv compatibility is left on in other distros. Which ones? http://pkgs.fedoraproject.org/cgit/systemd.git/ http://download.opensuse.org/factory/repo/src-oss/suse/src/systemd-204-9.2.src.rpm https://forums.mageia.org/en/viewtopic.php?p=33087 Anyway, lxnay's solution allows to skip sysv compat even keeping this functionality (and I still don't see the reasoning against it, not sure what exactly mean by "openrc compat"... do you want it to read contents from a file instead or surfing inside /etc/local.d?)
(In reply to William Hubbs from comment #6) > @pacho: > On the other hand, I do remember speaking with you, and you stated to me > that sysv compatibility is left on in other distros. Which ones? Generally the distros which used 'sysvinit' as understood by Fedora. That is, using the /etc/*/1234foobarbaz thing. Serial boot, ordering by name, *no dependencies* and stuff like that. > @mgorny: > If this is the case and doesn't cause trouble for them, What's the > benefit of forcing it off? I think it would be more beneficial for us to > leave this on if possible. It simply can't work with OpenRC. OpenRC has dependencies, this thing can't support them.
(In reply to Pacho Ramos from comment #7) > (In reply to Mike Gilbert from comment #4) > > That said, I have no objection to implementing a custom solution (like > > lxnay's) in a separate ebuild/package. > > That looks interesting :O > > About why I dislike the idea of having to manually create a rule for each > command, looks for example to the start commands I have even needed to run > on one of the systems I am maintaining: > (I already shown mgorny two commands I am currently running on my laptop > just not -> one for proper sound in et (that could, indeed, be replaced by > et-sdl-sound stuff that I still need to try), the other for tweaking > tuxonice (that can also occur when people wants to tweak many other things > in /sys or /proc) /proc/sys goes with sysctl.d. As far as I understand, /sys should be mangled via udev rules. That is, getting rules applied every time the particular device is plugged. > echo 1024 > /sys/class/rtc/rtc0/max_user_freq KERNEL=="rtc0", ATTR{max_user_freq}=1024 ? Just guessing the values, though. > setkeycodes e005 129 (due a symbol not being properly shown in consoles) That one would probably use a dep for some console/keyboard thing. That can't be expressed in a plain file. > ethtool -s enp0s4 speed 100 duplex full (due a buggy driver that finally got > fixed in recent kernels after years :S) Again, udev. > From my point of view, forcing people to create a .service file for each one > would be overkill :| Welcome to the world of systemd. But it's less overkill than you think, and it works actually. And in the end, you can create a .service which runs your custom script if you really need that. > Anyway, lxnay's solution allows to skip sysv compat even keeping this > functionality (and I still don't see the reasoning against it, not sure what > exactly mean by "openrc compat"... do you want it to read contents from a > file instead or surfing inside /etc/local.d?) I mean that we're either partially supporting OpenRC -- then people start expecting more OpenRC support -- or inventing something custom to Gentoo.
(In reply to Michał Górny from comment #8) > (In reply to William Hubbs from comment #6) > > @pacho: > > On the other hand, I do remember speaking with you, and you stated to me > > that sysv compatibility is left on in other distros. Which ones? > > Generally the distros which used 'sysvinit' as understood by Fedora. That > is, using the /etc/*/1234foobarbaz thing. Serial boot, ordering by name, *no > dependencies* and stuff like that. sysvinit compatibility has to be on to run /etc/rc.local when system starts and /usr/sbin/halt.local when system stops. Pacho is not trying to run anything you are talking about above; he wants to just be able to run these two scripts. scripts. > > @mgorny: > > If this is the case and doesn't cause trouble for them, What's the > > benefit of forcing it off? I think it would be more beneficial for us to > > leave this on if possible. > > It simply can't work with OpenRC. OpenRC has dependencies, this thing can't > support them. He isn't talking about running OpenRC init scripts, just these two scripts.
At first, thanks for pointing the replacements for some of the exact lines I have posted... but I am sure there are many other commands that people can need to run (really do you want me to check every machine I maintain to post here random commands that need to be run?) (In reply to Michał Górny from comment #9) > /proc/sys goes with sysctl.d. Could this be documented in http://wiki.gentoo.org/wiki/Systemd ? > > As far as I understand, /sys should be mangled via udev rules. That is, > getting rules applied every time the particular device is plugged. Not sure if everything configurable via /sys is always related with switchable devices... also, not sure how feasible is to force people to learn to also write udev rules for every command they are running over /sys [...] > Welcome to the world of systemd. But it's less overkill than you think, and > it works actually. And in the end, you can create a .service which runs your > custom script if you really need that. The world of systemd allows to handle rc.local stuff, even Fedora is allowing that, and lxnay has an option to handle it without sysv compat > > > Anyway, lxnay's solution allows to skip sysv compat even keeping this > > functionality (and I still don't see the reasoning against it, not sure what > > exactly mean by "openrc compat"... do you want it to read contents from a > > file instead or surfing inside /etc/local.d?) > > I mean that we're either partially supporting OpenRC -- then people start > expecting more OpenRC support -- or inventing something custom to Gentoo. Eing?
Also, per https://forums.mageia.org/en/viewtopic.php?p=33087 you can even have a script not even relying on /etc/local.d to handle this (and, then, no openrc trace)
We can add 'rc-local.service' with USE=-vanilla, that uses /etc/local.d/. Lxnay's unit file is quite nice; I would prefer not having additional local.d.rc though. Is there a way we had something like 'foo /etc/local.d/*.start' that would run all the scripts in lexical order.
(In reply to Michał Górny from comment #13) > Is there a way we had something like 'foo /etc/local.d/*.start' that would > run all the scripts in lexical order. I guess a workaround would be to use "ls" as I remember it had some options to tweak the order, but no idea about how to do that with "bash" directly :S Regarding the rc.local thing (thanks a lot for taking care! :D), I was considering usage of "Type=idle": http://www.freedesktop.org/software/systemd/man/systemd.service.html But I am not sure how will it work as, per documentation, it should behave as "simple" :/
(In reply to Michał Górny from comment #13) > Is there a way we had something like 'foo /etc/local.d/*.start' that would > run all the scripts in lexical order. I rather doubt systemd would process a shell glob in an unit file. We could do something like this, but using a shell script would be cleaner. ExecStart=/bin/sh -c 'for x in /etc/local.d/*.start; do test -x "$x" && "$x"; done' ExecStop=/bin/sh -c 'for x in /etc/local.d/*.stop; do test -x "$x" && "$x"; done'
(In reply to Pacho Ramos from comment #14) > (In reply to Michał Górny from comment #13) > > Is there a way we had something like 'foo /etc/local.d/*.start' that would > > run all the scripts in lexical order. > > I guess a workaround would be to use "ls" as I remember it had some options > to tweak the order, but no idea about how to do that with "bash" directly :S Well, shell glob expansion gives lexical order already, so that's not a problem. The problem is to get systemd to expand them, and to find a command that runs it as expected. > Regarding the rc.local thing (thanks a lot for taking care! :D), I was > considering usage of "Type=idle": > http://www.freedesktop.org/software/systemd/man/systemd.service.html > > But I am not sure how will it work as, per documentation, it should behave > as "simple" :/ That looks like something that would delay the execution until system gets idle. I don't think that's what the user expects.
Well, usually rc.local stuff is run at the end of boot, not sure how a similar behavior could be done with systemd, maybe depending on some target (like graphical.target) or similar, but I don't know :| (I am just reviewing available targets)
(In reply to Pacho Ramos from comment #17) > Well, usually rc.local stuff is run at the end of boot, not sure how a > similar behavior could be done with systemd, maybe depending on some target > (like graphical.target) or similar, but I don't know :| (I am just reviewing > available targets) Wasn'it it possible to just do 'After=*'?
I've added some testing 'gentoo-local.service' to gentoo-systemd-integration (live ebuild only at the moment). However, I'm not convinced about the form. The proper thing to do would be probably to use a generator to get a separate unit for each file in question. Otherwise, there's no systemd-y way to properly track failures of single units.
Ok, current git of gentoo-systemd-integration has a nice local.d generator. Please test that and I'll wrap up a release soon.
was done some days ago
