Re: [systemd-devel] Conditionally reload a service from another service
1. decide on a global path like `/run/http/restart' 2. give your LE script access to write there 3. use a `.path' unit to trigger on the file above being created and triggering a one-liner that running as root restarts apache and deletes the file again This way your “run as root” is limited to that one, tiny script
Re: [systemd-devel] Fail to configure MaxFiles and MaxUse for systemd-journal-remote
> Jan 27 10:20:11 log-server systemd-journal-remote[949021]: > /etc/systemd/journal-remote.conf:18: Unknown key name ’MaxFiles’ in section > ’Remote’, ignoring. Because there is no key by that name? According to `man journald.conf' it’s either `SystemMaxFiles' or `RuntimeMaxFiles' depending on what you’re looking for.
Re: [systemd-devel] Antw: [EXT] SRe: VirtualBox VM as a unit failures
VBoxManage controlvm "$VM_NAME" acpipowerbutton Or run whatever is VBox's command to pause and save the VM state. Sure, writing out the memory state file(s) takes a while if you have several VMs with lots of memory assigned, but at least it's deterministic *and* you avoid yanking the rug out from underneath the VMs.
Re: [systemd-devel] Detecting when running under systemd
you want to check specifically whether stderr is tied to the journal, for which you can use JOURNAL_STREAM You are right, nice catch! (In addition to disabling the timestamps you should *at least* add message priority indicators as well, either by using SyslogLevelPrefix=, or by avoiding stderr entirely and using the syslog() API for logging – if not going all the way with sd_journal_send*().) It's an application written in crystal, so while it would be straight forward to either use the syslog API or write bindings for sd_journal_send, my logging requirements are basic (to put it mildly) and simply dumping to stderr works well enough when paired with the priority parsing provided by SyslogLevelPrefix. Thank you!
[systemd-devel] Detecting when running under systemd
Hi all, I have a small program that queries an external web API, massages the data and passes it off to something else. As I only need it to run during certain windows and I didn't want to have to bother with making sure it was alive, I am starting it using a systemd timer which is sufficiently flexible. All good and it's super nice to be able to "outsource" all that to systemd. My question is - what is the canonical way to detect that I'm running under systemd so that I can adjust accordingly? Currently I'm checking for the existence of the "_SYSTEMD_INVOCATION_ID" environment variable in order to change the logging function as the default logger includes a timestamp which is redundant when journald is picking it up. I'm also using LoadCredential for passing tokens but that just comes down to looking for the right file name where the CREDENTIALS_DIRECTORY variable points, so that really isn't systemd specific and there is a fallback in case that isn't set or the directory/file doesn't exist anyway. I could of course also add a --systemd flag that toggles this but if I can do "TheRightThing(tm)" out of the box, why not. Regards, Peter
Re: [systemd-devel] timer "OnBootSec=15m" not triggering
[Install] WantedBy=timer.target It's supposed to be timers.target
Re: [systemd-devel] Antw: Re: [systemd‑devel] [EXT] Proposal to extend os‑release/machine‑info with field PREFER_HARDENED_CONFIG
To what extent a machine is locked down is a policy choice. There are already loads of tools available to manage policy so this really doesn't belong here and if you want to ensure that your fleet of machines are locked down through something like PREFER_HARDENED_CONFIG=1, you're going to need tools to manage *that* anyway. Then why not use the same tool(s) to simply manage the machines? And what exactly should it do? I'm sorry, but what is "it" in this context? Also: Do you really believe in "one size fits all" security-wise? Of course not. I think distributions should be providing sane defaults and everything else is a policy decision that whoever is responsible for a particular machine would then implement using one of the many tools that already exist. If (at all), then the parameter should be "SECURITY_POLICY=name" (where name is one of the predefined policies). One of the ideas behind the systemd project was to provide plumbing for all distributions that would provide some level of standardization and each distribution not having to reinvent the wheel. Introducing something like SECURITY_POLICY=woot which inevitably would mean different things from distribution to distribution and even from package to package within a distribution doesn't seem like it would further that goal. And most of all, selecting a different policy does not make it a different OS. For sure, but I don't quite see which point you're trying to make.
Re: [systemd-devel] [EXT] Proposal to extend os-release/machine-info with field PREFER_HARDENED_CONFIG
I think os-relesase describes the operating system, not policies. You are right. Perhaps machine-info would be a better fit than os-release. To what extent a machine is locked down is a policy choice. There are already loads of tools available to manage policy so this really doesn't belong here and if you want to ensure that your fleet of machines are locked down through something like PREFER_HARDENED_CONFIG=1, you're going to need tools to manage *that* anyway. Then why not use the same tool(s) to simply manage the machines? It's 2022 - nobody should be doing this by hand.
Re: [systemd-devel] Block systemd from adding new services
This is admittedly slight off-topic but as you seem to be maintaining servers available on the public internet, this really affects us all. What you are asking for is the equivalent of "which brand of band-aid should I use for whenever I get hit by a bus". Human or bot doesnt' matter - if your machines keep getting rooted, *please* address *that*. Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Best practices for lots of similar units?
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? Solve this outside of systemd. Whatever configuration management tool you use should be able to process templates and create the required files. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WantedBy=default.target
Tomasz, sockets.target is rather odd for me. If I had (hypothetical) socket-activable service, which is only relevant in GUI environment, I would like its socket to be pulled in by graphical.target. Using sockets.target would let my hypothetical service to be available in text-only boot. Socket-activatable services are very useful across the board - for system and user level services running with and without a GUI as there is nothing GUI specific at all about them. And even if this hypothetical service was only useful in a GUI environment (for whatever reason), where would be the harm in having systemd register the socket in a non-GUI environment where presumable nothing would be trying to connect on the socket and thus nothing activates the service. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] my Ubuntu server sleep mode by Itself often
I am not sure if this is some grade A trolling or a massive language barrier issue but can someone who speaks french possibly reach out to Dorian and explain the purpose of the list? And if that doesn't change the behaviour we should simply block/ban him. -- Regards, Peter On 18-11-30 at 21:04, Dorian ROSSE wrote: Dear IT worker, Do you know why a old smart server return back to server mode from desktop mode want to sleep down often ? Thank you in advance to answer if you have an answer and to don’t be hungry if you think I Junk the systemd mailing list, Regards. Dorian ROSSE. ___ 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] systemd user unit - how to prepare environment?
How does this compare to man 5 environment.d ? You can use that too. Difference is mainly that user.conf is what systemd itself reads. So you are saying that DefaultEnvironment in user.conf will read immediately and therefore all services started by systemd will see that but since environment.d is processed by a generator, it might run later and therefore not all systemd started services will have the variables set? Or am I misunderstanding it? -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user unit - how to prepare environment?
Hi, > So my question is, where to init variables for user units? > I woluld like to have possiblity to set them as not only as fixed > strings > > (i.e. I would to have PATH=$PATH:xxx) You can add them to ~/.config/systemd/user.conf in the Environment= field in the [Manager] section, see systemd-system.conf(5).x How does this compare to man 5 environment.d ? -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: hi
Hi, im getting a error everytime when i try to start my httpd into my server This isn't a systemd issue but related to Apache httpd and your distribution. Please get in touch with them instead. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Graphical session targets as standard
Reindl, what problem needs to be solved? [root@srv-rhsoft:/usr/lib/systemd/system]$ ls | grep graphical we are talking about the *user* targets that will be activated by login managers, not the *system* targets. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting an unit in user mode for all users
Great point, I noticed. I work-arounded that by making the unit wanted by dbus. Systemd already comes with units for this: - graphical-session.target - graphical-session-pre.target -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting an unit in user mode for all users
Thanks for your help. I guess the only way is by creating the symlink manually, isn't it? The global flag is your friend: systemctl enable --user --global name_of_unit -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dedup timers?
Hi, I have a number of timers that all look something like the following: The boilerplate for such small things is killing me. Is there a good technique to replace them with something simpler? Maybe transient timers? What will be the drawbacks of transient timers comparing to regular timers? From man systemd.time: The following special expressions may be used as shorthands for longer normalized forms: minutely → *-*-* *:*:00 hourly → *-*-* *:00:00 daily → *-*-* 00:00:00 monthly → *-*-01 00:00:00 weekly → Mon *-*-* 00:00:00 yearly → *-01-01 00:00:00 quarterly → *-01,04,07,10-01 00:00:00 semiannually → *-01,07-01 00:00:00 -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can a systemd --user instance rely on After= of systemd --system instance?
Hi, If I have a user service which needs to have the system database server available: How do I construct a proper depend? As Lennart was pointing out, the user and system instances do not know anything about each other, so you cannot. The 2 other options I can think of: a) Run a system service specifying your user id in User= b) Enable socket activation (if possible) on the system instance database. That way your user instance will simply wait on the socket until the server comes up. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Additional error details when resource limits are exceeded
Hi, Type=simple cannot detect when a service is ready. Systemd simply of teamviewerd but with service inter-dependencies this becomes important. Type=simple considers the service up immediatly thus triggering dependent service for immediate execution while Type=forking considers the service up only when appearance of the PIDFile signals so, and only then schedules starting dependent services. So, Type=forking is the only way to have synchronization points between service that depend on each other. In all fairness, the presence of a PID really doesn't say anything either about availability. The only way to be sure is to use Type=Notify with a cooperating daemon. I haven't looked at the code, but again, if systemd knows that some limit is being exceeded, wouldn't it make sense to say which one? Probably yes... Maybe Lennart pays attention? Otherwise that might be fun xmas project for an enterprising young coder! -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Additional error details when resource limits are exceeded
Hi, [Service] Type=forking PIDFile=/run/teamviewerd.pid ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -d Restart=on-abort StartLimitInterval=60 StartLimitBurst=10 The alternative ExecStart I'm using: ExecStart=/opt/teamviewer10/tv_bin/teamviewerd -f And then you can get rid of PIDFile and Type. Resource limit exhaustion (in kernel sense) is usually easily to be found in dmesg. I think this wasn't the case here. I propose it was just because of StartLimitBurst? I haven't looked at the code, but again, if systemd knows that some limit is being exceeded, wouldn't it make sense to say which one? -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Additional error details when resource limits are exceeded
Hi, it turns out that the teamviewer daemon wasn't behaving correctly and double-forked before the PID file was written. Fixed by running it as Type=simple and in the foreground. It however, still doesn't change anything about the error message, which is just plain wrong in this case as opposed to unhelpful. Is there anything I can provide or do to help with this? -- Regards, Peter On 15-12-03 at 12:42, Peter Hoeg wrote: Hi, I'm using systemd 228-3 on Arch Linux (up-to-date as of time of writing) and am having an issue figuring out why a particular service fails to run. The message I am getting is "Job for teamviewerd.service failed because a configured resource limit was exceeded." but how do I figure out WHICH resource limit is causing this? What I have tried: 1) checking "systemctl status teamviewerd.service" and "journalctl -xe" as mentioned by systemd 2) bumping up the various LimitXXX configuration items in the unit file 3) adding Environment=SYSTEMD_LOG_LEVEL=debug to the unit file All in vain. However running the ExecStart line manually using sudo works fine. The fact that this is teamviewer really doesn't matter - it just happened to be where I noticed it, but providing additional info on this error would be very welcome. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Additional error details when resource limits are exceeded
Hi, I'm using systemd 228-3 on Arch Linux (up-to-date as of time of writing) and am having an issue figuring out why a particular service fails to run. The message I am getting is "Job for teamviewerd.service failed because a configured resource limit was exceeded." but how do I figure out WHICH resource limit is causing this? What I have tried: 1) checking "systemctl status teamviewerd.service" and "journalctl -xe" as mentioned by systemd 2) bumping up the various LimitXXX configuration items in the unit file 3) adding Environment=SYSTEMD_LOG_LEVEL=debug to the unit file All in vain. However running the ExecStart line manually using sudo works fine. The fact that this is teamviewer really doesn't matter - it just happened to be where I noticed it, but providing additional info on this error would be very welcome. -- Regards, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
