Re: [systemd-devel] Antw: [EXT] Re: Q; syslog.socket dependency
On Fri, 12 Mar 2021, Ulrich Windl wrote: > >>> Reindl Harald schrieb am 11.03.2021 um 16:23 in > Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>: > > > > > Am 11.03.21 um 12:17 schrieb Ulrich Windl: > >> Hi! > >> > >> I have a unit that uses logger, and I want to run it after syslog is > > available. So I added syslog.socket as dependency, but it fails: > >> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service > > syslog.service not loaded, refusing. > >> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket. > >> > >> Doesn't journald also "provide" syslog.socket? > >> > >> Manual says: > >> syslog.socket > >> The socket unit syslog implementations should listen on. All > >> userspace log messages will be made available on this socket. > > For > >> more information about syslog integration, please consult the > >> Syslog Interface[2] document > > > > you need no dependencies for logging ‑ journald is responsible for that > > and even available in the initrd > > So journald is not listening to the syslog socket? So how are messages sent to > the journal in a compatible way? > At least the manual page for syslog.socket is confusing then. So you say "the" syslog socket, but when you're running both journald and rsyslog, say, there are *two different syslog sockets*. It looks something like this: app | V /dev/log (systemd-journald-dev-log.socket) | V journald | | if ForwardToSyslog=yes | V /run/systemd/journal/syslog | (syslog.socket) | V rsyslog (syslog.service, symlinked to rsyslog.service) In other words, applications that expect something at /dev/log will work normally. Their messages sent to this socket will be sent to the journal. If the journal is configured to "forward to syslog", the message will sent to /run/systemd/journal/syslog ... and this will socket-activate some syslog implementation, such as rsyslog. I documentation for syslog.socket does essentially say this. The "syslog implementations" it's talking about means "rsyslog etc.", and "userspace log messages will be made available on this socket" means that the journal will send those messages to that socket. The linked Syslog Interface document also goes into more detail on it. Can you think of a better way of wording the documentation? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: Q; syslog.socket dependency
>>> Reindl Harald schrieb am 11.03.2021 um 16:23 in Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>: > > Am 11.03.21 um 12:17 schrieb Ulrich Windl: >> Hi! >> >> I have a unit that uses logger, and I want to run it after syslog is > available. So I added syslog.socket as dependency, but it fails: >> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service > syslog.service not loaded, refusing. >> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket. >> >> Doesn't journald also "provide" syslog.socket? >> >> Manual says: >> syslog.socket >> The socket unit syslog implementations should listen on. All >> userspace log messages will be made available on this socket. > For >> more information about syslog integration, please consult the >> Syslog Interface[2] document > > you need no dependencies for logging ‑ journald is responsible for that > and even available in the initrd So journald is not listening to the syslog socket? So how are messages sent to the journal in a compatible way? At least the manual page for syslog.socket is confusing then. Regards, Ulrich > > it's where early‑boot stuff comes from > ___ > systemd‑devel mailing list > systemd‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
On 11/03/21 7:39 pm, Alvin Šipraga wrote: Hi, On 3/11/21 11:01 AM, Reindl Harald wrote: Am 11.03.21 um 06:36 schrieb Amish: Hello So I have a wireguard setup which I use to connect to my server. But I do not connect to it daily, just once a in a while. I have setup wg0.netdev file and wg0.network file and all is working fine. But how do I set it up such that interface wg0 does not connect automatically but comes up only when I run: #networkctl up wg0 Effectively I want wireguard to connect/disconnect on demand given that wireguard runs directly in the kernel and has no single userland process what problem would you like to solve and why? Amish, I think you described your problem perfectly fine. It sounds like you want to add: [Network] ActivationPolicy=manual to your wg0.network file. More info here: https://www.freedesktop.org/software/systemd/man/systemd.network.html#ActivationPolicy= Thank you. I think this feature does not exist yet on current stable release. (I use Arch Linux systemd version 247.3) So as of now I can not try that setting. But just seeking a clarification about it. I think this feature will still bring up the interface wg0 via wg0.netdev file. But it will not assign IP address till it is activated manually. So VPN connection will still occur behind the scenes just that IP address and routes will not be setup. What I want is that it should not initiate VPN connection itself. i.e.: ActivationPolicy=manual for netdev file and not network file. But let me wait till the feature lands in Arch Linux and then I will test it. If you are only using the wireguard interface to connect to a specific IP or subnet (e.g. your server's), you can also fine-tune the routes in your .network file. That way you might be able to live with - and even prefer - the interface always being up. Yes thats what I have done, but I would still prefer a way to activate it on demand. Thanks, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
Hi, On 3/11/21 11:01 AM, Reindl Harald wrote: > > > Am 11.03.21 um 06:36 schrieb Amish: >> Hello >> >> So I have a wireguard setup which I use to connect to my server. >> >> But I do not connect to it daily, just once a in a while. >> >> I have setup wg0.netdev file and wg0.network file and all is working >> fine. >> >> But how do I set it up such that interface wg0 does not connect >> automatically but comes up only when I run: >> >> #networkctl up wg0 >> >> Effectively I want wireguard to connect/disconnect on demand > > given that wireguard runs directly in the kernel and has no single > userland process what problem would you like to solve and why? Seems like a perfectly mainstream use-case, no? Some people don't want to be hooked up to their VPN by default - particularly if it reroutes all their Internet traffic - so it makes sense to have this controlled manually. Amish, I think you described your problem perfectly fine. It sounds like you want to add: [Network] ActivationPolicy=manual to your wg0.network file. More info here: https://www.freedesktop.org/software/systemd/man/systemd.network.html#ActivationPolicy= If you are only using the wireguard interface to connect to a specific IP or subnet (e.g. your server's), you can also fine-tune the routes in your .network file. That way you might be able to live with - and even prefer - the interface always being up. Kind regards, Alvin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help: Program not run when rebooting
On Do, 11.03.21 15:53, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I tried to write a simple test unit that logs a message when the system is > going down (for reboot or halt), but it does not work: > --- > [Unit] > Description=Test Stop log entries > Documentation=man:logger(1) > DefaultDependencies=no > After=local-fs.target > Before=reboot.target halt.target shutdown.target poweroff.target kexec.target > Wants=local-fs.target This is contradictory: you want to be pulled in at shutdown, but are pulling in a target (and its dependencies) that are supposed to go away at shutdown. During shutdown your service will be started, but local-fs.target will go down. Now, After=/Before= declare the ordering when both the source and the target unit are started, or when both the source and the target unit are stopped. When one unit is started and another one stopped, then After=/Before= only have the effect that the unit to stop is stopped first, and the unit to start is started second, regardless if you actually use After= or Before=. See docs for more on this. So this means that local-fs.target has to go down first, then your service is started. Is this really what you want? Typically, if you want to run stuff durin shutdown you write a service that only has ExecStop= (and no ExecStart=) and pull that in at boot already. Doing this won't run any processes at boot, but just declare that this service is among those now managed by systemd to make sure we'll run ExecStop= eventually. > Mar 11 15:17:33 jeos1 systemd[1]: Stopped target Local File Systems. > Mar 11 15:17:33 jeos1 systemd[1]: Started Test Stop log entries. > Mar 11 15:17:33 jeos1 systemd[1]: Unmounting /usr/local... > > So I want to run my program much earlier; how to do that? If you want that your service's ExecStop= line runs *before* the local mount are shutdown, use something like this: [Service] ExecStop=… RemainAfterExit=yes Type=oneshot [Install] WantedBy=multi-user.target i.e. make it a regular service, with no special deps. The normal dep should be totally sufficient. But only declare a ExecStop= line. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Q; syslog.socket dependency
Am 11.03.21 um 12:17 schrieb Ulrich Windl: Hi! I have a unit that uses logger, and I want to run it after syslog is available. So I added syslog.socket as dependency, but it fails: Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service syslog.service not loaded, refusing. Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket. Doesn't journald also "provide" syslog.socket? Manual says: syslog.socket The socket unit syslog implementations should listen on. All userspace log messages will be made available on this socket. For more information about syslog integration, please consult the Syslog Interface[2] document you need no dependencies for logging - journald is responsible for that and even available in the initrd it's where early-boot stuff comes from ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Need help: Program not run when rebooting
Hi! I tried to write a simple test unit that logs a message when the system is going down (for reboot or halt), but it does not work: --- [Unit] Description=Test Stop log entries Documentation=man:logger(1) DefaultDependencies=no After=local-fs.target Before=reboot.target halt.target shutdown.target poweroff.target kexec.target Wants=local-fs.target #ConditionPathExists=/usr/bin/logger [Service] Type=oneshot TimeoutSec=5 RemainAfterExit=yes ExecStop=/usr/bin/logger -p user.notice -t LCD Stopping... [Install] WantedBy=reboot.target halt.target shutdown.target poweroff.target kexec.target #WantedBy=multi-user.target --- After a reboot I see: --- jeos1:~ # systemctl status log-stop-test.service ● log-stop-test.service - Test Stop log entries Loaded: loaded (/etc/systemd/system/log-stop-test.service; enabled; vendor p> Active: active (exited) since Thu 2021-03-11 15:38:42 CET; 9min ago Docs: man:logger(1) Tasks: 0 CGroup: /system.slice/log-stop-test.service Mar 11 15:38:42 jeos1 systemd[1]: Started Test Stop log entries. -- But no message was written when rebooting. That is, there is a message from systemd, but no log: Mar 11 15:17:33 jeos1 systemd[1]: Stopped target Local File Systems. Mar 11 15:17:33 jeos1 systemd[1]: Started Test Stop log entries. Mar 11 15:17:33 jeos1 systemd[1]: Unmounting /usr/local... So I want to run my program much earlier; how to do that? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
On Thu, Mar 11, 2021 at 12:01 PM Reindl Harald wrote: > > > Am 11.03.21 um 06:36 schrieb Amish: > > Hello > > > > So I have a wireguard setup which I use to connect to my server. > > > > But I do not connect to it daily, just once a in a while. > > > > I have setup wg0.netdev file and wg0.network file and all is working > fine. > > > > But how do I set it up such that interface wg0 does not connect > > automatically but comes up only when I run: > > > > #networkctl up wg0 > > > > Effectively I want wireguard to connect/disconnect on demand > > given that wireguard runs directly in the kernel and has no single > userland process what problem would you like to solve and why? > It might be the problem that I also have, which is that you don't always want certain destinations to be *permanently* routed through the tunnel -- e.g. you might have a VPN for 0.0.0.0/0 ::/0 (the whole internet) but don't actually want it to be active all the time, only when the need for it occurs. For example I have a tunnel through a USA server for websites that block Europe -- it routes 0/0 because I don't know the "wanted" destinations in advance, but at the same time I don't want the system to *default* to sending all my traffic halfway around the world and back, so it has to be "on demand". People are in a hurry to suggest "openvpn is meh, use wg-quick" and then the same people suggest "wg-quick is meh, use networkd" forgetting that A and C don't necessarily intersect. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd prerelease 248-rc3
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v248-rc3.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
* A concept of system extension images is introduced. Such images may
be used to extend the /usr/ and /opt/ directory hierarchies at
runtime with additional files (even if the file system is read-only).
When a system extension image is activated, its /usr/ and /opt/
hierarchies and os-release information are combined via overlayfs
with the file system hierarchy of the host OS.
A new systemd-sysext tool can be used to merge, unmerge, list, and
refresh system extension hierarchies. See
https://www.freedesktop.org/software/systemd/man/systemd-sysext.html.
The systemd-sysext.service automatically merges installed system
extensions during boot (before basic.target, but not in very early
boot, since various file systems have to be mounted first).
The SYSEXT_LEVEL= field in os-release(5) may be used to specify the
supported system extension level.
* A new ExtensionImages= unit setting can be used to apply the same
system extension image concept from systemd-sysext to the namespaced
file hierarchy of specific services, following the same rules and
constraints.
* Support for a new special "root=tmpfs" kernel command-line option has
been added. When specified, a tmpfs is mounted on /, and mount.usr=
should be used to point to the operating system implementation.
* A new configuration file /etc/veritytab may be used to configure
dm-verity integrity protection for block devices. Each line is in the
format "volume-name data-device hash-device roothash options",
similar to /etc/crypttab.
* A new kernel command-line option systemd.verity.root_options= may be
used to configure dm-verity behaviour for the root device.
* The key file specified in /etc/crypttab (the third field) may now
refer to an AF_UNIX/SOCK_STREAM socket in the file system. The key is
acquired by connecting to that socket and reading from it. This
allows the implementation of a service to provide key information
dynamically, at the moment when it is needed.
* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.
* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.
* The environment block of the manager itself may be configured through
a new ManagerEnvironment= setting in system.conf or user.conf. This
complements existing ways to set the environment block (the kernel
command line for the system manager, the inherited environment and
user@.service unit file settings for the user manager).
* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.
* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.
* Support has been added to systemd-cryptsetup for extracting the
PKCS#11 token URI and encrypted key from the LUKS2 JSON embedded
metadata header. This allows the information how to open the
encrypted device to be embedded directly in the device and obviates
the need for configuration in an external file.
* systemd-cryptsetup gained support for unlocking LUKS2 volumes using
TPM2 hardware, as well as FIDO2 security tokens (in addition to
Re: [systemd-devel] Q; syslog.socket dependency
On Thu, Mar 11, 2021, 13:17 Ulrich Windl wrote: > Hi! > > I have a unit that uses logger, and I want to run it after syslog is > available. So I added syslog.socket as dependency, but it fails: > Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service > syslog.service not loaded, refusing. > Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket. > > Doesn't journald also "provide" syslog.socket? > Yes but no. "Syslog.socket" is specifically for internal forwarding *from* journald to an external syslogd. What you're looking for (the journald *input* socket that's used by other programs) is actually "systemd-journald-dev-log.socket". Usually there should be no need to explicitly order against it, as normal services are already indirectly ordered after sockets.target as a whole. You'll only need an After if you're using DefaultDependencies=no. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Guidance on automount/unmount for external powered devices
On Thu, 2021-03-11 at 12:08 +, Dave Howorth wrote: > On Thu, 11 Mar 2021 11:00:04 + > Patrick O'Callaghan wrote: > > Unfortunately a system reboot always leaves it in the 'powered up and > > present in /dev/md' state, so I have to manually run the power-down > > script every time I reboot. This is inelegant. > > There may be better ways, but could you use an @reboot crontab entry > containing something like > > sleep 30 && do-whatever-you-need-to-issue-the-power-down I wasn't aware of the @reboot crontab option. Certainly a viable alternative, thanks. poc ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Guidance on automount/unmount for external powered devices
On Thu, 11 Mar 2021 11:00:04 + Patrick O'Callaghan wrote: > Unfortunately a system reboot always leaves it in the 'powered up and > present in /dev/md' state, so I have to manually run the power-down > script every time I reboot. This is inelegant. There may be better ways, but could you use an @reboot crontab entry containing something like sleep 30 && do-whatever-you-need-to-issue-the-power-down ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Q; syslog.socket dependency
Hi! I have a unit that uses logger, and I want to run it after syslog is available. So I added syslog.socket as dependency, but it fails: Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service syslog.service not loaded, refusing. Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket. Doesn't journald also "provide" syslog.socket? Manual says: syslog.socket The socket unit syslog implementations should listen on. All userspace log messages will be made available on this socket. For more information about syslog integration, please consult the Syslog Interface[2] document. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Guidance on automount/unmount for external powered devices
Apologies in advance if this is a FAQ, or if there is a more appropriate list for this question. I'm looking for a step-by-step guide for the following situation: I have an external 2-bay USB3 drive enclosure, configured as an MD Raid-1 device. This works without issue. I normally only use the device for nightly backups, so would prefer to leave it powered off until needed. I have scripts to power it up (creating the appropriate /dev/md entry and mounting the drive) and down (unmounting, removing the /dev/md entry and sending a magic signal to the USB device so it powers itself down after 30 minutes). Unfortunately a system reboot always leaves it in the 'powered up and present in /dev/md' state, so I have to manually run the power-down script every time I reboot. This is inelegant. I would much prefer to have this all handled automagically by systemd, but I need guidance on how to configure it. If it weren't for the power question, I know I can just use automount (and have managed to get this far on my own), but I don't know where or how to insert the power scripts. My reading of the systemd docs leads me to think that ExecStart/Stop might be the way, but where do I put this? Do I need a specific foo.mount unit (I'm currently using /etc/fstab)? poc ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
Am 11.03.21 um 06:36 schrieb Amish: Hello So I have a wireguard setup which I use to connect to my server. But I do not connect to it daily, just once a in a while. I have setup wg0.netdev file and wg0.network file and all is working fine. But how do I set it up such that interface wg0 does not connect automatically but comes up only when I run: #networkctl up wg0 Effectively I want wireguard to connect/disconnect on demand given that wireguard runs directly in the kernel and has no single userland process what problem would you like to solve and why? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
