Re: [systemd-devel] --luks-offline-discard option has no effect on systemd-homed
On 7/29/21 4:48 AM, Lennart Poettering wrote: On Sa, 17.07.21 23:55, Gibeom Gwon (gb.g...@stackframe.dev) wrote: Hello, I'm trying to create a systemd-homed based user, there is a problem with --luks-offline-discard option. According to homectl(1), if this option is true, home directory loopback file is minified on logout. But in my case it's not at all. Here is my executed command and output. I thought I had fixed that issue. Which systemd version is this? Lennart -- Lennart Poettering, Berlin I tested again with current systemd-stable repo and it worked as a charm. Is the fix backported after 249 release? Thanks, Gibeom Gwon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] --luks-offline-discard option has no effect on systemd-homed
On Sa, 17.07.21 23:55, Gibeom Gwon (gb.g...@stackframe.dev) wrote: > Hello, > > I'm trying to create a systemd-homed based user, there is a problem with > --luks-offline-discard option. According to homectl(1), if this option is > true, > home directory loopback file is minified on logout. But in my case it's not > at all. Here is my executed command and output. I thought I had fixed that issue. Which systemd version is this? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Do Systemd service have limitation w.r.t IPC on forked process
On Mi, 28.07.21 22:17, Stiju (stiju.e...@gmail.com) wrote: > Hi, > I have a templated service and socket, for my program. > thou may not be relevant here , socket is written for inetd (ie FD 0 and 1) > the service type is put as "simple" in systemd configuration, > the service spawns many processes in some flows ( fork + execv ) . > the spawned process opens , IPC connection ( normal socket to another > system ), the process is killed by systemd. > is this expected? Consider enabling debug logging in PID 1. It logs about everything it kills then, and the logs should explain why. "systemd-analyze log-level debug" is the command to do that during runtime. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem : service ( systemd )
On Do, 22.07.21 20:54, Webstrucs (webstr...@gmail.com) wrote: > What command do I use or how do I clean, delete or delete services that no > longer exist and are not found from the memory, as I believe that this is > influencing the activation of services I add, follow the attached terminal > print: Typically your package manager does this automatically for you when you remove the package that contains the unit file. The usual approach is to issue "systemctl disable --now …" on the unit files before removing them, to ensure the units are stopped and disabled. This will implicitly then do a "systemctl daemon-reload" for you, too. You can also do that part manually, maybe after you actually removed the unit files from disk. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Do Systemd service have limitation w.r.t IPC on forked process
Hi,
I have a templated service and socket, for my program.
thou may not be relevant here , socket is written for inetd (ie FD 0 and 1)
the service type is put as "simple" in systemd configuration,
the service spawns many processes in some flows ( fork + execv ) .
the spawned process opens , IPC connection ( normal socket to another
system ), the process is killed by systemd.
is this expected?
Strace of the killed process shows
*ioctl(4, FIONBIO, [0]) = 0write(0, "[112] [IpcIO_Recv] (2 4 0x1b335a0 4)
[CRYPT]\n", 45) = 45write(0, "[280] BIO[0x1b32770]:read(4, 5) - socket
fd=4\n", 46) = 46read(4, 0x1b60533, 5) = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1,
si_uid=0} ---+++ killed by SIGTERM +++*
Same issue is not seen for flows where fork+ execv is not there ( ie execv
flows and one where we dont load any process)
Socket file looks like below :
*[Unit]Description=PartOf=my.service*
*[Socket]ListenStream=Accept=yes*
*[Install]WantedBy=sockets.target*
--
Stiju Easo
The unexamined life is not worth living for man.
Socrates, in Plato, Dialogues, Apology
Greek philosopher in Athens (469 BC - 399 BC)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Changing the Priority Level of Journald during Runtime
On Mi, 28.07.21 10:02, Andreas Krueger (andreas.krue...@fmc-ag.com) wrote: > Hi Folks, > > I'm a programmer who has to realize a dynamic priority level for > Journald, i.e. the priority level for incoming messages that decide > whether they are stored in the journal shall be changeable at > runtime. As far as I know this is not directly supported by > Journald, I would like to use a trick to accomplish this: > > Each time the level is to be changed, the configuration value of > MaxLevelStore is changed accordingly and Jorunald is restarted by > command systemctl restart system-journald. Since this will take some > time, I ask myself, what will happen to messages that arrive during > this time? Are they gone or buffered and available after the > restart? The sockets that journald listens on are allocated outside of journald, before it is started, via the systemd-journald*.socket unit files. They also stay up while journald is restarted, and thus any messages queued in them will remain so. Thus restarting journald during runtime should be safe and won't lose you any messages. > Or is a dynamic priority level available in the meantime? It's not available right now. Please file an RFE issue on github so that we can look into it. Or provide a patch that adds it. We nowadays have the Varlink IPC API in journald, it should be pretty straight-forward adding this logic there. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fw: How to restart my socket activated service safely ?
Hi, Please remove my ID from list - Forwarded message - From: Arian van Putten To: Francis Moreau Cc: SystemD Devel Sent: Wednesday, 28 July, 2021, 01:44:23 pm ISTSubject: Re: [systemd-devel] How to restart my socket activated service safely ? If your service gracefully exits and flushes buffers on SIGTERM then no requests will be lost. (That means. Finish off processing any requests that have been accept()'d before exiting). Any requests you didn't accept() yet will simply queue up whilst the service is down and you pick up where you left off after restart. On Wed, 28 Jul 2021, 10:08 Francis Moreau, wrote: On Tue, Jul 27, 2021 at 11:12 AM Mantas Mikulėnas wrote: > > On Tue, Jul 27, 2021 at 10:10 AM Francis Moreau > wrote: > > > > Hello, > > > > During my application update, I want to restart my service which is > > activated by a socket but want to be sure that no request sent to my > > service will be missed. I also want to restart the socket too so > > systemd uses the latest version of the socket unit file. > > > > If I restart the socket when the service is still running then I get > > an error message: "rotor.socket: Socket service rotor.service already > > active, refusing." > > > > If I stop the service first and restart the socket then there's a > > short time frame where requests can be lost. > > The old socket has to be unbound before a new one can be put in its > place. Trying to keep the service alive (holding the old listener fd) > would just result in systemd not being able to bind a new socket with > the same address... (And even if that was possible, the old service > wouldn't be able to handle requests arriving on the new socket > anyway.) > > So whenever you restart a socket, there will *always* be a short time > frame where the old socket is closed but the new one is not yet > bound/listening. But as soon as the new one is listening, it'll start > queuing the requests even if the service isn't yet running (since it's > a socket-activated service after all) and the number of lost requests > should be minimal. Thank you for response. If the service only is restarted, will be there also requests that can be lost ? If the service is restarted then it's first stopped but in the meantime the socket unit should be listening for new requests... -- Francis ___ 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Changing the Priority Level of Journald during Runtime
Hi Folks, I'm a programmer who has to realize a dynamic priority level for Journald, i.e. the priority level for incoming messages that decide whether they are stored in the journal shall be changeable at runtime. As far as I know this is not directly supported by Journald, I would like to use a trick to accomplish this: Each time the level is to be changed, the configuration value of MaxLevelStore is changed accordingly and Jorunald is restarted by command systemctl restart system-journald. Since this will take some time, I ask myself, what will happen to messages that arrive during this time? Are they gone or buffered and available after the restart? Or is a dynamic priority level available in the meantime? Regards, Andreas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to restart my socket activated service safely ?
If your service gracefully exits and flushes buffers on SIGTERM then no requests will be lost. (That means. Finish off processing any requests that have been accept()'d before exiting). Any requests you didn't accept() yet will simply queue up whilst the service is down and you pick up where you left off after restart. On Wed, 28 Jul 2021, 10:08 Francis Moreau, wrote: > On Tue, Jul 27, 2021 at 11:12 AM Mantas Mikulėnas > wrote: > > > > On Tue, Jul 27, 2021 at 10:10 AM Francis Moreau > wrote: > > > > > > Hello, > > > > > > During my application update, I want to restart my service which is > > > activated by a socket but want to be sure that no request sent to my > > > service will be missed. I also want to restart the socket too so > > > systemd uses the latest version of the socket unit file. > > > > > > If I restart the socket when the service is still running then I get > > > an error message: "rotor.socket: Socket service rotor.service already > > > active, refusing." > > > > > > If I stop the service first and restart the socket then there's a > > > short time frame where requests can be lost. > > > > The old socket has to be unbound before a new one can be put in its > > place. Trying to keep the service alive (holding the old listener fd) > > would just result in systemd not being able to bind a new socket with > > the same address... (And even if that was possible, the old service > > wouldn't be able to handle requests arriving on the new socket > > anyway.) > > > > So whenever you restart a socket, there will *always* be a short time > > frame where the old socket is closed but the new one is not yet > > bound/listening. But as soon as the new one is listening, it'll start > > queuing the requests even if the service isn't yet running (since it's > > a socket-activated service after all) and the number of lost requests > > should be minimal. > > Thank you for response. > > If the service only is restarted, will be there also requests that can be > lost ? > > If the service is restarted then it's first stopped but in the > meantime the socket unit should be listening for new requests... > > -- > Francis > ___ > 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
Re: [systemd-devel] How to restart my socket activated service safely ?
On Tue, Jul 27, 2021 at 11:12 AM Mantas Mikulėnas wrote: > > On Tue, Jul 27, 2021 at 10:10 AM Francis Moreau > wrote: > > > > Hello, > > > > During my application update, I want to restart my service which is > > activated by a socket but want to be sure that no request sent to my > > service will be missed. I also want to restart the socket too so > > systemd uses the latest version of the socket unit file. > > > > If I restart the socket when the service is still running then I get > > an error message: "rotor.socket: Socket service rotor.service already > > active, refusing." > > > > If I stop the service first and restart the socket then there's a > > short time frame where requests can be lost. > > The old socket has to be unbound before a new one can be put in its > place. Trying to keep the service alive (holding the old listener fd) > would just result in systemd not being able to bind a new socket with > the same address... (And even if that was possible, the old service > wouldn't be able to handle requests arriving on the new socket > anyway.) > > So whenever you restart a socket, there will *always* be a short time > frame where the old socket is closed but the new one is not yet > bound/listening. But as soon as the new one is listening, it'll start > queuing the requests even if the service isn't yet running (since it's > a socket-activated service after all) and the number of lost requests > should be minimal. Thank you for response. If the service only is restarted, will be there also requests that can be lost ? If the service is restarted then it's first stopped but in the meantime the socket unit should be listening for new requests... -- Francis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
