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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
