A:1h' , which makes sense under systemd 228.
> Kind regards,
> Ulrich Windl
--
Brian Reichert
BSD admin/developer at large
27;.
That looks like correct syntax, based on that online doc I found.
If that is correct syntax, does that mean this feature is not
supported by my version of systemd?
--
Brian Reichert
BSD admin/developer at large
les.d(5) for my
distro.
Can you provide a pointer to some doc explaining that directive?
> --
> Mantas Mikul??nas
--
Brian Reichert
BSD admin/developer at large
On Fri, Jan 31, 2025 at 10:45:50AM -0500, Brian Reichert wrote:
> > If you want to only consider modification time, specify it as something
> > like "mM:10d" ??? see "Age" in tmpfiles.d(5).
>
> I cannot find any reference to this modifier, in either that
gly.
But, no files have been clean out:
10-153-68-12:~ # ls -ldtr --full-time /home/foobar/tmp/example.* | wc -l
45
So, what did I do wrong?
I'm happy for any guidance anyone can provide.
--
Brian Reichert
BSD admin/developer at large
7; or
'prior PID has exited', then you can add that as a second command
in your ExecStop, to cause this stage to block until that has
occurred.
> --
> kelsey.cummi...@sonic.com sonic.net, inc.
> System Architect 2260 Apollo Way
> 707
u IPv6 2703923 0t0 TCP *: (LISTEN)
10-153-68-12:/home/webapp # kill -TERM 22011
> BR
> Silvio
--
Brian Reichert
BSD admin/developer at large
of my control.
For the record, many other sites seems to propose masking the 143 issue with
SuccessExitStatus=143
but's that's clearly bogus. :/
I wish there was a systemd-pure way of implementing 'block until
PID exits'.
--
Brian Reichert
BSD admin/developer at large
roup=webapp
WorkingDirectory=/home/webapp
EnvironmentFile=/home/webapp/webapp.env
PassEnvironment=JAVA_HOME JDK_JAVA_OPTIONS JAR_FILE JAR_ARGS SERVER_PORT
ExecStart=/home/webapp/jdk/bin/java -jar ${JAR_FILE} ${JAR_ARGS}
ExecStop=/usr/bin/curl -X POST localhost:${SERVER_PORT}
ly did anything if it had Type=simple.
>
> Of more interest to you is logrotate.service, which is Type=oneshot.
(Confirmed, it is.)
> If it was Type=simple, your unit would be started before the logrotate
> command completed, which is probably not what you want.
Thanks for all o
your script completes. Type=simple is expected to be used for a
> service that doesn't exit under normal conditions.
Thanks for the additional feedback; I don't see the harm in trying.
How, forensically, would I see the difference between 'simple' and
'oneshot'
On Thu, Apr 11, 2024 at 11:14:20AM -0400, Brian Reichert wrote:
> Let me wrap up some testing, and I'll report back if all is successful.
I failed to report back; everything is working as I needed!
I appreciate everyone's help here.
For the record, my new service:
10-153-68-34
; This is also needed because otherwise the Requires directive does not
> work as intended.
That does seem to cause the correct behavior! Thanks!
Let me wrap up some testing, and I'll report back if all is successful.
--
Brian Reichert
BSD admin/developer at large
ingPriority=7
Environment=HOME=/root
10-153-68-34:~ # cat /etc/systemd/system/post-logrotate.service
[Unit]
Description=Activities after logrotation
Requires=logrotate.service
[Service]
Type=simple
ExecStart=/usr/bin/logger 'XXX post log rotation'
[Install]
WantedBy=logrotate.serv
e.log
-rw-r--r-- 1 root root 1607975 2024-04-10 16:57:55.094420531 -0400
/var/log/logrotate.log
Hopefully someone here can assure me this is just due to an artifact
of bookkeeping. I'm specifically trying to avoid doing any work
while logrotate is running.
That I got even this far is really great,
systemd/system/logrotate.service.wants/post-logrotate.service
lrwxrwxrwx 1 root root 42 2024-04-10 15:26:19.187115411 -0400
/etc/systemd/system/logrotate.service.wants/post-logrotate.service ->
/etc/systemd/system/post-logrotate.service
--
Brian Reichert
BSD admin/developer at large
On Wed, Apr 10, 2024 at 10:21:32PM +0300, Andrei Borzenkov wrote:
> On 10.04.2024 22:04, Brian Reichert wrote:
> > [Install]
> > WantedBy=logrotate.service
> >
>
> Links in [Install] section are created by "systemctl enable".
I could have sworn I did thi
On Wed, Apr 10, 2024 at 09:06:09AM -0600, Dan Nicholson wrote:
> On Wed, Apr 10, 2024 at 8:50???AM Brian Reichert wrote:
> >
> > My current service file:
> >
> > [Unit]
> > Description=Activities after logrotation
> >
> > Requires=logrotate.serv
Wants=logrotate.service
After=logrotate.service
[Service]
#Type=oneshot
Type=simple
ExecStart=/usr/bin/logger 'XXX post log rotation'
[Install]
WantedBy=timers.target
--
Brian Reichert
BSD admin/developer at large
persons or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and destroy any copies of
> this information. [ImprivataV12018]
--
Brian Reichert
BSD admin/developer at large
ld
block until some resource is consumed (network port opened, lock created,
whatever).
Perhaps not the most efficient, but that's how I've enforced 'really
up'.
> Ted
--
Brian Reichert
BSD admin/developer at large
te your feedback on the matter, nonetheless.
--
Brian Reichert
BSD admin/developer at large
On Fri, Nov 11, 2022 at 08:02:00AM +0100, Ulrich Windl wrote:
> >>> Brian Reichert schrieb am 10.11.2022 um 23:04 in
> Nachricht <20221110220426.ga17...@numachi.com>:
> > I've managed to hose a SLES12 SP5 host; it starts to boot, then hangs.
>
> And what did
eth0 up
> ip addr add 192.168.1.55/24 dev eth0
> ip route add default via 192.168.1.1
These, in isolation, are useful notes. It's been way too many years since
I had to rescue a failing-to-boot Linux server...
> --
> Mantas Mikul??nas
--
Brian Reichert
BSD admin/developer at large
hen I try to start networking with 'systemctl', I see this error:
systemd "failed to connect to bus; No such file or directory"
What can I do to minimally bring up the networking service? I don't even
have any network devices at this point...
--
Brian Reichert
ything under a single bond0
interface, so a) no software had to guess a NIC name, and b) in the
case of physical cabling, they would all Just Work.
This was work done in my kickstart file, and worked through many
releases of Red Hat and CentOS.
I adopted this tactic as Dell kept switching up how t
can confirm that putting IgnoreSIGPIPE=false under
[Service] indeed allows my example to work correctly.
--
Brian Reichert
BSD admin/developer at large
ing quickly.
pheonix:~ # systemctl daemon-reload
pheonix:~ # systemctl start random_str
Let me know if there are any other details of my environment that
would be helpful here.
--
Brian Reichert
BSD admin/developer at large
On Wed, Oct 16, 2019 at 07:43:10AM +, Zbigniew J??drzejewski-Szmek wrote:
> On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote:
> > I initiated an unsubscribe from this web page:
> >
> > https://lists.freedesktop.org/mailman/options/systemd-devel
&g
address rejected: User unknown in local recipient table
Giving up on 131.252.210.177.
What steps should I be taking?
--
Brian Reichert
BSD admin/developer at large
___
systemd-devel mailing list
systemd-devel
On Wed, Aug 14, 2019 at 04:19:46PM +0100, Simon McVittie wrote:
> On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote:
> Doesn't daemonize(1) make stdin, stdout and stderr point to /dev/null,
> instead of closing them?
Looking at the source, yes, it does.
> Ex
bsequently wants.
> Lennart
>
> --
> Lennart Poettering, Berlin
--
Brian Reichert
BSD admin/developer at large
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
as invoked, and found a pattern
of invocations I was able to backtrack to the cronjob.
> Zbyszek
--
Brian Reichert
BSD admin/developer at large
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ace=desc' (Trace all
file descriptor related system calls.)
- Choose to focus on a single descriptor; when I passively notice
that '19' has been reused a couple of time, stop the trace.
That should give me a smaller trace to analyze.
> Zbyszek
--
Brian Reicher
On Wed, Jul 31, 2019 at 12:36:41AM +0300, Uoti Urpala wrote:
> On Tue, 2019-07-30 at 14:56 -0400, Brian Reichert wrote:
> > I see, between 13:49:30 and 13:50:01, I see 25 'successful' calls
> > for close(), e.g.:
> >
> > 13:50:01 close(19)
On Thu, Jul 11, 2019 at 08:35:38PM +, Zbigniew J??drzejewski-Szmek wrote:
> On Thu, Jul 11, 2019 at 10:08:43AM -0400, Brian Reichert wrote:
> > Does that sound like expected behavior?
>
> No, this shouldn't happen.
>
> What I was trying to say, is that if you have
7;ll see what I can get from this.
In my prior email, I showed how some of the connections were
hours/days old, even with no connecting peer.
Does that sound like expected behavior?
> HTH,
> Zbyszek
--
Brian Reichert
BSD admin/developer at large
__
t root 64 2019-07-08 15:12:04.725350882 -0400 71 ->
socket:[54064]
> > Is my guess about CONNECTIONS_MAX's relationship to /run/systemd/private
> > correct?
>
> Yes. The number is hardcoded because it's expected to be "large
> enough". The connection cou
pparently came from the mailing list software,
and I did not realize that until I hit 'reply':
Date: Tue, 9 Jul 2019 11:21:13 +0100
From: systemd-devel@lists.freedesktop.org
To: Brian Reichert
Subject: OFFLIST Re: [systemd-devel] systemd's connections to
/run/systemd/priva
at they've adjusted it at least twice, but never went
so far as to make it a tunable in a config file somewhere is
worrisome.)
> Just report a bug for people to
> solve.
I wanted to avoid calling it a 'bug' report, as I wanted to establish
what expected behavior is.
But, your
On Tue, Jul 02, 2019 at 09:57:44AM -0400, Brian Reichert wrote:
> At $JOB, on some of our SLES12 boxes, our logs are getting swamped
> with messages saying:
>
> "Too many concurrent connections, refusing"
>
> It's hampering our ability to manage services, e.g
ver time.
- The CONNECTION_MAX constant is hard-coded, and it gets increased
every few months/years, but never seems to be expressed as something
you can set in a config file.
- I don't know what tunables affect the lifetime/culling of those
connections.
I have a hypothesis that t
42 matches
Mail list logo
