On Tue, 2020-07-28 at 16:13 +0200, Lennart Poettering wrote:
> On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote:
>
> > Further to my post about using the new mount table notifications in
> > systemd I'd like to start by posting a few patches for discussion
> > to
> > hopefully get a better
On Di, 28.07.20 12:12, Ian Pilcher (arequip...@gmail.com) wrote:
> On 7/28/20 9:44 AM, Lennart Poettering wrote:
> > Is the service short-lived? There's a race: if a process runs very
> > quickly and logs journald might process the message after the process
> > already exited, i.e. at a time where
On 7/28/20 9:44 AM, Lennart Poettering wrote:
Is the service short-lived? There's a race: if a process runs very
quickly and logs journald might process the message after the process
already exited, i.e. at a time where we can't read the cgroup off the
process anymore.
It is indeed a very short
On 7/28/20 11:07 AM, Mantas Mikulėnas wrote:
I'd create a single raidcheck.service that runs daily and calls a script
that itself determines which device to check, e.g. /dev/md$[dayofyear % 16].
That is the approach that I'm taking, although it means a fair bit of
work. I need to parse a confi
I'd create a single raidcheck.service that runs daily and calls a script
that itself determines which device to check, e.g. /dev/md$[dayofyear % 16].
On Sun, Jul 26, 2020, 22:56 Ian Pilcher wrote:
> My NAS has 16 MD RAID devices. I've created a simple service
> (raidcheck@.service) that will tr
I am still totally unable to make use of repart when the root is volatile... Is
this intended, or not ? I know volatile-root service changes where the
sysroot.mount ends up, for overlayfs, but this prevent repart from working
because it can't find the underlying root block device anymore but onl
On Fr, 24.07.20 00:12, Roman Odaisky (r...@qwertty.com) wrote:
> Hi All,
>
> Suppose I want to run a number of similar services that all require the same
> boilerplate. How to avoid repeating myself when creating unit files?
Three options:
1. Use templating, works great if you have a single para
On Fr, 24.07.20 16:44, John Ioannidis (systemd-de...@tla.org) wrote:
> I'm trying to be a good boy and migrate as much functionality as I can to
> networkd.
>
> I'm happy with how networkd manages "internal" and "external" interfaces
> and vlans for just setting up IPv4 addresses, but I still find
On Sa, 25.07.20 17:22, Ian Pilcher (arequip...@gmail.com) wrote:
> I have a simple (non-forking) one-shot service that logs messages via
> syslog. These messages are not being "associated" with the service
> unit. I.e., they don't show up if I use journalctl's -u option
> (although they are in t
On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote:
> Further to my post about using the new mount table notifications in
> systemd I'd like to start by posting a few patches for discussion to
> hopefully get a better understanding of some aspects of how systemd
> mount unit state handling w
On So, 26.07.20 14:56, Ian Pilcher (arequip...@gmail.com) wrote:
> My NAS has 16 MD RAID devices. I've created a simple service
> (raidcheck@.service) that will trigger a check of the RAID device
> identified by the argument. E.g., 'systemctl start raidcheck@md1' will
> trigger the check of md1
On Di, 28.07.20 15:50, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> Hi!
>
> I have a case where my main process has two success exit codes, and
> I'd like to run the ExecStartPost only if the exit code was
> 0. However as I understand the documentation any exit code listed
> for Succe
Hi!
I have a case where my main process has two success exit codes, and I'd like to
run the ExecStartPost only if the exit code was 0. However as I understand the
documentation any exit code listed for SuccessExitStatus is considered
successful. I also listed the alternative success return code
Am 28.07.20 um 12:05 schrieb Lennart Poettering:
> On Di, 28.07.20 02:02, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>> Hi
>>
>> is this a kernel limitation or could systemd act better by *not* mount
>> /boot unconditional becasue of the inherited /boot/efi?
>
> I think the kernel could th
On Di, 28.07.20 02:02, Reindl Harald (h.rei...@thelounge.net) wrote:
> Hi
>
> is this a kernel limitation or could systemd act better by *not* mount
> /boot unconditional becasue of the inherited /boot/efi?
I think the kernel could theoretically support that, but we don't
right now, and I am not
15 matches
Mail list logo
