[systemd-devel] Netconsole NG

[poma]

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, at 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