Re: [systemd-devel] Guidance on automount/unmount for external powered devices
On Fri, 2021-03-12 at 23:00 +0100, Silvio Knizek wrote: > Am Donnerstag, dem 11.03.2021 um 11:00 + schrieb Patrick > O'Callaghan: > > 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 > Hi, > > I don't really understand your problem. Do you want to unmount the > backup drive whenever it's not in use? There is the mount option x- > systemd.automount,x-systemd.idle-timeout=5s (man systemd.mount) to > mount/unmount on demand. That's not the issue. I know I can automount/unmount and this is already working. However I also want to power down the external drive after unmounting, and power it up again before mounting. I have my own script to handle the power up/down and that also works. What I haven't managed to do is join those two elements together. > Can you share your fstab entry for your backup device? UUID=6cb66da2-147a-4f3c-a513-36f6164ab581 /raid ext4 rw,noauto,user,x-systemd.automount 0 0 As I said, this in itself works fine, as long as I leave the drive permanently powered on. 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
Am Donnerstag, dem 11.03.2021 um 11:00 + schrieb Patrick O'Callaghan: > 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 Hi, I don't really understand your problem. Do you want to unmount the backup drive whenever it's not in use? There is the mount option x- systemd.automount,x-systemd.idle-timeout=5s (man systemd.mount) to mount/unmount on demand. Can you share your fstab entry for your backup device? BR Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Q; syslog.socket dependency
>>> Michael Chapman schrieb am 12.03.2021 um 11:27 in Nachricht : > On Fri, 12 Mar 2021, Ulrich Windl wrote: > [...] >> > Can you think of a better way of wording the documentation? >> >> It depends: Do you consider /dev/log to be a "syslog socket"? >> (I'm not running rsyslog there) > > I'm not quite sure what you mean. If where you're going is "well > *obviously* syslog.socket refers to /dev/log", then ... maybe that's true, > but that ship has sailed. It simply doesn't, it means what it currently > means: the socket by which journald sends messages to some other syslog > daemon (if any). Then yes: Change the documentation. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Q; syslog.socket dependency
On Fri, 12 Mar 2021, Ulrich Windl wrote: [...] > > Can you think of a better way of wording the documentation? > > It depends: Do you consider /dev/log to be a "syslog socket"? > (I'm not running rsyslog there) I'm not quite sure what you mean. If where you're going is "well *obviously* syslog.socket refers to /dev/log", then ... maybe that's true, but that ship has sailed. It simply doesn't, it means what it currently means: the socket by which journald sends messages to some other syslog daemon (if any). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: Re: Antw: [EXT] Re: Q; syslog.socket dependency
>>> Michael Chapman schrieb am 12.03.2021 um 08:59 in Nachricht <90c9a861-f8cd-88d7-647-c6cc2a8ad...@very.puzzling.org>: > 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? It depends: Do you consider /dev/log to be a "syslog socket"? (I'm not running rsyslog there) Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Re: Q; syslog.socket dependency
On Fri, Mar 12, 2021 at 10:34 AM 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? https://www.freedesktop.org/wiki/Software/systemd/syslog/ > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
