On Wed, Mar 13, 2019 at 09:05:39PM +0100, deloptes wrote:
> Dan Ritter wrote:
[...]
> > In point of fact:
[...]
> Who seeks, he finds and I have actually installed:
Thanks Dan and deloptes for bringing some sanity into this. And
thanks to all Debian folks who, in spite of all that mud flying
a
Dan Ritter wrote:
> Default User wrote:
>> On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
>>
>> > Well, I know a good solution that will work 100%: switch from Debian
>> > to Devuan to avoid this SystemD. sadly Debian does not provide the
>> > init system freedom, but if you'd switch to its' bro
On Wed, Mar 13, 2019, 10:50 Dan Ritter wrote:
> Default User wrote:
> > On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
> >
> > > Well, I know a good solution that will work 100%: switch from Debian
> > > to Devuan to avoid this SystemD. sadly Debian does not provide the
> > > init system freedom
Default User wrote:
> On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
>
> > Well, I know a good solution that will work 100%: switch from Debian
> > to Devuan to avoid this SystemD. sadly Debian does not provide the
> > init system freedom, but if you'd switch to its' brother distribution
> > (De
On Wed, Mar 13, 2019, 04:06 Ivan Ivanov wrote:
> On Mar 13, 2019, 07:54, Default User wrote:
> >
> > On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
> >>
> >> Well, I know a good solution that will work 100%: switch from Debian
> >> to Devuan to avoid this SystemD. sadly Debian does not provide
On Wed, Mar 13, 2019 at 12:38:48AM -0400, Default User wrote:
[...]
> The cancer of systemd has metastasized too far and the GNU/Linux patent is
> terminally ill.
MikeeeUSA at it again. We don't need that.
-- t
signature.asc
Description: Digital signature
On Wed, Mar 13, 2019, 00:38 Default User wrote:
>
>
> On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
>
>> Well, I know a good solution that will work 100%: switch from Debian
>> to Devuan to avoid this SystemD. sadly Debian does not provide the
>> init system freedom, but if you'd switch to its'
On Tue, Mar 12, 2019, 04:49 Ivan Ivanov wrote:
> Well, I know a good solution that will work 100%: switch from Debian
> to Devuan to avoid this SystemD. sadly Debian does not provide the
> init system freedom, but if you'd switch to its' brother distribution
> (Devuan) it still provides all the b
On Mon, Mar 11, 2019, 03:45 Sven Hartge wrote:
> Default User wrote:
>
> > I will just have to either ignore the problem and pretend it doesn't
> > exist, or just purge the minissdpd package completely, and hope
> > nothing really needs it. Decisions, decisions . . .
>
> "Nothing really needs it
Default User wrote:
> I will just have to either ignore the problem and pretend it doesn't
> exist, or just purge the minissdpd package completely, and hope
> nothing really needs it. Decisions, decisions . . .
"Nothing really needs it." is the answer here. It speeds up some
operations in some c
Okay, I give up.
I have literally spent almost all day trying to solve this. I tried and
tried, everything I could think of. But to no avail. So I quit.
I will just have to either ignore the problem and pretend it doesn't exist,
or just purge the minissdpd package completely, and hope nothing re
Hi.
On Sun, Mar 10, 2019 at 03:30:46PM -0400, Default User wrote:
> So, the file /lib/systemd/system/minissdpd.service is unchanged since Feb
> 27 22:13. It does NOT appear to include the contents of, or even refer
> to, /etc/systemd/system/minissdpd.service.d/override.conf, dated Mar 1
On Sun, Mar 10, 2019 at 1:45 PM Eduardo M KALINOWSKI <
edua...@kalinowski.com.br> wrote:
> On 10/03/2019 13:25, Default User wrote:
>
> So, should I try manually editing /lib/systemd/system/minissdpd.service?
>
> If you do that, you'll lose changes the next time the package is upgraded.
>
> To see
On 10/03/2019 13:25, Default User wrote:
> So, should I try manually editing /lib/systemd/system/minissdpd.service?
>
If you do that, you'll lose changes the next time the package is upgraded.
To see if systemd is seeing your add-in file, use 'systemctl cat
minissdpd.service'. It should list your
On Sun, Mar 10, 2019 at 11:21 AM Reco wrote:
> Hi.
>
> On Sun, Mar 10, 2019 at 01:03:47PM -, Curt wrote:
> > On 2019-03-10, Eduardo M KALINOWSKI wrote:
> > >>
> > >> # directory name is crucial
> > >> mkdir /etc/systemd/system/minissdpd.service.d
> > >> # file name is not important
>
On 2019-03-10, Reco wrote:
>>
>> I have
>>
>> After=network-online.target
>> Wants=network-online.target
>>
>> as per this bug report:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861231
>
> That's good for listening INADDR_ANY, but it's not sufficient in this
> particular case.
>
Hi.
On Sun, Mar 10, 2019 at 01:03:47PM -, Curt wrote:
> On 2019-03-10, Eduardo M KALINOWSKI wrote:
> >>
> >> # directory name is crucial
> >> mkdir /etc/systemd/system/minissdpd.service.d
> >> # file name is not important
> >> cat > /etc/systemd/system/minissdpd.service.d/override.co
On 3/10/19, Curt wrote:
> I don't use sudo and was unaware of this timeout feature.
>
> The timeout interval is configurable, though.
>
> man sudoers:
>
> timestamp_timeout
> Number of minutes that can elapse before sudo will ask for a passwd
> again.
> The timeout may include a fraction
On 2019-03-10, Eduardo M KALINOWSKI wrote:
>>
>> # directory name is crucial
>> mkdir /etc/systemd/system/minissdpd.service.d
>> # file name is not important
>> cat > /etc/systemd/system/minissdpd.service.d/override.conf << EOF
>> [Unit]
>> After=sys-subsystem-net-devices-enp7s0.device
>> sys-su
On 10/03/2019 04:20, Reco wrote:
> On Sat, Mar 09, 2019 at 09:27:35PM -0500, Default User wrote:
>> Hi, Reco.
>> Thanks for the reply and information.
>>
>> Since I know very little about systemd, may I ask, should:
>>
>> [Unit]
>> After=sys-subsystem-net-devices-enp7s0.device
>> sys-subsystem-net-
On 2019-03-10, Default User wrote:
>
> Curt, I often use sudo [command] even when not needed, because the sudo
> elevated privileges state "times out" after several minutes, reverting to
> unprivileged user state. So if I need to enter another command with
> elevated privileges after the elevated
Hi.
On Sat, Mar 09, 2019 at 09:27:35PM -0500, Default User wrote:
> On Sat, Mar 9, 2019 at 2:45 AM Reco wrote:
> >
> > On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> > > Hi. Got a (minor) systemd problem.
> > ...
> > >└─3684 /usr/sbin/minissdpd -i enp7s0 -i w
On Sat, Mar 9, 2019 at 2:45 AM Reco wrote:
> Hi.
>
> On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> > Hi. Got a (minor) systemd problem.
> ...
> >└─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0
> ...
> > So, although the minissdpd.service unit is enables, it d
On Sat, Mar 9, 2019 at 4:21 AM Curt wrote:
> On 2019-03-08, Default User wrote:
> >
> > doofus@doofus:~$ sudo systemctl status
> > [sudo] password for doofus:
> > doofus
> > State: degraded
> > Jobs: 0 queued
> >Failed: 1 units
>
> I believe sudo (or root) isn't required for this co
On 2019-03-08, Default User wrote:
>
> doofus@doofus:~$ sudo systemctl status
> [sudo] password for doofus:
> doofus
> State: degraded
> Jobs: 0 queued
>Failed: 1 units
I believe sudo (or root) isn't required for this command (nor is it
needed for some of the other, interrogative sys
Hi.
On Fri, Mar 08, 2019 at 04:00:05PM -0500, Default User wrote:
> Hi. Got a (minor) systemd problem.
...
>└─3684 /usr/sbin/minissdpd -i enp7s0 -i wlp6s0
...
> So, although the minissdpd.service unit is enables, it does not start
> automatically at boot, but will start manual
Hi. Got a (minor) systemd problem.
Running:
- 64-bit X86 computer.
- Debian Unstable, fully updated.
- Cinnamon desktop environment.
- stock setup, nothing exotic.
Boot up okay.
Internet connectivity okay (wifi, using Network Manager). No apparent
problems.
But,
--
doofus@doofus:~$ su
Jonathan de Boyne Pollard wrote:
> Sven Hartge:
>> systemd happily runs "legacy" LSB init scripts
>>
> ... except when its one-size-fits-all approach does not work, of
> course. Example:
> * https://unix.stackexchange.com/questions/386846/
> This is the problem with even Mewburn rc scripts (a
Sven Hartge:
systemd happily runs "legacy" LSB init scripts
... except when its one-size-fits-all approach does not work, of
course. Example:
* https://unix.stackexchange.com/questions/386846/
This is the problem with even Mewburn rc scripts (as I can attest from
personal experience of wr
Tom Browder:
# systemctl enable postfix # systemctl daemon-reload
Minor note: enable incorporates a daemon-reload.
Christian Seiler wrote:
> Now, that doesn't mean that you should still write _new_ init scripts
> for custom services if you're going to use systemd anyway. There it
> will be a good idea to learn how to do that with native systemd
> service units.
Exactly.
I was able to create much simpler and
Am 2017-08-21 11:52, schrieb Tom Browder:
On Mon, Aug 21, 2017 at 02:36 Sven Hartge wrote:
Question: Why do you want to manually replace the init-script from
postfix in Jessie with a systemd.unit? What do you want to
accomplish by
doing so (other than creating a possible broken system)?
I tho
Tom Browder wrote:
> On Mon, Aug 21, 2017 at 02:36 Sven Hartge wrote:
>> Tom Browder wrote:
>>> On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
>>> So the question I have is how does it all work? There is no init.d,
>>> but there seems to be some convoluted handling that I haven't
>>> figure
On Mon, Aug 21, 2017 at 02:36 Sven Hartge wrote:
> Tom Browder wrote:
> > On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
>
> > So the question I have is how does it all work? There is no init.d,
> > but there seems to be some convoluted handling that I haven't figured
> > out yet. Surely so
Tom Browder wrote:
> On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
>> That unit file does effectivly nothing. It just starts "/bin/true" and
>> exits.
>>
>> What it *not* does is starting postfix in any way.
>>
>> This looks like there should be some other unit files which start the
>> other
On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
> Tom Browder wrote:
>
> > The contents of the postfix.service file are;
>
...
> That unit file does effectivly nothing. It just starts "/bin/true" and
> exits.
>
> What it *not* does is starting postfix in any way.
>
> This looks like there shou
On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
> Tom Browder wrote:
>
> > The contents of the postfix.service file are;
>
...
>
> That unit file does effectivly nothing. It just starts "/bin/true" and
> exits.
>
> What it *not* does is starting postfix in any way.
...
> .
> Are you sure you
Tom Browder wrote:
> The contents of the postfix.service file are;
> [Unit]
> Description=Postfix Mail Transport Agent
> Conflicts=sendmail.service exim4.service
> ConditionPathExists=/etc/postfix/main.cf
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecReload=/bin/t
On Sun, Aug 20, 2017 at 11:41 AM, Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
>> So "disabled" is normal?
>
> Indeed. See:
>
> https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/ch-Services_and_Daemons.html#s3-services-configuration-enabling
I d
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> So "disabled" is normal?
Indeed. See:
https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/ch-Services_and_Daemons.html#s3-services-configuration-enabling
Regards,
--
Nicolas George
signature.asc
Description: Digital s
On Sun, Aug 20, 2017 at 10:17 AM, Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
>> > # systemctl start postfix
>> > # systemctl status postfix
>> >
>> > and got several lines basically saying posfix.service was disabled.
>
>> The exact message is:
>>
>> * postfi
On Sun, Aug 20, 2017 at 10:17 Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> > > # systemctl start postfix
> > > # systemctl status postfix
> > >
> > > and got several lines basically saying posfix.service was disabled.
>
> > The exact message is:
> >
> > * po
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> > # systemctl start postfix
> > # systemctl status postfix
> >
> > and got several lines basically saying posfix.service was disabled.
> The exact message is:
>
> * postfix.service - Postfix Mail Transport Agent
>Loaded: loaded (/etc
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> I got a postfix.service file from a postfix developer and installed it in
> /etc/systemd/system as the docs mention.
>
> I then moved the /etc/init.d/postfix file away, reloaded the systemd
> daemon, and did:
>
> # systemctl start postfix
On Sun, Aug 20, 2017 at 9:42 AM, Tom Browder wrote:
> I got a postfix.service file from a postfix developer and installed it in
> /etc/systemd/system as the docs mention.
>
> I then moved the /etc/init.d/postfix file away, reloaded the systemd daemon,
> and did:
>
> # systemctl start postfix
>
I got a postfix.service file from a postfix developer and installed it in
/etc/systemd/system as the docs mention.
I then moved the /etc/init.d/postfix file away, reloaded the systemd
daemon, and did:
# systemctl start postfix
# systemctl status postfix
and got several lines basically saying
46 matches
Mail list logo
