On 08.04.2014 18:21, "Jóhann B. Guðmundsson" wrote:
>
> On 04/08/2014 12:10 PM, poma wrote:
>> [Service]
>> EnvironmentFile=/etc/sysconfig/netconsole-zbyszek
>> RemainAfterExit=yes
>> ExecStart=/sbin/modprobe netconsole netconsole=@/${SRC_DEV},@${DST_IP}/
>> ExecStop=/sbin/modprobe -r netconsole
>
> On popular demand of me providing more detailed criticism than just
> "this is rubbish" as well as I got somewhat myself to blame for poorly
> written unit files given that the best practical of unit writing resides
> in my head by the experience of migrating so many legacy sysv initscript
> to native systemd units and driven half way to insanity while doing so.
>
> So let me clarify why I think this is rubbish.
>
> For the first you are using the wrong Type for that unit file as in the
> build in default which is Type=simple for the purpose of this unit along
> with RemainAfterExit=yes in it when you should be using Type=oneshot unit
>
> Secondly let me start with "EnvironmentFile=" in 99.9% times this is
> entirely unnecessary since what is contains within those environment
> files are configuration changes to daemon startup for daemons that are
> so poorly written they dont support reading configuration files on startup.
>
> Now on the 21 century within the systemd universe, administrators are (
> supposted to be ) using drop in configuration snippets that contain that
> administrator overwrite to overcome that daemons lack of reading
> configuration file in the relvant unit's .d configuration directory that
> resides under /etc/systemd/systemd/ or better yet developers that
> maintain and own that component should be rewriting it's daemon to
> support parsing configuration file(s) at startup.
>
> If you happen to be using the 00.1% components that actually has valid
> usecase for using "EnvironmentFile=" definition in type service units
> these days, then those environment files should reside in a components
> .d directory under /etc to make them cross distributional not under
> /etc/sysconfig or under /etc/default and hopefully one day I will have
> manage to remove all traces and usages of environmental files in
> /etc/sysconfig in Fedora ( but achieving that is more like David vs
> Goliath or Jóhann vs Red Hat.) as well as others doing the same in their
> distribution of choice
>
> Thirdly under no circumstances and I mean NEVER should you be loading
> and unloading modules from within a systemd unit YES NEVER!!!
>
> If you need for one reason or another to load module you do so by
> placing .conf configuration snippet in /etc/modules-load.d which tell
> the system which kernel modules to load but fact is if you actually need
> to load some module manually like this something is wrong since modules
> should be automatic loaded by PCI IDs, USB IDs, DMI IDs or similar
> triggers encoded in the kernel modules themselves these days.
>
> And you place .conf configuration snippet in /etc/modprobe.d which
> contains which parameters the kernel module uses when loading.
>
> Which leads to that service section being rubbish as well as the
> existence of that entire unit being o_O since the correct way ( always )
> when dealing with module and their option is what I described here above
> which leads to for netconsole being....
>
> /etc/modules-load.d/netconsole.conf
> # Load netconsole.ko at boot
> netconsole
>
> And
>
> /etc/modprobe.d/netconsole.conf
> # load netconsole options
> options netconsole netconsole=@192.168.1.2/enp1s2,@192.168.1.1/
>
> And since you are using netconsole you probably want to increase the
> logvel as well
>
> /etc/sysctl.d/10-netconsole.conf
> #raising loglevel from 7 to 8
> kernel.printk = 8 4 1 7
>
> JBG
What do you mean? African or European swallow?
poma
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
