I am setting up a computer with OpenSUSE 13.1 and want to run sendmail. I don’t, however, want to run amavis, cyrus, ldap or ypbind. They are not needed in our environment.
All of these services are, however, listed in /usr/lib/systemd/system/sendmail.service as requirements. Is the proper way to eliminate these unnecessary requirement just to edit this file?
I’ve done extensive searches and I can’t find a tool for editing a dependency tree (except vi, of course). I found a reference to using “systemctl edit” to edit a service, but this version of OpenSUSE results in an “Unknown operation ‘edit’.” message.
Is there a different wat to edit depencies that I’m missing?
Wants means the dependency is optional, not required. Sendmail does not require amavis, if it did, it would be labeled as Requires=amavis.service, for example.
If sendmail specifies this although it’s not needed, you might want to file a bug report.
But, AFAICS the package “sendmail” doesn’t specify those as requirements. So they might not be needed at all? And if they are required by the systemd service file, it’s even more a packaging bug…
All of these services are, however, listed in /usr/lib/systemd/system/sendmail.service as requirements. Is the proper way to eliminate these unnecessary requirement just to edit this file?
You should rather copy the file to /etc/systemd/system and edit the copy. Otherwise your changes might get lost on updates.
It’s also possible to override only certain lines in the .service file, but I’d have to search for that.
I’ve done extensive searches and I can’t find a tool for editing a dependency tree (except vi, of course). I found a reference to using “systemctl edit” to edit a service, but this version of OpenSUSE results in an “Unknown operation ‘edit’.” message.
Never heard of that (systemctl edit).
Just use a text editor of your choice, but you need to run it with root permissions of course.
It was my mistake. I didn’t understand that you should have a lot of errors in your logs about services that aren’t and aren’t supposed to run.
I tried to start sendmail and it failed:
service sendmail start
Job for sendmail.service failed. See ‘systemctl status sendmail.service’ and ‘journalctl -xn’ for details.
I looked in the logs and saw errors entries concerning services I don’t want to run and haven’t installed such as:
2015-04-09T12:00:55.271353-05:00 systemd[1]: Failed to start Amavisd-new Virus Scanner interface.
2015-04-09T12:00:55.271814-05:00 systemd[1]: Unit amavis.service entered failed state.
2015-04-09T12:00:50.076566-05:00 ypbind-systemd-pre[1422]:
Error: NIS domain not specified.
2015-04-09T12:00:50.077016-05:00 systemd[1]: ypbind.service: control process exited, code=exited status=1
2015-04-09T12:00:50.077573-05:00 systemd[1]: Failed to start NIS/YP (Network Information Service) Clients to NIS Domain Binder.
2015-04-09T12:00:50.078174-05:00 systemd[1]: Unit ypbind.service entered failed state.
I incorrectly assumes that I shouldn’t have a bunch of errors like this in my logs and thought these services not starting were why sendmail wasn’t starting.
Apparently, I’m going to get errors like this no matter what. Is there any way to get rid of them?
I’d still like to get rid of what I consider junk requests, even if they aren’t actual dependencies.
> 2015-04-09T12:00:55.271353-05:00 systemd[1]: Failed to start Amavisd-new
> Virus Scanner interface.
> 2015-04-09T12:00:55.271814-05:00 systemd[1]: Unit amavis.service entered
> failed state.
This means you do have amavis installed. Thus, when you start sendmail
it will try to start amavis first, because it is available. You have to
really remove the rpm.
Same for the rest.
Maybe there is a trick to have amavis installed and tell systemd not to
try start it even if sendmail wants it.
You can mask it (systemctl mask amavis.service) but that effectively is the same as deleting unit definition; it won’t be possible to start it even manually any more.
On 2015-04-10 07:36, Fraser Bell wrote:
>
> arvidjaar;2704033 Wrote:
>> You can mask it (systemctl mask amavis.service) but that effectively is
>> the same as deleting unit definition; it won’t be possible to start it
>> even manually any more.
>
> Yes, but if you decide you want it back, you just unmask it: voila!
Well, yes, but that is not the same as somehow deactivating automatic
start (kind of chkconfig init_service off), and starting it manually
whenever you want, never when the system wants it. My decision.
