Re: [arch-general] On /etc/conf.d deprecation
On Sun, Dec 09, 2012 at 04:01:08AM +0200, Dimitrios Apostolou wrote: Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Thanks in advance, Dimitris Every time I update I just check systemd-delta if a package I have changed updates. -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology pgpwnFlwHxxR0.pgp Description: PGP signature
Re: [arch-general] On /etc/conf.d deprecation
Dimitrios Apostolou wrote: Hello list, from a reply I got to a bug report (FS#32817, reply is private) I found out that configuration files in /etc/conf.d are deprecated and that the supported way is to replicate and customize service files. Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. So I'm curious to know why this mechanism was deprecated? Is it speed we gain by not including the EnvironmentFile directive in the systemd unit file? Is there some other reason I might be missing? Note that this is not an isolated request. At least FS#32354, FS#32336 and FS#32275 report the same for different packages. Note also that the systemd devs have stated that although the right way(tm) would be for all daemons to take their parameters from some config file of their own, using EnvironmentFile is an acceptable workaround for daemons that still take parameters from the command line. See: http://0pointer.de/blog/projects/on-etc-sysinit.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: [arch-general] On /etc/conf.d deprecation
The issue with /etc/conf.d is that it's Arch-specific. There are still a lot of cases where the packages themselves still provide the units, but there is a push to get them upstream whenever possible to remove a lot of burden from the packagers, and share more work between distributions.
Re: [arch-general] On /etc/conf.d deprecation
On Sat, 8 Dec 2012, Curtis Shimamoto wrote: On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think? Dimitris
Re: [arch-general] On /etc/conf.d deprecation
On 12/09/12 at 05:23pm, Dimitrios Apostolou wrote: On Sat, 8 Dec 2012, Curtis Shimamoto wrote: On 12/09/12 at 04:01am, Dimitrios Apostolou wrote: Imagine that in /usr unit file the daemon is being called as binary -d. So I create the /etc unit file that supersedes it and calls it as blah -d -n1. Then the package gets updated and the /usr unit file changes to binary -d --lock=/whatever/path. As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called binary -d --lock=/whatever/path $BLAH_ARGS there would have been no such problem. Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think? Dimitris Yeah, I wrote back shortly after I sent that mentioning that it really wouldn't work, after I had thought it through a bit. I am not sure what you mean by heavyweight solution. If what you mean is that is will have to check for and then source a secondary file of the same name, I really don't think this would matter as it only has to do it once. Also, this seems like it is probably nearly the same amount of work for the system as sourcing a configuration file. Could you explain what you mean by heavyweight? I do agree with the fact that things should move towards following upstream, and the use of conf.d specifically should be deprecated. That doesn't necessarily mean that I think that you, the user, should not be able to create a config file on your own to source and use in the service. Personally, I have only made use of the .include feature once, and for something very simple. This issue of yours has made me think that it might be neat if there was a service variable to append to the ExecStart line. Thus making the .include feature more robust, as you could add to instead of replacing the actual command. -- Curtis Shimamoto sugar.and.scru...@gmail.com
Re: [arch-general] harddisk suspending far to often
Am 09.12.2012 18:55, schrieb Leonid Isaev:
On Sat, 08 Dec 2012 21:48:54 +0100
G. Schlisio g.schli...@dukun.de wrote:
[...]
how can i get to know, why this is happening, and maybe stop it?
I suspect the issue is in pm-utils' pm-powersave script which executes power
saving hooks, and is in turn being called by upower. But to be sure we need to
see your pm-utils configuration (in /etc/pm) and and /etc/Upower/Upower.conf...
/etc/pm/ contains conf.d/, power.d/ (both empty) and sleep.d/ (contains
90alsa, not doing much apart aplay). upower [0] contains a
RunPowersaveCommand=true, does that include APM=1 setting?
what curtis said about expected behavior and default settings, can those
be altered somewhere?
my /usr/lib/systemd/system-sleep/notify-upower.sh contains some call of
upower{,.resuming} via dbus.
what irritates me is that i experience this after last update, and never
before.
[0] my upower.conf:
[UPower]
SleepTimeout=1000
AllowHibernateEncryptedSwap=true
RunPowersaveCommand=true
EnableWattsUpPro=true
PollDockDevices=false
IgnoreLid=false
Re: [arch-general] [arch-dev-public] syslinux 5.00 in [testing]
On 12/08/2012 10:59 AM, Matthew Gyurgyik wrote: On 12/08/2012 06:37 AM, Tobias Powalowski wrote: Hi, seems syslinux changed some things more than I expected, could thomas or gerado look at the changes? http://www.syslinux.org/archives/2012-December/018747.html I don't have time this afternoon. If it keeps broken, I'll remove it this evening from testing repository. greetings tpowa The default modules that we place into /boot (menu.c32 vesamenu.c32 chain.c32 hdt.c32 reboot.c32 poweroff.com) depend on libutil_com.c32, libcom32.c32, libmenu.c32, libcom32gpl.c32 (new with syslinux 5.0) The syslinux-install_update script will need to be updated to include these extra modules. I will provide a patch in the next day or two, since I'm the original author. Simply adding the new modules to the script should work, but I want to test the following (thus the delay for the patch): 1) upgrade from syslinux4 - syslinux5 2) new install using syslinux 5 Regards, Matthew Gyurgyik Unfortunately I have been battling a cold all weekend and have not had time to look into this. Like I said the change should be fairly simple, and I will attempt to get a patch (tested) out by mid-week. Matthew Gyurgyik
Re: [arch-general] On /etc/conf.d deprecation
Tom, thank you very much for the extensive reply, I've been searching a lot for the reasoning you explained. On Sun, 9 Dec 2012, Tom Gundersen wrote: Speed is not a concern. The way things should ideally work, IMHO, is: Options related to the init-system, such as where the lock-file is located should be indicated as an option in ExecStart. The reason this makes sense is that it must match what is specifid in PIDFile=. The same goes for any other option that systemd requires to be a certain value to function correctly. All these options are things that the admin would not usually change. Agreed, as I pointed in my example such options should be hardcoded in ExecStart. Unfortunately this comes with the side-effect of missing any updates if ExecStart gets customised in custom unit file (I didn't know about systemd-delta, thanks to everyone who mentioned it). However, options that are unrelated to the init-system should not be specified in ExecStart=, but should be configured in the applications own configuration file. It has nothing to do with systemd, so for systemd to just stupidly read it from one location and pass it on to the program without touching it seems wrong on a conceptual level. More concretely, why we should avoid /etc/conf.d (and why all distros should discourage similar use of their own config directories): * it is distro-specific, so once we switch to unit files provided by upstream, we would have to change the location of the configuration file to whatever is used upstream (maybe the Debain location, or maybe the Fedora one, or maybe something else, it would probably differ from package to package). I think it is better to have a general rule saying we don't use /etc/conf.d with systemd, than package by package moving their config files around as things are upstreamed. Personally I believe all distros that switch to systemd will add their own twist to it. Distro-independant Unit files sounds like Utopia. In reality I expect unit files to be patched for various custom needs of different distros. But anyway if it is actually achieved it would be great. * most packages have their own configuration file where some, if not all, options can be configured. Having two locations for configuring the same options is not ideal, so we want to avoid that to the extent possible. One could imagine using /etc/conf.d for packages where not all command-line options can be configured in the config file. However, what do we then do when one day the config files are extended to deal with all the options? If we drop /etc/conf.d support we'll have the same problems as above: package by package changing behaviour. There are cases when using /etc/conf.d is necessary, but to the extent possible we should try to avoid it. Moreover, the first option should always be to petition upstream to add their own config files with the required options, and only if that is impossible add /etc/conf.d support. Just let me be specific with two examples that I use /etc/conf.d, and it may be more clear why they are still needed: 1) On a memory constrained system I use the following for spamassassin: SPAMD_OPTS=-c --min-spare 0 --max-children 1 -s local5. I don't think this can be customized by other means. 2) For the crond started service of sysstat, I keep all history with HISTORY= in /etc/conf.d/sysstat. I don't know if /etc/conf.d is being deprecated for everything or only for systemd started daemons, but this is a non-systemd example that makes good use of it. Thanks, Dimitris Cheers, Tom
Re: [arch-general] On /etc/conf.d deprecation
On Mon, Dec 10, 2012 at 12:46 AM, Dimitrios Apostolou ji...@gmx.net wrote: Personally I believe all distros that switch to systemd will add their own twist to it. Distro-independant Unit files sounds like Utopia. In reality I expect unit files to be patched for various custom needs of different distros. But anyway if it is actually achieved it would be great. So far this has not been necessary (afaik) for the projects that do provide unit files upstream. Of course, there are still a lot of projects that don't, so we will see what happens in the future. 1) On a memory constrained system I use the following for spamassassin: SPAMD_OPTS=-c --min-spare 0 --max-children 1 -s local5. I don't think this can be customized by other means. This seems like a typical example of something that the daemon itself should have support for reading from its own config files rather than relying on it being passed on the command-line. Rather than fixing this in Arch, I'd suggest contacting spamassassin and request support for these options (and any other) to be added to their config file. In the meantime I suggest patching the unit file locally, and revisit the issue if upstream reject the change. 2) For the crond started service of sysstat, I keep all history with HISTORY= in /etc/conf.d/sysstat. I don't know if /etc/conf.d is being deprecated for everything or only for systemd started daemons, but this is a non-systemd example that makes good use of it. It appears sysstat store their configuration file in /etc/conf.d, so this is not really a problem. -t
[arch-general] Concerning Secure Boot Support
For those of you who care (and you may not number very many): As it stands, Gummiboot doesn't support calling back to Matthew Garrett's shim and until this happens it won't work in secure boot mode. I'm not aware of Pierre Schmitz's reasoning for using Gummiboot as opposed to rEFInd, but if the official archiso is to boot on secure bootable machines, it'll have to either use rEFInd or Fedora 18's RC's GRUB2 (the current install media of Fedora 18 uses the latter). These are essentially the only two options until syslinux gets a stable EFI release and does the same sort of hardcoded shim support. Notice I said Fedora's, and not upstream's. Upstream GRUB2 doesn't support kernel verification against the MOK database yet so Fedora 18 is shipping a patched version. Assuming we weren't going to wait for GRUB2 to support secure boot, we could ship Fedora's bootloader instead or apply similar patchwork, but this goes against Arch philosophy and it might be easier to simply wait for upstream support. Regardless of what Arch does the decision will have to come from someone with much more authority on Arch's direction; either Pierre because he's the one rolling out the monthly iso or another developer because using non-vanilla software, even something as critical as a bootloader, isn't very Arch-like. Someone correct me if I'm wrong. Not only that, but setting up a system of signing kernels, modules (out-of-tree modules are a beast that haven't been worked out yet beyond self-signing), and GRUB2 as well as rEFInd (for those who choose to use a boot manager beyond their UEFI's) with openssl generated x509 certificates using either Fedora's pesign (what MJG recommends) or Ubuntu's sbsign (a similar too that I've used and can guarantee will work) is a bit of work on its own. Lastly, the shim itself needs to be pulled into [extra] and it should come with some script like shim-install which would simply rename the grub-efi binary as grubx64.efi and would place the shim in /boot/efi/EFI/BOOT/x86_64/, renaming it bootx64.efi. Not so difficult at all, but it's another thing to do. That's only the technical implementation, however. Documentation would be tricky considering every manufacturer designs their UEFI implementation a little bit differently; on my system, I was stumped until I realized that regardless of the shim being signed by Microsoft's key I had to actually specify in the interface that I wanted to trust that particular .efi file. One point of the shim is so that launching Linux on a new machine isn't anymore daunting than changing the boot device order (I wouldn't worry so much about this with Arch users, however) but if the user still has to muck about in firmware that is different for everybody, one of many purposes has been swiftly defeated. Anyway, that's pretty much everything that's keeping secure boot from coming to Arch Linux for now. Well, that, and the fact that no developer actually owns a UEFI machine with secure-boot support. We'll see what happens in the future, I suppose. Thoughts and comments are requested.
